[pbachant]

I am running a case in pimpleDyMFoam, which seems to work well enough, but when I attempt to restart from latestTime, I am getting a large positive, then negative spike in the forces/moments right at the start of the new run. I am using an unsteady dynamicMeshDict, which has a table of 400 omega values. This is regenerated when restarting the solver, so it extends to endTime. My only guess it that the spikes could be caused by a change in the dynamicMeshDict, but that seems unlikely because of the resolution. To be more specific, I'm going from 400 omega values per 0.3 seconds to 400 omega values per 0.4 seconds. Any other ideas on what might be causing this issue?

[wyldckat]

Greetings Pete,

It might be due to a bug in the OpenFOAM version you are using.
There have been several bugs fixed related to simulation restarts, for example since OpenFOAM 2.1.0 was released, therefore knowing which OpenFOAM version you are using would make it a bit easier to assess if it's something that has already been fixed.

Best regards,
Bruno

[jvl001]

I had the same problem using v 2.2.x from the git repo. I found that the problem is that 'meshPhi' is not being written at each time step, and thus not read by the appropriate fvMesh constructor.

The pimpleDyMFoam solver does the following before advancing the PIMPLE loop:

fvc::makeAbsolute(phi, U); // This depends on meshPhi
mesh.update(); // This creates the meshPhi field if it doesn't exist, then updates it.
fvc::makeRelative(phi, U) // This depends on meshPhi

If meshPhi is not saved during the last time step, pimpleDyMFoam starts up with a zero-valued meshPhi, causing an immediate difference in the calculations of mesh displacement, U, and p. This probably affects other *DyMFoam solvers.

I'm not certain what the best fix is, other than to force fvMesh::movePoints() to write meshPhi every time it updates the phiPtr_ variable.
In my code, I adjusted the fvMesh::movePoints() function as follows:

- Change 'IOobject::NO_WRITE' to 'IOobject::AUTO_WRITE'
- Added a phi.write() just before the function returns. <-- This isn't good as it creates a new time directory at each time step!

Update:

I just took a look at the source of pimpleDyMFoam.C v2.3.x in git. Looks like it has been modified to fix this problem, though I have not tested it...

[jvl001]

After recompiling v2.3.x I discovered the restart problem still remains. However I did determine how to get meshPhi to be written, if needed. You'll need to modify fvMesh.C so that:

- 'phiPtr_' is registered as an IO object (currently it is not)
- add logic to change phiPtr_ to IOobject::AUTO_WRITE with the current time step if it is modified by fvMesh::movePoints
- add logic to write phiPtr_ if it exists in fvMesh::writeObject

The attached patch should work with v2.2.x (tested) or v2.3.x (not tested).

Apply this patch from the '$WM_PROJECT_DIR':

cd $WM_PROJECT_DIR
patch -p0 < fvMesh.patch
wmake src/finiteVolume

[wyldckat]

Hi Jason,

I thought this was a bug that was fixed long ago by now.
Thanks for sharing the solution you've found!

Please report this on the official bug tracker, so that the OpenFOAM team can fix this as well: http://www.openfoam.org/mantisbt/ - and please provide them with a test case and details on the issue, so that they can confirm how to reproduce the error.

Best regards,
Bruno