[rolando]

Hi,
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?

Rolando

[henry]

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.

Henry

[rolando]

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?

Rolando

[henry]

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

Henry

[rolando]

I´m looking forward to 1.4.
I´ll tell you if the changes in polyMesh and fvMesh fix the problem.

Rolando

[rolando]

Hello Hrvoje,
as far as I understand the library, the above way indeed doesn´t 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

[rolando]

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 can´t be stored and the above line of code has no effect. I think the false flag has to be removed.

Rolando

[henry]

Rolando,

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.

Henry

[rolando]

Thanks Henry,
that sounds very good. I´m 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 isn´t created for non-moving cases.

Rolando