Add support for implicit coupling of Lagrangian particles#405
Add support for implicit coupling of Lagrangian particles#405mike-tree-corvid wants to merge 25 commits into
Conversation
OpenFOAM native PatchInjection class will stop Lagrangian particle injection once the total accumulated mass is reached, but we cannot reset this accumulated mass count when we checkpoint the Lagrangian particle cloud object because the InjectionModel class where the accumulated mass value resides hides the value in protected memory. Unless we do something an implicit coupling loop with 10 iterations may stop injecting particles 10x sooner than it should in simulation time. So, we create a copy of the patchInjection class called implicitPatchInjection and overwrite the accumulated mass that must be reached in order to turn off the injection to infinity. This leaves the time at which injection will stop entirely dependeny on the SOI and duration value sent in constant/kinematicCloudProperties
|
This pull request has been mentioned on preCICE Forum on Discourse. There might be relevant details there: |
There was a problem hiding this comment.
Thank you for the PR! I know this is still a draft, but you might be interested in some comments already.
How could I reproduce the original issue and verify the fix? Could we also add the respective case as a tutorial, so that we can integrate it into the system tests?
Happy to integrate this in a next release. We are very close to releasing v1.4.0, so I would rather postpone it. But we could make another release for this feature once it is integrated.
Note that you can use pre-commit to format the code: https://github.com/precice/openfoam-adapter/blob/develop/CONTRIBUTING.md#code-formatting
There was a problem hiding this comment.
Do you have an impression at the moment of which versions of OpenFOAM this currently builds with? We currently document support of the adapter back to v1812: https://precice.org/adapter-openfoam-support.html
We could raise that to v1912 (Ubuntu 22.04) or v2212 (Ubuntu 24.04) soon.
We would later also need to port to the latest Foundation version (but we are currently behind on that matter).
There was a problem hiding this comment.
I'm using v2412, so I know it works with that. I've never ported anything to the Foundation version, but I know the differences between the two code bases has grown recently. I hope this doesn't prove too much of a struggle.
| Copyright (C) 2021 OpenCFD Ltd. | ||
| ------------------------------------------------------------------------------- | ||
| License | ||
| This file is part of OpenFOAM. |
There was a problem hiding this comment.
Is it, or is it your code? We would need some history (e.g., based on ... from version ..., with extensions ...).
That would also make reviewing easier.
There was a problem hiding this comment.
You're right. It is my code, so i added a copyright to my company and changed the .H file description to no longer be a direct copy of OpenFOAM's native PatchInjection.H
the license statement update description of implicitPatchInjection.H to match what it truly does instead of a copy of PatchInjection.H description
The sim I'm currently running this on is coupling two 60 million cell meshes and uses an in-house solver. I don't think it's something that will work as a tutorial. It appears that another preCICE user may have a case that is more suitable for tutorial use: If the adapted perpendicular flap case isn't shareable for any reason, I'll see if I can drum up a much smaller and completely open test case that we can use for a tutorial and continuous code verification. |
states that exist more than one timestep before current, thus enabling preCICE implict coupling time windows larger than one time step
…oneNozzleInjection type
…; cloud types now include basicKinematic, basicKinematicColliding, and basicThermo
…ction; cloud types now include basicKinematic, basicKinematicColliding, and basicThermo
…hermoCloud, and basicKinematicCollidingCloud types; uses macros
|
I added a draft tutorial pull request to the precice/tutorials repo here: |
…n pre-commit is almost comical
…e an implicitInjectionWrapper that now handles creating "implicit" versions of all native OpenFOAM injection models
MakisH
changed the title
MakisH
left a comment
MakisH
left a comment
There was a problem hiding this comment.
Thank you for all the updates! I am slowly catching up with the context. Having two motivated users needing this feature is already quite a good reason to integrate this feature.
I am still just thinking how we could make it easier to disable it, in case we cannot maintain it or port it to different versions in the future, since it is adding quite some dependencies.
All system tests but one pass: The elastic-tube-3d (OpenFOAM-FEniCS) reports some regressions in the first iterations, but this seems to be a known unrelated issue (precice/tutorials#393). The OpenFOAM-CalculiX case of the same tutorial passes.
| -lreactionThermophysicalModels \ | ||
| -lthermophysicalProperties \ | ||
| -lregionFaModels \ | ||
| -lfiniteArea \ |
There was a problem hiding this comment.
I am afraid I know the answer, but: Are all of these includes and linking options really needed in the main Make/options, or some of them only in the implicitInjectionWrapper/Make/options?
If we could modularize this feature (ideally with macros to enable/disable it) and make the dependencies optional, I would feel a bit more confident that we can maintain it in the long term and for different versions.
There was a problem hiding this comment.
Yes, unfortunately they are all necessary. Lagrangian particle considerations touch a lot. I'll see if I can find an easy way to enable / disable these additions...
There was a problem hiding this comment.
I used #ifdef statements to modularize the Lagrangian particle support within the Adapter.C and Adapter.H files. I then added variables so the Make/options files is dynamically modified. Allwmake is updated to look for the presence of an "ADAPTER_ENABLE_LAGRANGIAN" environment variable. If ADAPTER_ENABLE_LAGRANGIAN=1 then -DADAPTER_ENABLE_LAGRANGIAN is added to ADAPTER_CFLAGS and the implicitInjectionWrapper code will be built. If ADAPTER_ENABLE_LAGRANGIAN does not exist or is equal to something other than 1, then neither of these things happen.
…citConeNozzleInjection builds becuase we refactored and now use implicitInjectionWrapper
… to checkpointing before the first setupCloudType call
…ode in doc string
…ve a much smaller macro
… and Adapter.H files as well as whether to build the independent implicitInjection library
3 participants
Added checkpointing for Lagrangian particles within the preCICE adaptor. When a time-rewind is detected the adapter clears the kinematicCloud state from the mesh at the end of the time window and restores the kinematicCloud state from the beginning of the time window to the mesh.
However, the preCICE adapter is a function object that operates at the global mesh level and cannot access the protected memory accumulators within OpenFOAM's native InjectionModel that govern if and how many particles are injected. So, in order to completely reset the sim and properly adjust active particle injection an additional library was created. The library, implicitPatchInjection, was created to gain protected access to these variables and override the native prepareForNextTimeStep method allowing for safely wiping the injector's memory and state caches to reset injection. To employ this properly the user will need to load the implicitPatchInjection library in system/controlDict and then swap their injectionModel type to "implicitPatchInjection" in constant/kinematicCloudProperties
This addition only supports basicthermoCloud types and patchInjection -> implicitPatchInjection injection types. Other cloud types not supported include: kinematicCloud, reactingCloud, reactingMultiphaseCloud, collidingCloud, MPPICCloud. Other injection models that cannot be replaced with implicitPatchInjection include: coneInjection, solidConeInjection, cellZoneInjection, manualInjection, surfaceFilmInjection, and fieldActivatedInjection.
TODO list:
docs/changelog-entries/(create directory if missing)