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

JohnAB · March 18, 2015, 11:40

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 ?

fluid23 · March 18, 2015, 16:53

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.

JohnAB · March 18, 2015, 17:46

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) ?

fluid23 · March 19, 2015, 07:56

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.

simplepiso · March 28, 2015, 11:44

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

JohnAB · April 9, 2015, 12:10

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.

chooper11 · August 12, 2015, 23:11

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

JohnAB · August 13, 2015, 11:59

Yes you are right, thanks!

March 18, 2015, 11:40	Starccm+ v10.02.010, resume a moving mesh = problem	#1
JohnAB Member Join Date: Nov 2012 Posts: 74 Rep Power: 13	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 ?

March 28, 2015, 11:44		#5
simplepiso New Member Join Date: Mar 2015 Posts: 1 Rep Power: 0	If you do end up contacting support and getting an answer from them, we would love to hear about it! lcarasik likes this.

April 9, 2015, 12:10		#6
JohnAB Member Join Date: Nov 2012 Posts: 74 Rep Power: 13	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. chooper11 likes this.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
snappyhexmesh remove blockmesh geometry	philipp1	OpenFOAM Running, Solving & CFD	2	December 12, 2014 10:58
Question on moving mesh, mesh velocity is really small!	ripperjack	Main CFD Forum	2	April 28, 2014 13:37
[Other] How to set up a dynamic mesh for a piston moving through a tube of variable diameter?	karkar	OpenFOAM Meshing & Mesh Conversion	0	July 4, 2012 06:54
[Gmsh] 2D Mesh Generation Tutorial for GMSH	aeroslacker	OpenFOAM Meshing & Mesh Conversion	12	January 19, 2012 03:52
How to control Minximum mesh space?	hung	FLUENT	7	April 18, 2005 09:38

March 18, 2015, 16:53		#2
fluid23 Senior Member Matt Join Date: Aug 2014 Posts: 947 Rep Power: 17	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.

March 18, 2015, 17:46		#3
JohnAB Member Join Date: Nov 2012 Posts: 74 Rep Power: 13	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) ?

March 19, 2015, 07:56		#4
fluid23 Senior Member Matt Join Date: Aug 2014 Posts: 947 Rep Power: 17	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.

August 12, 2015, 23:11		#7
chooper11 New Member Join Date: Aug 2015 Posts: 2 Rep Power: 0	This has been fixed in 10.04.009 - maybe you can import your model to this version and resume.

August 13, 2015, 11:59		#8
JohnAB Member Join Date: Nov 2012 Posts: 74 Rep Power: 13	Yes you are right, thanks!