Skip to content

Remove foam interface singleton#41

Merged
hsaunders1904 merged 13 commits intoaurora-multiphysics:mainfrom
hsaunders1904:hsaunders1904/remove_foam_interface_singleton
Mar 7, 2025
Merged

Remove foam interface singleton#41
hsaunders1904 merged 13 commits intoaurora-multiphysics:mainfrom
hsaunders1904:hsaunders1904/remove_foam_interface_singleton

Conversation

@hsaunders1904
Copy link
Collaborator

@hsaunders1904 hsaunders1904 commented Mar 6, 2025

Summary

Removes the FoamInterface singleton, which allows us to have two Hippo multiapps in a single multiapp system. Previously, having two multiapps just ran one multiapp twice!

Now the FoamInterface class is gone, member functions interfacing solver/solution properties have been moved to FoamSolver. A new class, FoamRuntime, has been added, which is responsible for creating the Foam::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_SETNAN in the CI, so I don't have to keep remembering to add dummy variables to input files.

Related Issue

Refs #25

Checklist

  • Tests have been written for the new/changed behaviour.
  • Documentation/examples have been added/updated for the new changes.

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.
@hsaunders1904 hsaunders1904 marked this pull request as ready for review March 7, 2025 13:29
@hsaunders1904 hsaunders1904 merged commit df2a9e9 into aurora-multiphysics:main Mar 7, 2025
2 checks passed
@hsaunders1904 hsaunders1904 deleted the hsaunders1904/remove_foam_interface_singleton branch March 7, 2025 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant