Advanced stateful material restart

[loganharbour]

This supports restarting and adding/removing stateful properties

Closes #25840

[moosebuild]

Job Documentation on 209a0e3 wanted to post the following:

View the site here

This comment will be updated on new commits.

[hugary1995]

I was looking for a markdown file but couldn't find one... Just to clarify this PR addresses adding/removing property but doesn't enable the usage of something like "block-restricted" restart, am I right?

[loganharbour]

Just to clarify this PR addresses adding/removing property

correct

but doesn't enable the usage of something like "block-restricted" restart, am I right?

it doesn't, but I could think about that.can you provide more detail?

[hugary1995]

Yeah, one of our collaborators wanted to do checkpoint and restart, and they want to keep adding new blocks to the mesh as they restart. The common blocks between the old mesh and the new mesh are always conformal, i.e. same equation system, same material storage etc.

I think in theory we can support that by asking the user to specify which blocks (from the checkpoint) to restart from. Or more generally speaking, there could be two symmetric parameters blcoks_from and blocks_to.

I hope I explained the usage scenario I had in mind clearly enough... Let me know if otherwise.

I've told our collaborators some workarounds. But this will be a useful capability to have in the future.

[moosebuild]

Job Coverage on 209a0e3 wanted to post the following:

Framework coverage

	c7df31	#26680 209a0e
	Total	Total	+/-	New
Rate	85.29%	85.30%	+0.01%	95.38%
Hits	100942	101062	+120	227
Misses	17409	17419	+10	11

Diff coverage report

Full coverage report

Modules coverage

Porous flow

	c7df31	#26680 209a0e
	Total	Total	+/-	New
Rate	95.35%	95.35%	+0.00%	100.00%
Hits	11251	11252	+1	1
Misses	549	549	-	0

Diff coverage report

Full coverage report

Solid mechanics

	c7df31	#26680 209a0e
	Total	Total	+/-	New
Rate	84.88%	84.75%	-0.13%	100.00%
Hits	27134	27086	-48	2
Misses	4835	4874	+39	0

Diff coverage report

Full coverage report

Xfem

	c7df31	#26680 209a0e
	Total	Total	+/-	New
Rate	82.27%	82.25%	-0.02%	-
Hits	6836	6834	-2	0
Misses	1473	1475	+2	0

Diff coverage report

Full coverage report

Full coverage reports

Reports

• framework
• chemical_reactions
• combined
• contact
• electromagnetics
• external_petsc_solver
• fluid_properties
• fsi
• functional_expansion_tools
• geochemistry
• heat_transfer
• level_set
• misc
• navier_stokes
• optimization
• peridynamics
• phase_field
• porous_flow
• ray_tracing
• rdg
• reactor
• richards
• scalar_transport
• solid_mechanics
• solid_properties
• stochastic_tools
• thermal_hydraulics
• xfem

This comment will be updated on new commits.

[dschwen]

I'm working on fixing the ComputeElasticityTensorCP issue. Should I add my commits to this branch?

[loganharbour]

Yeah, one of our collaborators wanted to do checkpoint and restart, and they want to keep adding new blocks to the mesh as they restart. The common blocks between the old mesh and the new mesh are always conformal, i.e. same equation system, same material storage etc.

I think in theory we can support that by asking the user to specify which blocks (from the checkpoint) to restart from. Or more generally speaking, there could be two symmetric parameters blcoks_from and blocks_to.

I hope I explained the usage scenario I had in mind clearly enough... Let me know if otherwise.

I've told our collaborators some workarounds. But this will be a useful capability to have in the future.

@hugary1995 in regard to this conversation, there's nothing stopping us now from adding additional blocks and just initializing the stateful data for those new blocks as new data, while retaining the old ones. There's an error in place for now because it's ambiguous, but we could enable this capability by just providing a list of material objects or material parameters that would be allowed to add new (clean) information while retaining old.

[loganharbour]

@dschwen This is ready. All of the failures but one are due to the solid mechanics rename.

[YaqiWang]

Griffin just needs a regolding because of this commit 72b37d4.

[loganharbour]

@dschwen please. Griffin patch is near

[YaqiWang]

@dschwen please. Griffin patch is near

Griffin patch is ready. All tests passed. When this is merged, we will just need to replace the MOOSE submodule hash.

[moosebuild]

Job Valgrind stochastic tools on 209a0e3 : invalidated by @lindsayad

[moosebuild]

Job OpenMPI on 209a0e3 : invalidated by @lindsayad