moose
moose copied to clipboard
idaholab
Add Physics base class and a heat conduction example
Open for comments. Once the dependent PRs are in, this could actually be merged refs https://github.com/idaholab/moose/issues/25642 see original PR https://github.com/idaholab/moose/pull/25704
I dont think the syntax has been decided yet, so I m open to a CCB meeting on this
Currently the Physics base class only implements:
- some basic parameter checking
- an insertion point for relationship managers at the equation level (could be removed for now, will come in for NS)
- an insertion point for restarting from Exodus (could be removed for now, will come in for NS)
Job Documentation on bd7ff03 wanted to post the following:
View the site here
This comment will be updated on new commits.
Job Coverage on bd7ff03 wanted to post the following:
Framework coverage
| 796cb8 | #25977 bd7ff0 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 85.24% | 85.20% | -0.04% | 74.95% | |
| Hits | 99138 | 99509 | +371 | 377 | |
| Misses | 17166 | 17283 | +117 | 126 | |
Modules coverage
Heat transfer
| 796cb8 | #25977 bd7ff0 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 88.28% | 88.16% | -0.11% | 83.49% | |
| Hits | 3938 | 4029 | +91 | 91 | |
| Misses | 523 | 541 | +18 | 18 | |
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_properties -
stochastic_tools -
tensor_mechanics -
thermal_hydraulics -
xfem
Warnings
-
frameworknew line coverage rate 74.95% is less than the suggested 90.0% -
heat_transfernew line coverage rate 83.49% is less than the suggested 90.0%
This comment will be updated on new commits.
Should probably move this forward. It doesnt have to be merged right right now, we could also wait until I dig deep into Component as Actions and assess if this is going to change the deal for Physics. I dont expect it to. But work on syntax for Components as Actions could enable interesting syntax for Physics.
The thing that came to my mind is DiffusionPhysics or PoissonPhysics. @nmnobre just recently created a coupled_elestrostatics.i framework level test in his Raviart-Thomas PR.... It could be a good demonstration of Physics to make both CFEM and Raviart-Thomas implementations of the Poisson equation.... Although I can't remember if you wanted Physics to be useful for the purpose of allowing different algebraic discretizations of the same physics. Also you probably don't want to balloon this PR too much, so maybe just a CFEM implementation of Poisson would be good to start, and then we could add RT later.
I thought we had an issue where we had a pretty large community (I thought it involved @dschwen at least) discussion about the Physics class but maybe i've lost my marbles. #25642 doesn't seem like it.
A lot of the discussion is on the original Physics PR https://github.com/idaholab/moose/pull/25704
wanted Physics to be useful for the purpose of allowing different algebraic discretizations of the same physics
I do want that. I dont think it s feasible to do a [Discretization] block with our current ways of parsing the input file without being very convoluted. So I think when we instantiate a Physics object in the input file, it should have the discretization as well
A lot of the discussion is on the original Physics PR #25704
Ah there it is, thanks
Added a FV and CG example in the framework. might not pass tests yet. I did not make it as simplistic as I would have hoped. I think these objects should be fairly optimized.
I did some timing in devel and it seems that I was losing 10% performance with full functors. So I made the Physics use the best object for every input
Now in opt I'm not seeing much but I m not done timing
Timings (I ll update this post)
| Diffusion | mamba-libmesh | opt executable | Other cases |
|---|---|---|---|
| 8 cores | |||
| 100k elems r-6 | 110k dofs | 400k - r7 | |
| FV | MOOSE-default PC | ||
| full scalar | full variables | functors | |
| 37s | 37s | 37s | |
| CG - AD | |||
| full scalar | full variables | ||
| 29s | 30.5s | ||
| no AD | |||
| full scalar | full variables | ||
| 23s | 28s | ||
| Physics-default PC | |||
| CG - AD | noAD | ||
| full scalar | full variables | full variables | |
| 24.163s | 1 min 2s | ||
| LU - mumps | 400k - r7 | ||
| CG - AD | noAD | ||
| full scalar | full variables | full variables | |
| 24s | 1m19.837s |
Overall design looks good to me. I wish the syntax could be
[Physics]
[diff]
type = DiffusionFE
instead of
[Physics]
[DiffusionFE]
[diff]
but I believe we've decided that Action is the right approach, which I think constrains the syntax to as you have.
Let me know when this is ready for a thorough review. I'll have a lot of requests for documentation, but I'd probably just have us fix anything wrong and then I can do a follow-up PR to improve the documentation to my satisfaction, and you can review that.
Oh, one thing I forgot: do you have a working example (not necessary to be in this PR) with the integration of this design with Components?
Oh, one thing I forgot: do you have a working example (not necessary to be in this PR) with the integration of this design with Components?
other PR https://github.com/idaholab/moose/pull/25704
but I believe we've decided that Action is the right approach, which I think constrains the syntax to as you have.
yes. And having type= forward to an action is difficult.
There are several routes:
Parsing the input file and recognizing actions from the syntax. This becomes difficult for:
[Physics]
[NavierStokes]
type = FV
[Energy]
to pick an NSFVEnergy action, this is some multi-line parsing which we do not have
Or create a ActionCreationAction action that just reads parameters.
type = NavierStokesWCNSFVEnergy
the problem with that, is that:
- we need a lot of new meta action code to make an action-creating action work (need to register tasks on the fly for example)
- we need to rework the syntax auto-complete to be able to find the action parameters more like an object
Another option is this
[Physics]
[name1]
type = NavierStokes
discretization = FV
equation = energy
[]
[]
but then it s even more complicated for parameter auto-complete. We need to parse parameters to know what the other parameters are
Let me know when this is ready for a thorough review. I'll have a lot of requests for documentation, but I'd probably just have us fix anything wrong and then I can do a follow-up PR to improve the documentation to my satisfaction, and you can review that.
Alex has been thoroughly reviewing this. I dont think there is anything left wrong! He did catch a lot of wrong things
I dont think there is anything left wrong! He did catch a lot of wrong things
Oh don't worry, there's wrong stuff still. But just doc/typos so far 😄
noice thanks a lot for the reviews. Merging so it makes the newsletters
now for the tough part. NS, TM and THM