Starccm+ v10.02.010, resume a moving mesh = problem
 

Hello,

I have a DFBI (type boat on a free surface) moving mesh simulation that I was able to run/stop/resume any way I wanted with starccm+ v9. I have opened this simulation with the new v10, it worked and ran.
But then I saved it and closed it. When I try to reopen and resume it, I always get the error message "Enabling a DFBI during a time-step is unsupported", and it crashes. I never got that error message before with any previous version.

I believe this is not linked to my specific simulation since it can perfectly run on v9 (as long as I do not save it with v10),

anybody encountered that ?

No. That is fairly specific and the chances of someone on here having encountered that in the few weeks since v10 release are small. I would contact Tech Support, they love development bugs like this.

that's what I figured but we never know.. thanks, so my only option is to open a support case on the steve portal or is there another way (like direct email contact) ?

Steve Portal is the easiest. Create a case, be descriptive, give your email/phone (if you are at a large company or school), and your DSE will contact you.

If you do end up contacting support and getting an answer from them, we would love to hear about it!

I got a reply from the support, and in fact, unlike with the previous versions, in order to resume this type of simulation it has to be saved at the end of a time step. It does not work anymore when we save during a time step, so be careful if your autosave criterion is set to iteration instead of time step.

Saving at the end of a time step makes sense and I thought I was doing so, until I realized that because I was using an iteration criterion for the auto save, it actually did not save when I expected. For example, most of the time I have 5 iterations per time step, and say I have an auto save like [...]@35000.sim, I would guess it corresponds to the end of a time step, but for this simulation it was not the case, it was actually in the middle of the 6999th timestep, which I did not expect.

This has been fixed in 10.04.009 - maybe you can import your model to this version and resume.

Yes you are right, thanks!