Emily Boudreaux
6b57738330
Note for now much of the docs is LLM written. This was done to save time and focus on code development. The docs have been LOOSLEY reviewed. However, the code itself has been either fully written by hand or fully reviewed. Therefore, the docs should at the moment be seen as a loose resource rather than authoratiative (and this is on top of the general ability for docs to drift)
133 lines
19 KiB
XML
133 lines
19 KiB
XML
<?xml version='1.0' encoding='UTF-8' standalone='no'?>
|
|
<doxygen xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="compound.xsd" version="1.13.2" xml:lang="en-US">
|
|
<compounddef id="todo" kind="page">
|
|
<compoundname>todo</compoundname>
|
|
<title>Todo List</title>
|
|
<briefdescription>
|
|
</briefdescription>
|
|
<detaileddescription>
|
|
<para><variablelist>
|
|
<varlistentry><term>File <ref refid="context_8hpp" kindref="compound">context.hpp</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000007"/>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 </para>
|
|
</listitem>
|
|
<varlistentry><term>File <ref refid="data_8hpp" kindref="compound">data.hpp</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000013"/>As said above there is some refactoring to make this cleaner which could happen. </para>
|
|
</listitem>
|
|
<varlistentry><term>File <ref refid="forms_8hpp" kindref="compound">forms.hpp</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000028"/>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.... </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1discretization_1_1backend_1_1mfem_1_1_tensor_basis_cache_1_1_entry" kindref="compound">serif::discretization::backend::mfem::TensorBasisCache::Entry</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000003"/>Consider if we can remove the shared pointer from here, shared pointers introduce overhead with reference counting and that may slow down the cache. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="classserif_1_1discretization_1_1blocks_1_1_block_vector_view_1a33dc11460a096a75aa726c97f23a2d64" kindref="member">serif::discretization::blocks::BlockVectorView< Kind, Layout, Scalar >::BlockVectorView</ref> (const <ref refid="classserif_1_1discretization_1_1blocks_1_1_block_vector_view_1a7cd2f4e8ddc18a6a5593f39bc07339fa" kindref="member">LayoutType</ref> &layout, std::span< Scalar > values)</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000019"/>Really this could go in many places; however, I think we should move away from throwing std exceptions and introduce our own exception hierarchy. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1blocks_1a946d6244b79cf4fad47d07fb97db32e1" kindref="member">serif::discretization::blocks::checked_block_size</ref> (std::span< const std::size_t > sizes)</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000015"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1blocks_1a8b16d088f59cff9d40cd84eebd53d3b1" kindref="member">serif::discretization::blocks::FunctionalSpaceOf</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000016"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1blocks_1aef1a0354784f797bfa87d2369652b5cb" kindref="member">serif::discretization::blocks::QuantityOf</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000018"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1blocks_1aba18df102a90506f2263dc6395e3f975" kindref="member">serif::discretization::blocks::SupportOf</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000017"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1domain_1_1ids_1_1validation_1aa32cf1b94829069aacbae4c24d24ea50" kindref="member">serif::discretization::domain::ids::validation::all_unique_values</ref> (Ts... values) noexcept</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000022"/>Really this should probably be refactored into the utils module since this is not super specific to domainIDs. </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1discretization_1_1domain_1_1mesh_1_1_mesh_topology_data" kindref="compound">serif::discretization::domain::mesh::MeshTopologyData</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000023"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="structserif_1_1discretization_1_1domain_1_1schema_1_1validation_1_1_domain_boundary_1acd6f3036bc6d36e93ea1cdba556a25e1" kindref="member">serif::discretization::domain::schema::validation::DomainBoundary< BoundaryT, DomainTs >::name</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000026"/>we should replace this with our meta library. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="structserif_1_1discretization_1_1domain_1_1schema_1_1validation_1_1_fully_connected_1ad996a186a7ae8839a3d21f0be7b41fad" kindref="member">serif::discretization::domain::schema::validation::FullyConnected< A >::name</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000025"/>we should replace this with our meta library. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="structserif_1_1discretization_1_1domain_1_1schema_1_1validation_1_1_inscribed_1a31cfdcacefd6b4fc515fdef5bc81117d" kindref="member">serif::discretization::domain::schema::validation::Inscribed< A, B >::name</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000024"/>we should replace this with our meta library. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1forms_1a259c1476be2e462d8cd07c803434af69" kindref="member">serif::discretization::forms::PartialDerivative</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000033"/>Should probably be consolidated with the other <ref refid="namespaceserif_1_1discretization_1_1forms_1a259c1476be2e462d8cd07c803434af69" kindref="member">PartialDerivative</ref> system... No, should <emphasis>definitely</emphasis> be consolidated... </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1discretization_1_1forms_1_1_value_components" kindref="compound">serif::discretization::forms::ValueComponents< ValueT ></ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000032"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1forms_1a19001a41347e243892d7bfef18abd174" kindref="member">serif::discretization::forms::VectorValue</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000031"/>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 <ref refid="structserif_1_1discretization_1_1forms_1_1_operation" kindref="compound">Operation</ref>, remove the assumption of 3 dimensionality, and probably fall back to something like a span rather than an array. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1functional__space_1a4a023144b19edc1f9083dbfc4634fdd2" kindref="member">serif::discretization::functional_space::Continuity</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000034"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1discretization_1_1quadrature_1_1backend_1_1mfem_1a57b84979ef93418360b7d207fa87858b" kindref="member">serif::discretization::quadrature::backend::mfem::resolve_operand_order</ref> () noexcept</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000002"/>We already have some of this information in the form_traits file, we should probably extract the order boost from there. </para>
|
|
</listitem>
|
|
<varlistentry><term>Class <ref refid="classserif_1_1eos_1_1_e_o_s_evaluation_error" kindref="compound">serif::eos::EOSEvaluationError</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000035"/>We have moved away from custom error types, this may warrant removal. </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1equations_1_1_contributions_3_01_t_00_01std_1_1void__t_3_01decltype_07std_1_1decl671b42e5568b3715d07217eb0f34ce32" kindref="compound">serif::equations::Contributions< T, std::void_t< decltype(std::declval< const T & >().contributions())> ></ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000039"/>Replace SFINAE with requires or concepts if possible. This would make the code more readable and easier to understand. </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1equations_1_1_contribution_tuple_3_01std_1_1tuple_3_01_ts_8_8_8_01_4_00_01std_1_1e282a2c4b2ce56d3b5a3d2dda19385da" kindref="compound">serif::equations::ContributionTuple< std::tuple< Ts... >, std::void_t< decltype(std::tuple_cat(std::declval< typename Contributions< std::remove_cvref_t< Ts > >::type >()...))> ></ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000038"/>Replace SFINAE with requires or concepts if possible. This would make the code more readable and easier to understand. </para>
|
|
</listitem>
|
|
<varlistentry><term>Class <ref refid="classserif_1_1equations_1_1_rigid_rotation" kindref="compound">serif::equations::RigidRotation</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000040"/>This should probably be refactored into its own submodule to clean up equations a bit </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a7e704e49442ae57319c415c0d7f25fe0" kindref="member">serif::equations::RigidRotation::centrifugal_potential</ref> (const <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a1e11c2a12ffc17fd826e02ec5ac19311" kindref="member">Vector</ref> &position) const</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000043"/>We should add some validation for position into this </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a8f188b248fc9cea40a5916fee0ff933f" kindref="member">serif::equations::RigidRotation::centrifugal_potential_gradient</ref> (const <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a1e11c2a12ffc17fd826e02ec5ac19311" kindref="member">Vector</ref> &position) const</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000044"/>We should add some validation for position into this </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a46be2ab431592a732b137543f1b9531e" kindref="member">serif::equations::RigidRotation::RigidRotation</ref> (const <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a1e11c2a12ffc17fd826e02ec5ac19311" kindref="member">Vector</ref> &angular_velocity_vector, const <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a1e11c2a12ffc17fd826e02ec5ac19311" kindref="member">Vector</ref> &axis_origin={})</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000041"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a3aace3f5fe0ec7d0714b21862b7ca199" kindref="member">serif::equations::RigidRotation::unit_rotation</ref> (<ref refid="classserif_1_1equations_1_1_rigid_rotation_1a1e11c2a12ffc17fd826e02ec5ac19311" kindref="member">Vector</ref> rotation_axis={0.0, 0.0, 1.0}, const <ref refid="classserif_1_1equations_1_1_rigid_rotation_1a1e11c2a12ffc17fd826e02ec5ac19311" kindref="member">Vector</ref> &axis_origin={})</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000042"/>This may make sense to turn into a free-function rather than a class method. </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1equations_1_1_test_operand_traits" kindref="compound">serif::equations::TestOperandTraits< T, typename ></ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000037"/>Can we replace SFINAE here with requires or concepts? </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1geometry_1_1deformation_1_1backend_1_1mfem_1_1detail_1a6d9608b34a2b5cc2fc9290e472c5da2c" kindref="member">serif::geometry::deformation::backend::mfem::detail::compile_radial_reference</ref> (const <ref refid="structserif_1_1geometry_1_1deformation_1_1backend_1_1mfem_1_1_reference_discretization" kindref="compound">ReferenceDiscretization</ref> &input, const std::vector< int > &selected)</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000006"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="namespaceserif_1_1geometry_1_1deformation_1_1backend_1_1mfem_1_1detail_1a05b352de13c1c09e3358f7990397f317" kindref="member">serif::geometry::deformation::backend::mfem::detail::share_reference_result</ref> (std::expected< Value, DeformationFailure > result)</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000005"/>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). </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1mapping_1_1_face_mapping_context" kindref="compound">serif::mapping::FaceMappingContext</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000012"/>Add a worked example here </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1mapping_1_1_face_quadrature_context" kindref="compound">serif::mapping::FaceQuadratureContext</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000009"/>Add a worked example here </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1mapping_1_1_mapping_point_context" kindref="compound">serif::mapping::MappingPointContext</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000010"/>Add a worked example here </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1mapping_1_1_volume_mapping_context" kindref="compound">serif::mapping::VolumeMappingContext</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000011"/>Add a worked example here </para>
|
|
</listitem>
|
|
<varlistentry><term>Struct <ref refid="structserif_1_1mapping_1_1_volume_quadrature_context" kindref="compound">serif::mapping::VolumeQuadratureContext</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000008"/>Add a worked example here </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="classserif_1_1operators_1_1backend_1_1mfem_1_1_tensor_basis_cache_1ab188f20a72adcd9a938a3062355d66e1" kindref="member">serif::operators::backend::mfem::TensorBasisCache::get</ref> (const ::mfem::FiniteElement &element, const ::mfem::IntegrationRule &rule, <ref refid="namespaceserif_1_1discretization_1_1backend_1_1mfem_1af75f98db90618153ea4ca169945733f7" kindref="member">ReferenceOperation</ref> operation, const int copies, const <ref refid="structserif_1_1discretization_1_1backend_1_1mfem_1_1_element_reconstruction" kindref="compound">ElementReconstruction</ref> *reconstruction=nullptr)</term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000004"/>I think it would make sense, at some point, to switch this to an std::optional return </para>
|
|
</listitem>
|
|
<varlistentry><term>Member <ref refid="structserif_1_1operators_1_1backend_1_1mfem_1_1_volume_options_1ab7b060d26541126b069ab6827de75723" kindref="member">serif::operators::backend::mfem::VolumeOptions::quadrature_policy</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000014"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>Namespace <ref refid="namespaceserif_1_1utils_1_1dependencies" kindref="compound">serif::utils::dependencies</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000045"/>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. </para>
|
|
</listitem>
|
|
<varlistentry><term>File <ref refid="value_8hpp" kindref="compound">value.hpp</ref> </term></varlistentry>
|
|
<listitem><para><anchor id="todo_1_todo000030"/>This should be consolidated and removed. This information could be injected into the Operation itself. </para>
|
|
</listitem>
|
|
</variablelist>
|
|
</para>
|
|
</detaileddescription>
|
|
<location file="todo"/>
|
|
</compounddef>
|
|
</doxygen>
|