[WIP] Make geometric calculations more generic #2396

lindsayad · 2020-01-06T15:44:46Z

Classes that need to be templated:

Other To-Do items:

Compile
Unit tests
Fix merge conflicts
Have someone review/approve this monstrosity

We'll have to talk about what we want to do for backwards compatability.

Closes #2121

roystgnr · 2020-01-06T23:25:58Z

"Work in progress" means I can merge #2395 and undercut all your hard work without feeling too guilty?

lindsayad · 2020-01-06T23:32:38Z

Sigh...haha yes go ahead.

roystgnr · 2020-01-06T23:34:35Z

Ouch, I barely changed browser tabs before github started yelling at us here about conflicting files.

Sorry about the hassle. On the bright side, the expanded unit test coverage should make it easier to do this work without regressions!

roystgnr · 2020-01-07T15:55:52Z

@jwpeterson pointed out to me that our _impl.h convention (where most users don't need to include them because we instantiate the common case(s) manually) isn't intuitively obvious. Let's come up with some boilerplate comment to document that convention in the _impl.h headers as part of this PR, then when we're happy with that we can add it to the existing dense_matrix*_impl.h headers too?

lindsayad · 2020-01-07T16:14:15Z

Sounds good to me

jwpeterson · 2020-01-08T17:48:48Z

So @lindsayad I think you are going to have to template every class in libmesh, like EquationSystems, System, etc.? I'm starting to get scared.

lindsayad · 2020-01-08T18:06:46Z

So @lindsayad I think you are going to have to template every class in libmesh, like EquationSystems, System, etc.? I'm starting to get scared.

Haha, this is why I threw this up here (with a WIP label) so that you guys could give your input as I go. So I think that I should only have to class template geometric entities. Algebraic entities should escape relatively unscathed, except that algebraic class methods which include geometric entities in their argument list will probably have to become templated; you can see d2b9728 for an example of this. If an algebraic class has a geometric entity as a data member or a method with a geometric return type that is unrelated to the argument list (e.g. I wouldn't be able to deduce a function template argument from the function args), then I have to get a little more clever. So for the DofMap for example, I ended up creating a MeshGhosting class which MeshBase inherits from that contains the APIs that the DofMap needs to use and then changed the DofMap::_mesh data member to be of MeshGhosting type.

I've been thinking about how to do this with any less work (and any less destruction) than what I've been doing but so far I've yet to have any bright ideas.

lindsayad · 2020-01-29T23:19:02Z

I never thought I'd see the day...my branch compiles!!! Now of course compiling a RealType = DualNumber unit test...that will be the next battle

lindsayad · 2020-02-04T03:14:31Z

Has anyone ever seen an error like this before?

In file included from ../include/libmesh/dof_map_impl.h:40,
from ../include/libmesh/instantiate_real_type.h:22,
from /home/lindad/projects/moose/scripts/../libmesh/tests/ad/geometric_ad_test.C:2:
/home/lindad/projects/moose/scripts/../libmesh/contrib/timpi/src/algorithms/include/timpi/parallel_sync.h:502:6: error: ‘void TIMPI::push_parallel_vector_data(const TIMPI::Communicator&, const MapType<unsigned int, std::__debug::vector<std::__debug::vector<ValueType, A1>, A2>, ExtraTypes ...>&, const ActionFunctor&) [with MapType = std::__debug::map; ValueType = std::pair<unsigned int, double>; A1 = std::allocator<std::pair<unsigned int, double> >; A2 = std::allocator<std::__debug::vector<std::pair<unsigned int, double> > >; ExtraTypes = {std::less, std::allocator<std::pair<const unsigned int, std::__debug::vector<std::__debug::vector<std::pair<unsigned int, double>, std::allocator<std::pair<unsigned int, double> > >, std::allocator<std::__debug::vector<std::pair<unsigned int, double>, std::allocator<std::pair<unsigned int, double> > > > > > >}; ActionFunctor = libMesh::DofMap::allgather_recursive_constraints(libMesh::MeshBaseTempl&) [with RealType = MetaPhysicL::DualNumber<double, MetaPhysicL::DynamicSparseNumberArray<double, unsigned int> >]::<lambda(libMesh::processor_id_type, const std::__debug::vector<std::__debug::vector<std::pair<unsigned int, double> > >&)>]’, declared using local type ‘const libMesh::DofMap::allgather_recursive_constraints(libMesh::MeshBaseTempl&) [with RealType = MetaPhysicL::DualNumber<double, MetaPhysicL::DynamicSparseNumberArray<double, unsigned int> >]::<lambda(libMesh::processor_id_type, const std::__debug::vector<std::__debug::vector<std::pair<unsigned int, double> > >&)>’, is used but never defined [-fpermissive]

Used but never defined...I don't get it. There's clearly a definition for the template TIMPI::push_parallel_vector_data and you can't declare a lambda without a definition...

lindsayad · 2020-02-04T17:54:36Z

I'm seeing two paths forward with this:

Don't template algebraic classes at all. This would essentially necessitate the user always having two meshes (which is what MOOSE does) and the algebraic objects (EquationSystems, System, DofMap) would always interact with the non-displaced mesh. This would lead to a lot less content in this PR, but would make it rather inconvenient to query the displaced mesh's elements and nodes for dof information.
Basically template the whole world, e.g. template EquationSystems, System, DofMap. I don't think it makes sense to just say template EquationSystems because then System would have to get_equation_systems().get_mesh() in order to get a complete mesh object (e.g. not some dumbed-down base class object that you can't query for elements/nodes etc.)

I'm leaning towards 2 because it is more consistent with the current conceptual libMesh model which is that a mesh is paired with an EquationSystems object and its associated Systems/DofMaps. But this will be more disruptive to the libMesh code base. No matter what, I don't think we're going to want to merge this into master for a while...I'm doing all this work so that we can get more accurate/perfect Jacobians for displaced problems, but I'm not even sure if we're going to see performance gains, e.g. will a decreased non-linear iteration count offset the computational cost of sparsity computations in MetaPhysicL types? Moreover, for this to even be feasible for a large problem, we're going to have to use a dynamic derivative container type for memory reasons. And we've already seen that these containers are relatively slow (see roystgnr/MetaPhysicL#1). I (and @fdkong and @friedmud) believe we can fix this with a memory pool. That's going to be even more development time.

In summary, I think I'm going to need to:

"Complete" the content of this PR
Develop the memory pool based derivative container type in MetaPhysicL
In a branch update MOOSE to interface with the content of this PR
Run a significant amount of unit tests and legitimate physical problems in MOOSE applications
Based on those results, determine whether it's worth it to overhaul libMesh with this PR

lindsayad · 2020-02-04T18:48:06Z

On second thought, I'm leaning towards not templating algebraic objects at all. You know, Occam's Razor and stuff. Then I'd just have to do something smart for cloning DofObject information on to the displaced mesh's Nodes and Elems

roystgnr · 2020-02-04T22:22:32Z

So that "used but never defined" looks like my bug? At one point I had a KeyType parameter in the push vector specialization, but now it looks like the KeyType parameter exists in the declaration but not in the definition, and so your compiler may rightly be confused by that. Not sure why my compiler and the CI compilers haven't already hit that or how you set it off, though.

roystgnr · 2020-02-04T22:31:33Z

There's got to be a better phrase than "algebraic classes" for System/DofMap/EquationSystems ... if only because I've already abused that vocabulary in the opposite direction in parallel_algebra.h ... let me call them "system classes" for lack of a better word.

I agree with your dichotomy, and my vote would be to avoid templating the system classes if possible, and I think it would be possible, if we're willing to allow for a little dynamic_cast hackery in user space to get AD geometry when that's available.

lindsayad · 2020-02-05T02:32:38Z

There's got to be a better phrase than "algebraic classes" for System/DofMap/EquationSystems

Seemed consistent with algebraic ghosting 😅

I agree with your dichotomy, and my vote would be to avoid templating the system classes if possible, and I think it would be possible, if we're willing to allow for a little dynamic_cast hackery in user space to get AD geometry when that's available.

Cool 👍

roystgnr · 2020-02-05T14:23:15Z

Seemed consistent with algebraic ghosting 😅

Oh, well, see, there's your problem. If you try to come up with your own names then consistency is difficult, but if you try to match my naming schemes then consistency is impossible.

…oses

This is a much simpler in terms of lines of code (albeit perhaps slower) implementation of the goal of realizing geometric and finite element basis evaluations with derivative information, which has its usefulness in displaced mesh calculations. Refs libMesh#2121 libMesh#2396

…oses

This is a much simpler in terms of lines of code (albeit perhaps slower) implementation of the goal of realizing geometric and finite element basis evaluations with derivative information, which has its usefulness in displaced mesh calculations. Refs libMesh#2121 libMesh#2396

jwpeterson · 2022-03-02T20:52:36Z

This PR has been marked "do not merge" since we are no longer accepting PRs into the master branch. All new PRs should be made on the devel branch instead. Once this PR's target branch has been updated to devel, the "do not merge" label will be removed.

This is a much simpler in terms of lines of code (albeit perhaps slower) implementation of the goal of realizing geometric and finite element basis evaluations with derivative information, which has its usefulness in displaced mesh calculations. Refs libMesh#2121 libMesh#2396

lindsayad · 2023-02-04T00:33:18Z

Closing in favor of the research work on #2576

lindsayad mentioned this pull request Jan 6, 2020

WIP: Frictional mortar contact with tensor mechanics tests idaholab/moose#14241

Closed

lindsayad force-pushed the template-fe-map branch 2 times, most recently from 9cee552 to 6b825db Compare January 6, 2020 23:14

lindsayad force-pushed the template-fe-map branch from 7bf4306 to 7a3ce50 Compare January 7, 2020 15:17

lindsayad force-pushed the template-fe-map branch 4 times, most recently from db77e13 to 4305ca5 Compare January 8, 2020 02:53

lindsayad force-pushed the template-fe-map branch from c91cd08 to 76e8f66 Compare January 8, 2020 17:56

lindsayad mentioned this pull request Jan 8, 2020

AD-ify thermal expansion function methods idaholab/moose#14590

Merged

lindsayad force-pushed the template-fe-map branch 6 times, most recently from aeddc83 to 571248c Compare January 10, 2020 20:06

lindsayad mentioned this pull request Jan 14, 2020

Protect kinematic formulation against scaling effects idaholab/moose#14546

Merged

3 tasks

lindsayad force-pushed the template-fe-map branch from 42cd6c8 to 651e829 Compare January 29, 2020 23:15

lindsayad force-pushed the template-fe-map branch 2 times, most recently from 1eef47e to 730fb93 Compare February 4, 2020 01:00

lindsayad force-pushed the template-fe-map branch from 13b2d8a to 13e0dde Compare February 4, 2020 03:26

lindsayad force-pushed the template-fe-map branch from 13e0dde to dcbc7d7 Compare February 4, 2020 18:35

lindsayad added 2 commits February 4, 2020 18:31

Template geometric entities for automatic differentiation purposes

3020bd4

Create mechanical contact test exercising geometric AD

dc9097a

lindsayad force-pushed the template-fe-map branch from dcbc7d7 to dc9097a Compare February 5, 2020 02:31

lindsayad added 2 commits February 6, 2020 17:26

fixup! Template geometric entities for automatic differentiation purp…

663ca8e

…oses

fixup! Template geometric entities for automatic differentiation purp…

6252197

…oses

lindsayad mentioned this pull request Feb 9, 2020

Automatic Differentiation for geometric entities? #2121

Open

fixup! Template geometric entities for automatic differentiation purp…

8860306

…oses

lindsayad mentioned this pull request Dec 1, 2020

[WIP] AD libMesh #2576

Closed

jwpeterson added the do not merge label Mar 2, 2022

lindsayad closed this Feb 4, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Make geometric calculations more generic #2396

[WIP] Make geometric calculations more generic #2396

lindsayad commented Jan 6, 2020 •

edited

Loading

roystgnr commented Jan 6, 2020

lindsayad commented Jan 6, 2020

roystgnr commented Jan 6, 2020

roystgnr commented Jan 7, 2020

lindsayad commented Jan 7, 2020

jwpeterson commented Jan 8, 2020

lindsayad commented Jan 8, 2020

lindsayad commented Jan 29, 2020

lindsayad commented Feb 4, 2020 •

edited

Loading

lindsayad commented Feb 4, 2020 •

edited

Loading

lindsayad commented Feb 4, 2020

roystgnr commented Feb 4, 2020

roystgnr commented Feb 4, 2020

lindsayad commented Feb 5, 2020

roystgnr commented Feb 5, 2020

jwpeterson commented Mar 2, 2022

lindsayad commented Feb 4, 2023

[WIP] Make geometric calculations more generic #2396

[WIP] Make geometric calculations more generic #2396

Conversation

lindsayad commented Jan 6, 2020 • edited Loading

roystgnr commented Jan 6, 2020

lindsayad commented Jan 6, 2020

roystgnr commented Jan 6, 2020

roystgnr commented Jan 7, 2020

lindsayad commented Jan 7, 2020

jwpeterson commented Jan 8, 2020

lindsayad commented Jan 8, 2020

lindsayad commented Jan 29, 2020

lindsayad commented Feb 4, 2020 • edited Loading

lindsayad commented Feb 4, 2020 • edited Loading

lindsayad commented Feb 4, 2020

roystgnr commented Feb 4, 2020

roystgnr commented Feb 4, 2020

lindsayad commented Feb 5, 2020

roystgnr commented Feb 5, 2020

jwpeterson commented Mar 2, 2022

lindsayad commented Feb 4, 2023

lindsayad commented Jan 6, 2020 •

edited

Loading

lindsayad commented Feb 4, 2020 •

edited

Loading

lindsayad commented Feb 4, 2020 •

edited

Loading