moose
moose copied to clipboard
idaholab
Initial work on contact for explicit finite element dynamics
Job Documentation on 3c5651e wanted to post the following:
View the site here
This comment will be updated on new commits.
@recuero do you think it makes more sense for a mechanics person to review this or do you want me to review it?
I believe @dschwen will want to review it. I'll be happy to address your comments too.
I still need to address a threading diff on a critical time step output, which I don't know if it's related to the code in this PR.
still need to address a threading diff on a critical time step output, which I don't know if it's related to the code in this PR.
If you want any help looking at this let me know. Is it repeatable?
It seems repeatable. I haven't looked into it yet. I have a small suspicion that we may be summing the output of threads instead of just getting the minimum. I'll ping you if I can't figure it out, thanks!
Job Coverage on 3c5651e wanted to post the following:
Framework coverage
| 1ac1dd | #26073 3c5651 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 85.29% | 85.29% | -0.00% | 82.35% | |
| Hits | 100826 | 100890 | +64 | 84 | |
| Misses | 17388 | 17401 | +13 | 18 | |
Modules coverage
Contact
| 1ac1dd | #26073 3c5651 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 90.31% | 90.44% | +0.13% | 91.70% | |
| Hits | 4456 | 4931 | +475 | 475 | |
| Misses | 478 | 521 | +43 | 43 | |
Solid mechanics
| 1ac1dd | #26073 3c5651 | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 84.87% | 84.88% | +0.00% | 85.71% | |
| Hits | 27122 | 27134 | +12 | 12 | |
| Misses | 4834 | 4835 | +1 | 2 | |
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
Warnings
-
frameworknew line coverage rate 82.35% is less than the suggested 90.0% -
solid_mechanicsnew line coverage rate 85.71% is less than the suggested 90.0%
This comment will be updated on new commits.
My biggest concern is the poor line coverage in the framework. This reflects the leaking of the contact module into the framework. Is there something we can do about this? Perhaps add some virtual methods in NonlinearSystemBase and create a NonlinearSystem derived class in the contact module? That's just a spitball.
My smaller concern is the proliferation of writable variables through different systems in MOOSE
Perhaps add some virtual methods in NonlinearSystemBase and create a NonlinearSystem derived class in the contact module?
That'll fix the coverage issue. We'd need to create that contact-specific nonlinear system from the framework, I believe. Maybe with CONTACT_ENABLED macros? There may be a better solution, I don't like the one I just thought of.
An alternative way of looking at this is that contact, just now, requires additional, general capabilities. That 'overwrite' method is probably not that different in nature from presetting Dirichlet BCs? Maybe cooking up a test in the framework to cover that code would be enough?
That'll fix the coverage issue. We'd need to create that contact-specific nonlinear system from the framework, I believe. Maybe with
CONTACT_ENABLEDmacros? There may be a better solution, I don't like the one I just thought of.
Definitely don't want to do macros. I would be in favor of something more _factory and MooseObject based, e.g. make Systems moose objects that can be easily derived from and buildable by the factory. This would allow users to create arbitrary Systems in their modules/applications without the framework needing the details, just like our other systems (using lower case systems here to mean systems like Kernels, BoundaryConditions, etc.)
An alternative way of looking at this is that contact, just now, requires additional, general capabilities. That 'overwrite' method is probably not that different in nature from presetting Dirichlet BCs? Maybe cooking up a test in the framework to cover that code would be enough?
Yes if you can make framework level tests for the framework code you've added then I would be supportive of keeping the new code in the framework
It seems like the balance tests might be a little long for dbg. Might be an intermittent failure:
[299.9s] TIMEOUT contact/test:explicit_dynamics.test_balance FAILED (TIMEOUT) [previous results: TIMEOUT,FINISHED]
[300.0s] TIMEOUT contact/test:explicit_dynamics.test_balance_overwrite FAILED (TIMEOUT) [previous results: TIMEOUT,FINISHED]
@recuero please review my commits and see what you think. I'll see how testing does. If something fails from my changes I will fix it
I've reviewed the framework pieces. @dschwen I'll let you review the contact pieces