Enable MultiApp transfers between MFEM and libMesh problems on CPU#32315
Conversation
9d7807b to
a2fc66d
Compare
5087a0c to
5ceba23
Compare
a256a01 to
791693c
Compare
|
Job Documentation, step Docs: sync website on 58a80e6 wanted to post the following: View the site here This comment will be updated on new commits. |
a33274f to
da45066
Compare
|
Job Coverage, step Generate coverage on 58a80e6 wanted to post the following: Framework coverage
Modules coverageCoverage did not change Full coverage reportsReports
This comment will be updated on new commits. |
||||||||||||||||||||||||||
bcdd203 to
8c12ff0
Compare
8c12ff0 to
3057f8e
Compare
1 similar comment
9f5bdad to
1dbcc43
Compare
|
Job Disable HDF5 on 1dbcc43 : invalidated by @loganharbour |
08dd19f to
7f1c81f
Compare
7f1c81f to
e4c4583
Compare
1b3394d to
c1f2cf7
Compare
|
Job Precheck, step Clang format on c1f2cf7 wanted to post the following: Your code requires style changes. A patch was auto generated and copied here
Alternatively, with your repository up to date and in the top level of your repository:
|
…nsfer loops, and fix docstrings
c1f2cf7 to
d5fab83
Compare
lindsayad
left a comment
There was a problem hiding this comment.
I'm giving my approval contingent on my one remaining conversation being resolved, tests passing, and Nuno's review being met 😄
e82400e to
d6febef
Compare
17ee24c to
4d11729
Compare
…uationTransfer and add 1-to-N test
4d11729 to
25b8962
Compare
nmnobre
left a comment
There was a problem hiding this comment.
One question:
- What's the reason for using a different idiom to get libMesh's system in the libMesh->MFEM vs MFEM->libMesh transfer implementations?
One commit: nmnobre@5c259a0
- Fixes a time section's (now) outdated description and a few of comments
- Swaps the switch stmts with loops (sorry I didn't suggest this last time)
- Reorders/simplifies some loop/if statements to reuse work or for early exit
- Replaces
getProblemData().cmplx_gridfunctions.Get()idioms withgetComplexGridFunction() - Replaces
dynamic_cast<MFEMProblem *>()withstatic_cast<MFEMProblem &>()where we already know it's safe to do so - Removes trailing whitespace in the tests file
nmnobre
left a comment
There was a problem hiding this comment.
Though noting I'd like an answer above for completeness, I'm happy with this now.
Thanks for this Alex, very nice work.
In the future, besides the many-to-many transfers, it'd be cool if we could hide the type of transfer from the user, e.g. if the user wants a shape evaluation transfer, perhaps we could determine programatically if it needs to be libMesh->MFEM or MFEM->libMesh or MFEM->MFEM or libMesh->libMesh? Just a thought.
This could be changed - the reasons are historic. The
Since |
Co-authored-by: Nuno Nobre <nuno.nobre@stfc.ac.uk>
|
Job Test, step Results summary on 58a80e6 wanted to post the following: Framework test summaryCompared against 953c577 in job civet.inl.gov/job/3779372. Removed tests
Added tests
Modules test summaryCompared against 953c577 in job civet.inl.gov/job/3779372. No change |
|
The sweeps should be added to anything relating to transfers, meshing, or parallel algorithms. This broke next: https://civet.inl.gov/event/292493/ |
PR to enable transfers between transfers between MFEM GridFunctions and libMesh solutions on CPU, leveraging newly added GSLib interpolators for interpolation of MFEM GridFunctions at arbitrary sets of points.
Adds three new transfer classes, for transfers between arbitrary meshes in 2D and 3D using shape function evaluations for:
The newly added MFEM to MFEM transfer class is based off the MFEM
gslib/field-interpminiapp. Interpolation and projection of libMesh variables in libMesh to MFEM and MFEM to libMesh transfers respectively is based off of existing implementations inMultiAppGeneralFieldTransferandMultiAppShapeEvaluationTransfer.Closes #31982