[Wowbagger]

Hi Foamers,

I am struggling with an overset simulation.
I ran a simulation to the time XXX and stopped it there.

In a second thought I wanted to restart it from there with a shorter interval of write time.
Trying this always gives me the same problem.

-> The mesh courant number is much too high and I do not know how to avoid this in the initial start from time XXX.
In the second time step the velocity of the overset mesh is much too high which seems to be the result of the initial problem. After this mismatch the simulation does not get better....

I tried to set the time stepping to really very low numbers fot the initial calculation but this seems to be not related in the initial mesh courant number....

Anybody got experience how to fix this?


Best regards,
Michael

[Wowbagger]

Initial logfile from time XX, Courant 0.8 was the courant from running simulation at the first start. It ran well over a long time so this problem seems only related to the restart I think. First, initial step of the reastart:

Starting time loop

Courant Number mean: 0.002566905784 max: 0.798598669498
deltaT = 1e-12
Time = 7

forces forces:
    rho: rhoInf
    Freestream density (rhoInf) set to 1.2
    Not including porosity effects

6-DoF rigid body motion
    Centre of rotation: (4.52050459585e-27 9.36037226369e-28 3.48672357583e-26)
    Centre of mass: (4.52050459585e-27 9.36037226369e-28 3.48672357583e-26)
    Orientation: (1 1.89886146867e-25 3.56446691711e-23 -1.89886146867e-25 1 -1.4704682721e-23 -3.56446691711e-23 1.4704682721e-23 1)
    Linear velocity: (9.0410091917e-15 1.87207445274e-15 6.97344715165e-14)
    Angular velocity: (2.9409365442e-11 7.12893383421e-11 -3.79772293735e-13)
DILUPBiCGStab:  Solving for yPsi, Initial residual = 0.00454392990427, Final residual = 9.46945338613e-06, No Iterations 69
inverseDistance : detected 3 mesh regions
    zone:0 nCells:309288  voxels:(27 27 27) bb:(-0.40000045141 -0.397980507516 -0.500000747277) (-0.0399704184464 7.47279699828e-07 0.0200152408993)
    zone:1 nCells:2488  voxels:(27 27 27) bb:(-2.00000058403 -2.00000092056 -2.50000150997) (-1.19999788023 -1.1999981944 -1.49999849003)
    zone:2 nCells:21024  voxels:(27 27 27) bb:(-2.00000058403 -2.00000092056 -2.50000150997) (-1.19999788023 -1.1999981944 -1.49999849003)
Overset analysis : nCells : 332800
    calculated   : 330360
    interpolated : 1501 (from local:1055  mixed local/remote:446  remote:0)
    hole         : 939

Mesh Courant Number mean: 0.0225261263018 max: 545.439207769
PIMPLE: iteration 1
...

Second step:

Courant Number mean: 0.0484307886207 max: 201.289335348
deltaT = 3.97437846679e-15
Time = 7

forces forces:
    rho: rhoInf
    Freestream density (rhoInf) set to 1.2
    Not including porosity effects

6-DoF rigid body motion
    Centre of rotation: (-2.3195495872e-11 1.08337649798e-11 -6.60471118518e-11)
    Centre of mass: (-2.3195495872e-11 1.08337649798e-11 -6.60471118518e-11)
    Orientation: (1 -8.81915728871e-14 -1.30487618269e-08 8.82711033301e-14 1 6.09486510264e-09 1.30487618269e-08 -6.09486510264e-09 1)
    Linear velocity: (-11672.5148678 5451.80338024 -33236.4481157)
    Angular velocity: (-3067078.36386 -6566441.48812 44.4000685119)
DILUPBiCGStab:  Solving for yPsi, Initial residual = 0.0135703272124, Final residual = 7.40960574936e-06, No Iterations 77
inverseDistance : detected 3 mesh regions
    zone:0 nCells:309288  voxels:(27 27 27) bb:(-0.40000045141 -0.397980507516 -0.500000747277) (-0.0399704184464 7.47279699828e-07 0.0200152408993)
    zone:1 nCells:2488  voxels:(27 27 27) bb:(-2.00000058403 -2.00000092056 -2.50000150997) (-1.19999788023 -1.1999981944 -1.49999849003)
    zone:2 nCells:21024  voxels:(27 27 27) bb:(-2.00000058403 -2.00000092056 -2.50000150997) (-1.19999788023 -1.1999981944 -1.49999849003)
Overset analysis : nCells : 332800
    calculated   : 330543
    interpolated : 1318 (from local:955  mixed local/remote:363  remote:0)
    hole         : 939

Mesh Courant Number mean: 9.3848858359e-10 max: 2.21983969752e-05
PIMPLE: iteration 1

...

Any help is welcome.

[Ranj]

Hi, I have this same problem and it's because the original dynamicMeshDict is read so centre of rotation etc. are set back to their original positions. Unfortunately I don't know a way around this; did you manage to find a solution?

[Wowbagger]

Hi Ranj,

