CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

dynamicMotionSolverFvMeshAMI restart implementation

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By cibanez

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 23, 2024, 08:28
Default dynamicMotionSolverFvMeshAMI restart implementation
  #1
New Member
 
Cristóbal
Join Date: Jan 2022
Location: Sweden
Posts: 17
Rep Power: 4
cibanez is on a distinguished road
Hi,

I'm a regular user of cyclicAMI and cyclicACMI patches for the interfaces between rotating and stationary zones. I've recently tested the motion solver dynamicMotionSolverFvMeshAMI that introduces topology changes to achieve 1 to 1 face matching between patches at the interface to maintain mass conservation. This solver structure was incorporated in v2006 as beta-level code (check OpenFOAM-v2006 release notes) and the improvements in signal noise are quite remarkable. Now, as the release note specifies, restarting the simulation is not currently supported. This leads me to the first questions: why does it not restart? what would it be necessary for it to restart?

In mixerVesselAMI2D-topologyChange tutorial the error when restarting from a later saved time originates because the number of patch faces no longer corresponds to the number of field values at the patch that has been saved at that time. In consequence fields at the patches cannot be initialized. One bypass to this issue is to clone the case, copy the content of constant/polymesh, with the exception of the points, to the new time in the cloned case and then map the fields from the original case to the cloned case and restart with the AMI solver. This will restart the simulation but there will be a mass loss since the fields are being "cut" to fewer faces when mapping.

I understand that the topology algorithm is duplicating faces according to how the owner patch overlays with the neighbor patch, but since we are not adding any extra points I'm not sure how this process depends on the original mesh all the time. I suspect it has to do with how the patch is constructed. I intend to keep investigating this issue, but for the moment, has anyone tried to tackle it or could give me any directives? It would be great to be able to restart without a loss of mass in the process.

Regards,
/C
WJPeace1 likes this.
cibanez is offline   Reply With Quote

Old   November 13, 2024, 02:57
Default modify pimpleFoam
  #2
New Member
 
Cristóbal
Join Date: Jan 2022
Location: Sweden
Posts: 17
Rep Power: 4
cibanez is on a distinguished road
Hi,

I've found a workaround that makes restarting a more smooth process. Restarting fails in pimpleFoam when #include "createFields.H" gets called and the fields get initialized on the AMI patches. Since the error states that there are more field values than faces then I figured the mesh topology changes should be called before this line with mesh.controlledUpdate(). This way the AMI patches go through the process of resetting, removing and adding new faces given the current rotation so the fields get correctly initialized before the while loop.

This is the modified pimpleFoam.C that works for restarting the mixerVesselAMI2D-topologyChange case.
Code:
int main(int argc, char *argv[])
{
    argList::addNote
    (
        "Transient solver for incompressible, turbulent flow"
        " of Newtonian fluids on a moving mesh."
    );

    #include "postProcess.H"

    #include "addCheckCaseOptions.H"
    #include "setRootCaseLists.H"
    #include "createTime.H"
    #include "createDynamicFvMesh.H"
    #include "initContinuityErrs.H"
    #include "createDyMControls.H"

    mesh.controlledUpdate(); // Do any mesh changes

    #include "createFields.H"
    #include "createUfIfPresent.H"
    #include "CourantNo.H"
    #include "setInitialDeltaT.H"

    turbulence->validate();

    if (!LTS)
    {
        #include "CourantNo.H"
        #include "setInitialDeltaT.H"
    }

    // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

    Info<< "\nStarting time loop\n" << endl;

    while (runTime.run())
    {
From cyclicAMIPolyPatchTopologyChange.C, these are the steps that set the correct number of patch faces and weights at the given time.
Code:
bool Foam::cyclicAMIPolyPatch::setTopology(polyTopoChange& topoChange)
{
    DebugInFunction << endl;

    if (createAMIFaces_ && owner())
    {
        // Calculate the AMI using the new points
        // Note: mesh still has old points
        resetAMI(topoChange.points());

        removeAMIFaces(topoChange);

        addAMIFaces(topoChange);

        return true;
    }

    return false;
}
It is important to change writeFormat in controlDict to binary or something as precise as the precision of the points in constant/polyMesh. This is because when the case gets restarted the points that are not being transformed by rotation are taken from the points file of the restarting time. If the precision of the points in the restarting time is different from the precision of points in constant, then the addressing of intersecting faces between AMI1 (rotates) and AMI2 (static) can give more faces than it should. For example, in the tutorial slight differences in Z coordinate in AMI2 might have an AMI1-face intersect with 4 AMI2-faces instead of 2. Not changing the precision of the tutorial fails the restarting since a wrong number of faces will be added.

A better solution than this workaround could be to make the topology process kick in during the construction of dynamicMotionSolverFvMeshAMI instead. Then this should work for any solver without the need of modification. Precision should still be important.

/C
cibanez is offline   Reply With Quote

Old   November 19, 2024, 13:20
Default modify constructor dynamicMotionSolverFvMeshAMI
  #3
New Member
 
Cristóbal
Join Date: Jan 2022
Location: Sweden
Posts: 17
Rep Power: 4
cibanez is on a distinguished road
Hi,

This issue has been resolved. For anyone interested you can check the commit here.

The fix runs update() during initialization of dynamicMotionSolverFvMeshAMI only if required. This would be the case if the time of restarting contains the duplicate faces. If it does not contain the duplicate faces, running topology changes during the initialization ends up in error (more patch faces than patch values). In this case update() is not run.

/C
cibanez is offline   Reply With Quote

Reply

Tags
amitopologychange, cyclicacmi, cyclicami, dynmotionsolverfvmeshami, openfoam

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Restart file question Athos_e SU2 3 April 29, 2024 06:41
solids4Foam: Restart of solid-solid contact cases not working for some cases conza OpenFOAM Bugs 4 November 7, 2023 07:52
Time-accurate solution restart from steady state solution jyotir SU2 6 December 8, 2021 09:34
Unsteady Restart Divergence pro_ SU2 6 May 20, 2020 16:17
Problem with multiframe restart of two-way fsi coupled problem Dimone CFX 26 December 20, 2011 11:10


All times are GMT -4. The time now is 22:33.