Like a lot of the parts of the mapping module written before I started factoring mfem stuff into backend modules, a good amount of this might be movable to some mfem backend
Come back and fill in more information about elsewhere. If you are the developer from above and you are reading this todo, then I am, and I mean this truly, very sorry....
Really this does not need to be specific to this module, this might more generally be named something like "safe sum" and moved to a more general location.
For consistency with other types consider renaming TermT::FunctionalSpace to TermT::functional_space. This would require updating all term definitions to use the new naming convention. CLion or some other IDE should be able to handle this refactor easily.
For consistency with other types consider renaming TermT::Quantity to TermT::quantity. This would require updating all term definitions to use the new naming convention. CLion or some other IDE should be able to handle this refactor easily.
For consistency with other types consider renaming TermT::Support to TermT::support. This would require updating all term definitions to use the new naming convention. CLion or some other IDE should be able to handle this refactor easily.
Implemented this with std::vector when I moved all the mfem code into backend/mfem; however, std::vector has all sorts of limitations and problems. We may want to consider using the types.hpp vector alias here instead? Or some other vector implementation.
This introduces an assumption of three-dimensionality, we say "this is either a scalar or a tensor of dimension 3". We should probably relax this assumption.
This file was a mistake, the information it is is helpful yes, however, it has lost generality, lost good type information, and does not need to be separate Really we should refactor this to be part of Operation, remove the assumption of 3 dimensionality, and probably fall back to something like a span rather than an array.
We make an assumption here about the dimensionality of the space (e.g that the hessian is a 3x3 matrix). This is likely fine; however, if we ever want to be able to model 1D or 2D systems we will need to refactor this to be more general.
This is a holdover from the original MeanField code and its bespoke reference tracking system. It is likely that this can be removed in favor of SERiF's more robust dependencies graph system.
A shared pointer was the easiest way to implement this; however, this introduces some non-zero overhead related to reference counting. Generally, shared pointers should only be used when absolutely necessary and I have not given deep thought to if that is the case here (and more generally across the graph system).
Change this default. The automatic rule (operators/backend/mfem/quadrature.hpp: equation_rule) adds OrderW() of the geometry (17 for geometry order 6) plus 3 (p_disp - 1) to every form, giving ~order 35 (5,832 points per hexahedron) on the stellar meshes. A fixed discretization order of 11 (216 points) gave the same ESTER/TOP agreement for the n=2, J=0.05 benchmark at 0.96 GiB instead of 13.6 GB (profiling/results/FINDINGS.md, sections 14-15); complete_sandbox already passes it explicitly. Changing the library default changes every solve, so test expectations (tolerances, iteration counts, stored reference values) may need updating, and a fixed order should be checked against higher field orders.
1.13.2