[cibanez]

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

[cibanez]

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.

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.

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]

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