thanks for that hint!
This sounds like the problem.

If so, it is possible to change the position and motion of the body in the dynamicMeshDic, etc and restart with that.

I will try this and give you feedback.
Thanks a lot!

Best regards,

Michael

[Wowbagger]

I made this short test without success.
But I found out the important part I think:
Reconstructing the latest time and have a look to it in paraView showed that the overset mesh did not move. Therefore I suggest that this position is always the reference for the calculation with the pointDisplacement folder.

I tried different ways to get the latest simulated time step into reconstructed form but without success.

Does anybody knew:
--> Is there a way to reconstruct the latest time step in overset mesh?

Maybe I missed the important bit...
Any help welcome.

Best regards
Michael

[music_of_emotion]

Originally Posted by Wowbagger

Hi Foamers,

I am struggling with an overset simulation.
I ran a simulation to the time XXX and stopped it there.

In a second thought I wanted to restart it from there with a shorter interval of write time.
Trying this always gives me the same problem.

-> The mesh courant number is much too high and I do not know how to avoid this in the initial start from time XXX.
In the second time step the velocity of the overset mesh is much too high which seems to be the result of the initial problem. After this mismatch the simulation does not get better....

I tried to set the time stepping to really very low numbers fot the initial calculation but this seems to be not related in the initial mesh courant number....

Anybody got experience how to fix this?


Best regards,
Michael

Hi dear Michael,
I am a newbie to CFD, but recently I've been able to simulate a 3d floating object using overset mesh, although there are tons of issues which I still don't know.

You have executed your model for 7 seconds, which is pretty good and indicates your model is working. But, suddenly, your solution diverges. you want to see what causes this problem and you want to reduce the write Interval to capture more details of divergence. right?

I can't understand what's the point in reconstructing the latest time step?

You can change the controlDict parameters, including write interval on the fly. Did you try to delete some (2 or 3) solved folders from processor* directories and then re-run the simulation?

Since in the overset, the mesh doesn't deform, so running from the last time step won't be an issue. In the former case (deforming meshes as in mesh morphing), you need to do some considerations which are not necessary here.

[Wowbagger]

I am a newbie to CFD, but recently I've been able to simulate a 3d floating object using overset mesh, although there are tons of issues which I still don't know.

Keep on doing. Thats the only way to learn. I am not really new but my knowledge is limitied. I am still trying stuff to improve....

You have executed your model for 7 seconds, which is pretty good and indicates your model is working. But, suddenly, your solution diverges. you want to see what causes this problem and you want to reduce the write Interval to capture more details of divergence. right?

No. Model runs fine and I aborted it. I am fine with this part. I go through the data and now I want to have a better time resolution in the results to have a better view on a small time scale.

 I can't understand what's the point in reconstructing the latest time step?

In my understanding when you restart the simulation from latest time the solver seems not to take the value from the latest overset position.

Reconstructing the latest time shows differences in paraview:
-looking to the decomposed case - everything is fine like the in the running aborted simulation.
-looking into the reconstructed case - I see the overset mesh in the original position at start without any change.
Therefore I think the restart is related to this.

 You can change the controlDict parameters, including write interval on   the fly. Did you try to delete some (2 or 3) solved folders from   processor* directories and then re-run the simulation?

I know about changing on the fly.
I tried to re-run in some time before - while I was working on the case to run.
It did not work and I thought this was related to some bad numerics.

Now the case is running fine but I can not re-start from latest time. And now I believe this is related to some overset stuff which I do not know so far or there is still a bug...

 Since in the overset, the mesh doesn't deform, so running from the last time step won't be an issue. In the former case (deforming meshes as in mesh morphing), you need to do some considerations which are not necessary here.

True in case of deformation.
But the position of the overset mesh are totally different from the very start to the latest time step...

[music_of_emotion]

Originally Posted by Wowbagger

Keep on doing. Thats the only way to learn. I am not really new but my knowledge is limitied. I am still trying stuff to improve....


No. Model runs fine and I aborted it. I am fine with this part. I go through the data and now I want to have a better time resolution in the results to have a better view on a small time scale.

 I can't understand what's the point in reconstructing the latest time step?

In my understanding when you restart the simulation from latest time the solver seems not to take the value from the latest overset position.

Reconstructing the latest time shows differences in paraview:
-looking to the decomposed case - everything is fine like the in the running aborted simulation.
-looking into the reconstructed case - I see the overset mesh in the original position at start without any change.
Therefore I think the restart is related to this.

 You can change the controlDict parameters, including write interval on   the fly. Did you try to delete some (2 or 3) solved folders from   processor* directories and then re-run the simulation?

I know about changing on the fly.
I tried to re-run in some time before - while I was working on the case to run.
It did not work and I thought this was related to some bad numerics.

Now the case is running fine but I can not re-start from latest time. And now I believe this is related to some overset stuff which I do not know so far or there is still a bug...

 Since in the overset, the mesh doesn't deform, so running from the last time step won't be an issue. In the former case (deforming meshes as in mesh morphing), you need to do some considerations which are not necessary here.

