CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Bugs (
-   -   Problem of restarting moving meshes with icoDyMFoam (

rolando March 22, 2007 06:21

Hi, I have detected a problem
I have detected a problem with restarting the calculation of moving meshes.
The problem is, that if you calculate moving meshes with icoDyMFoam, the solution of the phi field is stored as relative phi (phi - meshPhi).
If you restart the same calculation, phi is read and handled as absolute phi.
My first intention to handle this problem was to make the fluxes absolute before storing them with runTime.write and make them relative again directly afterwards.
This is at least not nice, as the fluxes are stored as absolute ones. Moreover if you restart the calculation and use a dynamic time step you get a problem as the Co-number is determined wrongly.
As there is stored meshPhi when handling moving meshes, it may be best to change the fvMesh constructor in a way that it reads meshPhi if present and sets the moving_ attribute of polyMesh to true.
That would leave icoDyMFoam uneffected and solve the problem I think.
Any acceptance or denial?


henry March 22, 2007 06:31

Yes your proposal looks reason
Yes your proposal looks reasonable, I will try it in 1.4 and if all is well the change will go out in the release.


rolando March 22, 2007 06:43

Meanwhile I will try it myself
Meanwhile I will try it myself, so that I can continue my work with 1.3.
I think I just have to change moving_ from private to protected in polyMesh and change the fvMesh constructor.
Can you estimate when 1.4 will be released?


henry March 22, 2007 06:56

Yes that should be enough. 1.
Yes that should be enough. 1.4 is undergoing beta testing and will be released soon.


rolando March 22, 2007 07:00

Im looking forward to 1.4. I
Im looking forward to 1.4.
Ill tell you if the changes in polyMesh and fvMesh fix the problem.


rolando March 22, 2007 08:58

Hello Hrvoje, as far as I und
Hello Hrvoje,
as far as I understand the library, the above way indeed doesnt restore all informations (like the points before motion, swept volumes, ...).
But the only information that is accessable, when loading the data from a time directory is the meshPhi field. And the only informations that I can recover of it are the mesh fluxes (of course) and the fact that the mesh is moving (moving_ = true;)
But that are the only information that I need for icoDyMFoam, which uses polyMesh.moving() and fvc::meshPhi(U). And fvc::meshPhi just accesses phiPtr_, which is a member of fvMesh.
Is something wrong about that?


rolando March 22, 2007 11:16

I see the problem. It would b
I see the problem.
It would be nice if there was a solution to this problem. Meanwhile I use the above fix. It seems to work. I have tested a first shot.
To the above things I had also to assure that V0 was stored. It is obviously used by the time schemes.

There I encountered an inconsistency in fvMesh.
In fvMesh::V00() there is the line of code:

V0Ptr_->writeOpt() = IOobject::AUTO_WRITE;

But in fvMesh::movePoints(..) where V0Ptr_ is created, the IOobject of V0Ptr_ has the "false flag" for registering this object. So it cant be stored and the above line of code has no effect. I think the false flag has to be removed.


henry March 23, 2007 06:51

Rolando, I have implemented

I have implemented your suggested change into 1.4 and adjusted the handling of V0 to be consistent (slightly differently to your approach) and it runs and restarts fine now. I have also taken this a bit further and made some improvements to the handling of absolute and relative flux conversions in the libraries and icoDynFoam to handle the case of no mesh motion more elegantly and to make the code simpler.


rolando March 23, 2007 07:18

Thanks Henry, that sounds ver
Thanks Henry,
that sounds very good. Im really looking forward to 1.4.

One word about what I did:
In the fvMesh constructor I made a request for the meshPhi file before creating the meshPhi object, to ensure it isnt created for non-moving cases.


All times are GMT -4. The time now is 20:42.