Add ability to do recover with MFEM#32736
Draft
lindsayad wants to merge 30 commits intoidaholab:nextfrom
Draft
Conversation
Introduce explicit FEProblemBase add hooks for MFEM FESpaces, submeshes, solvers, preconditioners, and MFEM submesh transfers so the MFEM action layer follows the same registerBase/syntax/action/addFoo pattern used by other object families. Update MFEMProblem to construct these MFEM system objects through addObject<...> and retrieve them from the warehouse by their real registered system instead of routing them through addUserObject as a generic backing layer. This covers the MFEM problem-side setup for FESpaces, submeshes, solvers, preconditioners, submesh transfers, kernels, boundary conditions, functor materials, indicators, markers, and MFEM variables. Normalize complex kernel insertion by making MFEMComplexKernel derive from MFEMKernel, which lets the kernel setup path stay on typed warehouse storage without falling back to the old user-object path. Refs idaholab#31434 Co-authored-by: OpenAI Codex <codex@openai.com>
Introduce a lightweight MFEMObject base for non-executed MFEM system objects so they no longer inherit user-object execution machinery just to access MFEMProblem state and shared helper interfaces. Migrate the non-executed MFEM families onto this base, including kernels, boundary conditions, FE spaces, variables, solvers, submeshes, functor materials, indicators, and refinement markers. Keep executed MFEM classes such as auxkernels, postprocessors, vector postprocessors, initial conditions, and MFEMSubMeshTransfer on MFEMGeneralUserObject for now. Update the converted classes to register their warehouse system attribute names explicitly so they can be stored and queried directly from TheWarehouse under their real systems instead of piggybacking on UserObject storage. Adjust the marker lookup to fetch its indicator through MFEMProblem warehouse queries, and remove stale MFEMGeneralUserObject-only includes/comments from the non-executed path. Refs idaholab#31434 Co-authored-by: OpenAI Codex <codex@openai.com>
Move MFEM initial conditions, aux kernels, submesh transfers, postprocessors, and vector postprocessors onto a shared MFEMExecutedObject base backed directly by MooseObject instead of the libMesh/MOOSE user-object stack. This introduces an MFEM-owned executed-object scheduling path in MFEMProblem. Executed MFEM objects are now collected from the warehouse by MFEM-specific system name, dependency ordered from the resources they produce and consume, and then initialized/executed/finalized explicitly. Variable, postprocessor, and vector-postprocessor dependencies now provide the ordering signal that used to be expressed through execution_order_group. As part of that split, MFEMGeneralUserObject is removed entirely. The executed MFEM families no longer inherit GeneralUserObject machinery, and the MFEM docs and test inputs are updated to reflect the new dependency-driven model rather than user-object execution groups. The refactor also adapts the framework touch points that previously assumed MFEM PP/VPP objects were user objects. AdvancedOutput now discovers MFEM postprocessors and vector postprocessors from their own warehouse systems, FEProblemBase and VectorPostprocessorInterface can resolve MFEM vector postprocessors by PPName(), and MFEMProblem finalizes MFEM PP/VPP reporter data in its explicit execution pass. Non-MFEM postprocessors and vector postprocessors in an MFEMProblem still go through the normal framework add path, while MFEM-native PP/VPP objects use the new MFEM executed-object machinery. Refs idaholab#31434 Co-authored-by: OpenAI Codex <codex@openai.com>
Co-authored-by: Codex <codex@openai.com>
Update MFEM base header documentation and small API cleanup. - add doxygen coverage for the non-override MFEMObject and MFEMExecutedObject APIs - document the MFEM executed-object dependency metadata structures - remove unnecessary interface using-declarations from MFEMObject These changes are limited to framework/include/mfem/base/MFEMObject.h and framework/include/mfem/base/MFEMExecutedObject.h. Co-authored-by: OpenAI Codex <codex@openai.com>
Tighten the MFEM executed-object cache and naming cleanup around the ongoing warehouse-backed refactor. This updates MFEMExecutedObject to lazily build requested/supplied dependency sets, switches it over to getParam-based access, and adds missing doxygen on MFEMProblem and FEProblemBase helper APIs touched by this work. On the MFEM problem side, remove immediate warehouse round-trips after addObject() where the returned shared_ptr is already sufficient, and simplify a few remaining shared_ptr casts. Also replace misleading UserObjectName parameters used for MFEM-specific systems with dedicated derivative string classes: - MFEMFESpaceName for MFEM FESpace references - MFEMSolverName for MFEM solver/preconditioner references The new MFEM name types are registered with the parser/JSON machinery, and the affected MFEM variables, solvers, indicators, problem helpers, and unit tests are updated accordingly. Co-authored-by: OpenAI Codex <codex@openai.com>
Contributor
|
Job Documentation, step Docs: sync website on cf64c6e wanted to post the following: View the site here This comment will be updated on new commits. |
Contributor
|
Job Coverage, step Generate coverage on cf64c6e wanted to post the following: Framework coverageMutiple base shas were found when retrieving head reports: Modules coverageCoverage did not change Full coverage reportsReports
This comment will be updated on new commits. |
refs idaholab#30076 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Route checkpoint mesh writing through MooseMesh and revert\nusing RestartableData for MFEM mesh recovery.\n\nCo-authored-by: OpenAI Codex <codex@openai.com> refs idaholab#30076
This allows the nl_heatconduction.i test to pass with uniform_refine instead of serial_refine
We already check in MFEMProblem::addKernel that we have a complex equation system when MFEMComplexKernels are present. I don't think there's a real reason to ban complex aux components when all the solve parts are real. One could decompose their solver into real components and then synthesize the complex aux solution afterwards
lindsayad
force-pushed
the
mfem-recover-30076
branch
from
ea38676 to
a1bca1b
Compare
Contributor
|
Job Precheck, step Clang format on a1bca1b 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:
|
lindsayad
force-pushed
the
mfem-recover-30076
branch
from
a1bca1b to
3444509
Compare
lindsayad
force-pushed
the
mfem-recover-30076
branch
from
3444509 to
cf64c6e
Compare
Contributor
|
Job Test, step Results summary on cf64c6e wanted to post the following: Framework test summaryCompared against e2d94b0 in job civet.inl.gov/job/3728495. Added tests
Modules test summaryCompared against e2d94b0 in job civet.inl.gov/job/3728495. No change |
Contributor
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
2 participants
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.
Refs #30076