|
[Sponsors] |
dynamicMotionSolverFvMeshAMI restart implementation |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
October 23, 2024, 08:28 |
dynamicMotionSolverFvMeshAMI restart implementation
|
#1 |
New Member
Cristóbal
Join Date: Jan 2022
Location: Sweden
Posts: 17
Rep Power: 4 |
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 |
|
November 13, 2024, 02:57 |
modify pimpleFoam
|
#2 |
New Member
Cristóbal
Join Date: Jan 2022
Location: Sweden
Posts: 17
Rep Power: 4 |
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()) { 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; } 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 |
|
November 19, 2024, 13:20 |
modify constructor dynamicMotionSolverFvMeshAMI
|
#3 |
New Member
Cristóbal
Join Date: Jan 2022
Location: Sweden
Posts: 17
Rep Power: 4 |
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 |
|
Tags |
amitopologychange, cyclicacmi, cyclicami, dynmotionsolverfvmeshami, openfoam |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |