todo File context.hpp 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 File data.hpp As said above there is some refactoring to make this cleaner which could happen. File forms.hpp 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.... Struct serif::discretization::backend::mfem::TensorBasisCache::Entry Consider if we can remove the shared pointer from here, shared pointers introduce overhead with reference counting and that may slow down the cache. Member serif::discretization::blocks::BlockVectorView< Kind, Layout, Scalar >::BlockVectorView (const LayoutType &layout, std::span< Scalar > values) Really this could go in many places; however, I think we should move away from throwing std exceptions and introduce our own exception hierarchy. Member serif::discretization::blocks::checked_block_size (std::span< const std::size_t > sizes) 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. Member serif::discretization::blocks::FunctionalSpaceOf 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. Member serif::discretization::blocks::QuantityOf 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. Member serif::discretization::blocks::SupportOf 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. Member serif::discretization::domain::ids::validation::all_unique_values (Ts... values) noexcept Really this should probably be refactored into the utils module since this is not super specific to domainIDs. Struct serif::discretization::domain::mesh::MeshTopologyData 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. Member serif::discretization::domain::schema::validation::DomainBoundary< BoundaryT, DomainTs >::name we should replace this with our meta library. Member serif::discretization::domain::schema::validation::FullyConnected< A >::name we should replace this with our meta library. Member serif::discretization::domain::schema::validation::Inscribed< A, B >::name we should replace this with our meta library. Member serif::discretization::forms::PartialDerivative Should probably be consolidated with the other PartialDerivative system... No, should definitely be consolidated... Struct serif::discretization::forms::ValueComponents< ValueT > 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. Member serif::discretization::forms::VectorValue 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. Member serif::discretization::functional_space::Continuity There may be a better way to store these relations that forces them to be parallel rather than just relying on the programmer to keep them in sync. Member serif::discretization::quadrature::backend::mfem::resolve_operand_order () noexcept We already have some of this information in the form_traits file, we should probably extract the order boost from there. Class serif::eos::EOSEvaluationError We have moved away from custom error types, this may warrant removal. Struct serif::equations::Contributions< T, std::void_t< decltype(std::declval< const T & >().contributions())> > Replace SFINAE with requires or concepts if possible. This would make the code more readable and easier to understand. Struct serif::equations::ContributionTuple< std::tuple< Ts... >, std::void_t< decltype(std::tuple_cat(std::declval< typename Contributions< std::remove_cvref_t< Ts > >::type >()...))> > Replace SFINAE with requires or concepts if possible. This would make the code more readable and easier to understand. Class serif::equations::RigidRotation This should probably be refactored into its own submodule to clean up equations a bit Member serif::equations::RigidRotation::centrifugal_potential (const Vector &position) const We should add some validation for position into this Member serif::equations::RigidRotation::centrifugal_potential_gradient (const Vector &position) const We should add some validation for position into this Member serif::equations::RigidRotation::RigidRotation (const Vector &angular_velocity_vector, const Vector &axis_origin={}) 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. Member serif::equations::RigidRotation::unit_rotation (Vector rotation_axis={0.0, 0.0, 1.0}, const Vector &axis_origin={}) This may make sense to turn into a free-function rather than a class method. Struct serif::equations::TestOperandTraits< T, typename > Can we replace SFINAE here with requires or concepts? Member serif::geometry::deformation::backend::mfem::detail::compile_radial_reference (const ReferenceDiscretization &input, const std::vector< int > &selected) 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. Member serif::geometry::deformation::backend::mfem::detail::share_reference_result (std::expected< Value, DeformationFailure > result) 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). Struct serif::mapping::FaceMappingContext Add a worked example here Struct serif::mapping::FaceQuadratureContext Add a worked example here Struct serif::mapping::MappingPointContext Add a worked example here Struct serif::mapping::VolumeMappingContext Add a worked example here Struct serif::mapping::VolumeQuadratureContext Add a worked example here Member serif::operators::backend::mfem::TensorBasisCache::get (const ::mfem::FiniteElement &element, const ::mfem::IntegrationRule &rule, ReferenceOperation operation, const int copies, const ElementReconstruction *reconstruction=nullptr) I think it would make sense, at some point, to switch this to an std::optional return Member serif::operators::backend::mfem::VolumeOptions::quadrature_policy 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. Namespace serif::utils::dependencies We may want to remove the ability to have implicit casting between types, this is a bit of a footgun and may lead to subtle bugs. File value.hpp This should be consolidated and removed. This information could be injected into the Operation itself.