True in case of deformation.
But the position of the overset mesh are totally different from the very start to the latest time step...

Dear Mickael,

Thank you so much for your detailed response,

So it seems the problem is related to existing overset bugs that should be solved in the next updates.

First: May I ask you to share your case files??

Second: In my opinion, one of your last resources is to re-mesh everything again. These steps may be obvious for you, but to be used for others, try this procedure:

1) Reconstruct to your latest time step (your_last_time_step folder creates).


2) Make another folder resembling your case (background and overset). In the background directory, make an 'empty folder' named your_last_time_step.


3) Copy the "constant" and the "system" folders from the former "background" and "overset" directories to the new "background" and "overset" ones.


4) Modify the dictionaries, especially your write intervals and starting time, which should be the same as the last time step you reconstructed before.

5) In the "background directory", update the centre of mass in dynamicmeshDict according to your latest log file.


6) In the "overset directory", modify your blockmesh according to the updated centre of mass and the controlDict such as starting time.


7) If you have a 6dof body, it might be introduced by an STL file. You need to make an STL file from the latest position of your body. So:

a) copy "points" from reconstructed/polymesh to background/constant/polymesh

b) extract STL file from your patch using surfaceMeshTriangulate (in openfoam foundation versions this tool exists ), e.g. :
surfaceMeshTriangulate -patches '(your patch or object)' new_stl_file.stl

c) move the created STL file to the overset/constant/triSurface

d) modify surfaceFeatureExtractDict and snappyHeshDict according to the new STL file.

e) execute all commands related to mesh generation as before (blockMesh, snappy, mergeMesh , ...)

f) execute mapFields to mirror field values from the reconstructed folder to the created your_last_time_step folder:

mapFields ../former_backgrounf_directory -sourceTime your_last_time_step -mapMethod cellPointInterpolate -noFunctionObjects -consistent

g) copy pointDisplacement file from 0 directory (former background directory) to the your_last_time_step folder (new background directory).

h) copy "uniform" folder from reconstructed folder (former background directory) to the your_last_time_step (new background directory)


8) re-run the simulation.


Best regards,

Diyanosh

[Wowbagger]

Hi Diyanosh...

...are you sure you are a OpenFOAM newby?! ^^
Thanks a lot for your detailed description of the steps for the restart.
I took in account that it is needed to get a new mesh but I was not aware about the practises in step 7.

I will try it as soon as I got a few hours to work on that again. But I think it will be earliest next week. However I will give feedback.

Regarding the question to my case files: You got PN.

Best regards
Michael

[Wowbagger]

Finally after a long time I did it.
With the help of Diyanosh I was able to restart at the given time.

Most points where correct but I did not find a way to work with openfaom on point 7a & 7b.
I updated Diyanoshs work therefore with my findings. Some steps are slightly different due to simple preference:


1. Reconstruct the latest time Step
2. Make a copy of the folders (background & overset) with foamCloneCase.
3. Copy the reconstructed latestTime from the old background folder into the new one.
4. Modify the dictionaries, especially your write intervals and starting time, which should be the same as the last time step you reconstructed before.

5. In the "background directory", update
a) the centre of mass in dynamicmeshDict according to your latest log file.
b) same with velocity
c) I had no markable angular momentum. This was not for big intereset. Keep that in mind, maybe check for it.

6. In the "overset directory", modify your blockmesh according to the updated centre of mass and the controlDict such as starting time.

7. For my 6dof body I need the last position of the body.
I do not found a way to get this via openfoam. So I had to use paraView instead.
Therefore go to the latest time step.
a) ExtractBlock - with the overset body.
b) Mark ExtractBlock in the pipeline --> "File" --> "Save Data" --> "MyMovinBody.stl"
c) Use this file in the new 'overset/constant/triSurface' folder
d) Use the same name as before for the stl file or change snappyHexMesh & surfaceFeatureExtractDict to new name.

8) execute all commands related to mesh generation as before (blockMesh, snappy, mergeMesh , ...)

--------------------------------------------------
9) Only in case you refined or changed the oversetmesh: cp ./'time'/zoneID ./'time'/zoneID.orig
--------------------------------------------------

10) execute mapFields to mirror field values from the reconstructed folder to the created your_last_time_step folder:
mapFields ../former_backgrounf_directory -sourceTime your_last_time_step -mapMethod cellPointInterpolate -noFunctionObjects -consistent
11) after mapping pointDisplacement file gets an extension to: pointDisplacement.unmapped
remove this by: cp -R ./7/pointDisplacement.unmapped ./7/pointDisplacement

--------------------------------------------------
12) Only in case you refined or changed the oversetmesh. Get back the zoneIDs from the new mesh by: cp ./'time'/zoneID.orig ./'time'/zoneID
--------------------------------------------------

14) re-run


Thanks again Diyanosh. This gave me a lot more understanding in how openFoam works.

Best regards
Michael