Remove foam interface singleton#41
Merged
hsaunders1904 merged 13 commits intoaurora-multiphysics:mainfrom Mar 7, 2025
Merged
Conversation
This class being a singleton was causing problems when more than one hippo multiapp was being run - it would only run one of them, twice! This change removes the FoamInterface class and we indirectly replace it with a FoamRuntime class that keeps everything we need alive (the Foam::Time, the Foam::argList, etc.). Interactions with the OpenFOAM API are performed through the rest of the FoamX classes (e.g., FoamSolver, FoamMesh), so we don't need the interface class anymore.
All the other member functions in the class have a signature like: `(int patch_id, vector<> &v)`. For consistency, make the first argument to wallHeatFlux the patch ID.
There seems to be a bit of weirdness when not initialising a solver, where OpenFOAM doesn't cope well with destruction of Time objects. I'd get errors saying 'Cannot access element zero of list' (or similar) when the OpenFOAM object trees were being destructed. Workaround this by always intialising a solver.
The cube slice tests were failing as the cases were not valid for initialising an OpenFOAM fluid solver. This commit creates the necessary files but also removes a bunch of pre-meshed and pre-decomposed cases. We now build and decompose the mesh in the setup step of the tests.
Also add instructions on how to generate the reference data.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Removes the
FoamInterfacesingleton, which allows us to have two Hippo multiapps in a single multiapp system. Previously, having two multiapps just ran one multiapp twice!Now the
FoamInterfaceclass is gone, member functions interfacing solver/solution properties have been moved toFoamSolver. A new class,FoamRuntime, has been added, which is responsible for creating theFoam::argList, which initialises OpenFOAM. It keeps a hold of the OpenFOAM command line arguments that we generate and makes sure the pointers to them we pass to OpenFOAM don't go invalid.To test that we can use two multiapps at once, a new test is added
multiapps/simplified_heat_exchanger(another example taken from preCICE), that contains two OpenFOAM fluid domains.I have also unset
FOAM_SIGFPE&FOAM_SETNANin the CI, so I don't have to keep remembering to add dummy variables to input files.Related Issue
Refs #25
Checklist