idaholab
Add a positions object with a parsed selection criterion
Thoughts on this?
Seems like it could be useful. But it does not quite do what the user wanted (material properties) here: https://github.com/idaholab/moose/discussions/30765 It's inspired from that need though.
Edit: actually using the auxvariable output of the property, this does work for matprops
name could be ElementParsedSelectionPositions instead since it keeps the element centroid positions or we could add (in the future) an argument to decide the type of loops (nodal, Qps, faces, ...)
Job Documentation, step Docs: sync website on cd8f5eb wanted to post the following:
View the site here
This comment will be updated on new commits.
Job Coverage, step Generate coverage on cd8f5eb wanted to post the following:
Framework coverage
| 98f5d7 | #30767 cd8f5e | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 85.47% | 85.50% | +0.03% | 91.93% | |
| Hits | 114883 | 114947 | +64 | 148 | |
| Misses | 19525 | 19494 | -31 | 13 | |
Modules coverage
Optimization
| 98f5d7 | #30767 cd8f5e | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 88.20% | 88.19% | -0.01% | 100.00% | |
| Hits | 1966 | 1956 | -10 | 2 | |
| Misses | 263 | 262 | -1 | 0 | |
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 -
subchannel -
thermal_hydraulics -
xfem
This comment will be updated on new commits.
git s buggy so replying here
: We already have a quadraturePointPositions btw. We could add an option to this ParsedPositions to be able to down-select from an existing Positions object .
Otherwise it feels a bit like adding code just because we can
Every system ought to have parsed capabilities imo. It's just so much more flexible and helps no-code users of our software.
Can we make a helper function somewhere to help reduce the number of times we repeat this pattern? There is certainly some variation throughout these grep match occurrences but maybe the helper function could take arguments that support those variations
seems tough with the number of attributes that may not be shared by all these objects. I ll take a look. I think all these attributes can then just be parameters of the utility, along with a bunch of booleans to enable/disable things
Otherwise it feels a bit like adding code just because we can
Every system ought to have parsed capabilities imo. It's just so much more flexible and helps no-code users of our software.
Sure but this is adding a very particular parsed capability type of positions: element centroids. Has a user asked for that particular type of positions?
or we could add (in the future) an argument to decide the type of loops (nodal, Qps, faces, ...)
Why future and not now? Then we would be adding a flexible parsed positions object that potentially addresses an immediate user need
Users need are met outside of moose fairly easily in that thread.
I think my new idea (use this to downselect) is pretty good I'll implement that
Not done with addressing the review but the new design is online now if you want to take a look. I think the added generality and capability is worth the new object now
Well the testing is failing in parallel because of ghosting issues. Instead of adding my semiverify check that can be avoided by just evaluating for a given element if (elem->processor_id() == this->processor_id()). Then there are no ghosting issues, you only evaluate the function on one rank for a given element, and then logically there is no chance for a disagreement between ranks
Yup that's a good idea. I was thinking we would need algebraic ghosting to always match geometric ghosting otherwise. And the potential for disagreement seals the deal.
I think I should still have code to make the point locator consider multiple elements, in case someone uses this at nodes