Files
MeanField_SERiF/docs/xml/structserif_1_1equations_1_1_contribution.xml
Emily Boudreaux 6b57738330 docs(docs): built docs
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)
2026-11-09 14:09:44 -05:00

130 lines
9.2 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="structserif_1_1equations_1_1_contribution" kind="struct" language="C++" prot="public">
<compoundname>serif::equations::Contribution</compoundname>
<derivedcompoundref refid="classserif_1_1equations_1_1_barycenter_constraint" prot="public" virt="non-virtual">serif::equations::BarycenterConstraint&lt; Axis, Row &gt;</derivedcompoundref>
<derivedcompoundref refid="structserif_1_1operators_1_1_nodal_request" prot="public" virt="non-virtual">serif::operators::NodalRequest&lt; Potential &gt;</derivedcompoundref>
<derivedcompoundref refid="classserif_1_1equations_1_1_barycenter_constraint" prot="public" virt="non-virtual">serif::equations::BarycenterConstraint&lt; Axis, Row &gt;</derivedcompoundref>
<includes local="no">contributions.hpp</includes>
<templateparamlist>
<param>
<type>discretization::forms::IsOperand</type>
<declname>TestOperandT</declname>
<defname>TestOperandT</defname>
</param>
<param>
<type>typename SupportT</type>
<defval><ref refid="namespaceserif_1_1discretization_1_1blocks_1aba18df102a90506f2263dc6395e3f975" kindref="member">discretization::blocks::SupportOf</ref>&lt;typename TestOperandT::term_type&gt;</defval>
</param>
</templateparamlist>
<sectiondef kind="public-type">
<memberdef kind="typedef" id="structserif_1_1equations_1_1_contribution_1a6ad0d6daa9f9c3dfb155841cb0a562bc" prot="public" static="no">
<type>TestOperandT::term_type</type>
<definition>using serif::equations::Contribution&lt; TestOperandT, SupportT &gt;::Test = TestOperandT::term_type</definition>
<argsstring></argsstring>
<name>Test</name>
<qualifiedname>serif::equations::Contribution::Test</qualifiedname>
<briefdescription>
<para>The test type of the contribution. </para>
</briefdescription>
<detaileddescription>
<para>The terminology <ref refid="structserif_1_1equations_1_1_contribution_1a6ad0d6daa9f9c3dfb155841cb0a562bc" kindref="member">Test</ref> here comes from finite element analysis. Specifically, the test type is the type of the test function used in the weak formulation of the equation. More concretely, the test type is the type for which the residuals are computed. Therefore think of this as the type of the residual row that this contribution contributes to. There are a lot of repetitions of the word type here, which I can recognize is a bit confusing. Effectively, the way that we have structured much of this code is that we embed particular functions into the type system. Therefore when I say &quot;the type of the test function&quot; what I mean is the c++ type that we have defined to represent the test function.</para>
<para><simplesect kind="note"><para>The above comment would probably make any actual writer shake in their boots. I&apos;m sure there is a better way to phrase that; however, I am at a loss for the moment. The TL;DR here is that since we encode so much information into the type system we use the word type a lot. If this makes you rationally upset please email me... </para>
</simplesect>
</para>
</detaileddescription>
<inbodydescription>
</inbodydescription>
<location file="src/include/serif/equations/contributions.hpp" line="63" column="9" bodyfile="src/include/serif/equations/contributions.hpp" bodystart="63" bodyend="-1"/>
</memberdef>
<memberdef kind="typedef" id="structserif_1_1equations_1_1_contribution_1aa35e98078c6c8a579a0f702cb710b883" prot="public" static="no">
<type>TestOperandT</type>
<definition>using serif::equations::Contribution&lt; TestOperandT, SupportT &gt;::TestOperand = TestOperandT</definition>
<argsstring></argsstring>
<name>TestOperand</name>
<qualifiedname>serif::equations::Contribution::TestOperand</qualifiedname>
<briefdescription>
<para>The operand type of the contribution (associating a test function and a term) </para>
</briefdescription>
<detaileddescription>
</detaileddescription>
<inbodydescription>
</inbodydescription>
<location file="src/include/serif/equations/contributions.hpp" line="64" column="9" bodyfile="src/include/serif/equations/contributions.hpp" bodystart="64" bodyend="-1"/>
</memberdef>
<memberdef kind="typedef" id="structserif_1_1equations_1_1_contribution_1abf74d552d7125c10a4b41d60398cfc15" prot="public" static="no">
<type>SupportT</type>
<definition>using serif::equations::Contribution&lt; TestOperandT, SupportT &gt;::Support = SupportT</definition>
<argsstring></argsstring>
<name>Support</name>
<qualifiedname>serif::equations::Contribution::Support</qualifiedname>
<briefdescription>
<para>The domain support of the contribution (which then boils down to the dofs which are supported by the term on that test function) </para>
</briefdescription>
<detaileddescription>
</detaileddescription>
<inbodydescription>
</inbodydescription>
<location file="src/include/serif/equations/contributions.hpp" line="65" column="9" bodyfile="src/include/serif/equations/contributions.hpp" bodystart="65" bodyend="-1"/>
</memberdef>
</sectiondef>
<briefdescription>
<para>A helper struct for authoring equations with fewer lines of boiler-plate. The idea here is that every equation must report certain members so that the backend can inspect at compile time. An author could certainly write these members themselves, but the <ref refid="structserif_1_1equations_1_1_contribution" kindref="compound">Contribution</ref> struct auto generates those members based on its template parameters. Therefore, by inheriting from the <ref refid="structserif_1_1equations_1_1_contribution" kindref="compound">Contribution</ref> struct an equation author can avoid writing those members themselves. Note that while this is inheritance it is still a compile-time relation. <ref refid="structserif_1_1equations_1_1_contribution" kindref="compound">Contribution</ref> does not add any runtime overhead to the equation. </para>
</briefdescription>
<detaileddescription>
<para><parameterlist kind="templateparam"><parameteritem>
<parameternamelist>
<parametername>TestOperandT</parametername>
</parameternamelist>
<parameterdescription>
<para>The test operation type, which must be a valid operand (IsOperand). </para>
</parameterdescription>
</parameteritem>
<parameteritem>
<parameternamelist>
<parametername>SupportT</parametername>
</parameternamelist>
<parameterdescription>
<para>The support type, which must be a valid support (IsSupport). This defaults to the support of the test term.</para>
</parameterdescription>
</parameteritem>
</parameterlist>
<simplesect kind="note"><para>The support type is, by default, read from the test term. There are very few situations where you should need to override this default.</para>
</simplesect>
<simplesect kind="note"><para>Read this as "residuals are contributed to the row(s) defined by the test operation. e.g Some density constraint function might contribute to the residuals of the overall system through some density row. </para>
</simplesect>
</para>
</detaileddescription>
<inheritancegraph>
<node id="2">
<label>serif::equations::BarycenterConstraint&lt; Axis, Row &gt;</label>
<link refid="classserif_1_1equations_1_1_barycenter_constraint"/>
<childnode refid="1" relation="public-inheritance">
</childnode>
</node>
<node id="4">
<label>serif::equations::BarycenterConstraint&lt; Axis, Row &gt;</label>
<link refid="classserif_1_1equations_1_1_barycenter_constraint"/>
<childnode refid="1" relation="public-inheritance">
</childnode>
</node>
<node id="1">
<label>serif::equations::Contribution&lt; TestOperandT, SupportT &gt;</label>
<link refid="structserif_1_1equations_1_1_contribution"/>
</node>
<node id="3">
<label>serif::operators::NodalRequest&lt; Potential &gt;</label>
<link refid="structserif_1_1operators_1_1_nodal_request"/>
<childnode refid="1" relation="public-inheritance">
</childnode>
</node>
</inheritancegraph>
<location file="src/include/serif/equations/contributions.hpp" line="45" column="5" bodyfile="src/include/serif/equations/contributions.hpp" bodystart="45" bodyend="66"/>
<listofallmembers>
<member refid="structserif_1_1equations_1_1_contribution_1abf74d552d7125c10a4b41d60398cfc15" prot="public" virt="non-virtual"><scope>serif::equations::Contribution</scope><name>Support</name></member>
<member refid="structserif_1_1equations_1_1_contribution_1a6ad0d6daa9f9c3dfb155841cb0a562bc" prot="public" virt="non-virtual"><scope>serif::equations::Contribution</scope><name>Test</name></member>
<member refid="structserif_1_1equations_1_1_contribution_1aa35e98078c6c8a579a0f702cb710b883" prot="public" virt="non-virtual"><scope>serif::equations::Contribution</scope><name>TestOperand</name></member>
</listofallmembers>
</compounddef>
</doxygen>