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)
57 lines
4.0 KiB
TeX
57 lines
4.0 KiB
TeX
\doxysection{src/include/serif/discretization/domain/schema/domain\+\_\+schema.hpp File Reference}
|
|
\hypertarget{domain__schema_8hpp}{}\label{domain__schema_8hpp}\index{src/include/serif/discretization/domain/schema/domain\_schema.hpp@{src/include/serif/discretization/domain/schema/domain\_schema.hpp}}
|
|
|
|
|
|
File containing the Domain\+Schema class. The idea here is to prevent a class of bugs wherein the user or developer things that their mesh is valid but there is some subtle difference between their mesh and what we expect. Domain\+Schema lets us define the particular traits a mesh must have to be valid (e.\+g. must have a particular set of domain and boundary IDs, those must correspond to a particular set of topological relations). Then the first things that happens when a mesh is loaded is that it is validated against this schema.
|
|
|
|
|
|
{\ttfamily \#include $<$cstddef$>$}\newline
|
|
{\ttfamily \#include "{}serif/discretization/domain/concepts.\+hpp"{}}\newline
|
|
{\ttfamily \#include "{}serif/discretization/domain/ids/lists/concepts.\+hpp"{}}\newline
|
|
{\ttfamily \#include "{}serif/discretization/domain/relation/lists/concepts.\+hpp"{}}\newline
|
|
{\ttfamily \#include "{}serif/discretization/domain/relation/validation/concepts.\+hpp"{}}\newline
|
|
{\ttfamily \#include "{}serif/discretization/domain/resolver.\+hpp"{}}\newline
|
|
Include dependency graph for domain\+\_\+schema.\+hpp\+:
|
|
\nopagebreak
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\leavevmode
|
|
\includegraphics[width=350pt]{domain__schema_8hpp__incl}
|
|
\end{center}
|
|
\end{figure}
|
|
This graph shows which files directly or indirectly include this file\+:
|
|
\nopagebreak
|
|
\begin{figure}[H]
|
|
\begin{center}
|
|
\leavevmode
|
|
\includegraphics[width=350pt]{domain__schema_8hpp__dep__incl}
|
|
\end{center}
|
|
\end{figure}
|
|
\doxysubsubsection*{Classes}
|
|
\begin{DoxyCompactItemize}
|
|
\item
|
|
struct \mbox{\hyperlink{structserif_1_1discretization_1_1domain_1_1schema_1_1_domain_schema}{serif\+::discretization\+::domain\+::schema\+::\+Domain\+Schema$<$ Domain\+IDs, Boundary\+IDs, Relations $>$}}
|
|
\begin{DoxyCompactList}\small\item\em A \doxylink{structserif_1_1discretization_1_1domain_1_1schema_1_1_domain_schema}{Domain\+Schema} is a collection of relations that describe the relationships between domains and boundaries in a mesh. It is used to validate that a mesh has the expected set of domains and boundaries, and that those domains and boundaries have the expected topological relations. This is important for ensuring that the mesh is suitable for the intended simulation or analysis. There is one primary schema we define for SERiF, that is three domains (core, envelope, and vacuum) and two boundaries (stellar surface and infinity surface). See \doxylink{schemas_8hpp}{schemas.\+hpp} for more information on this schema. \end{DoxyCompactList}\end{DoxyCompactItemize}
|
|
\doxysubsubsection*{Namespaces}
|
|
\begin{DoxyCompactItemize}
|
|
\item
|
|
namespace \mbox{\hyperlink{namespaceserif}{serif}}
|
|
\item
|
|
namespace \mbox{\hyperlink{namespaceserif_1_1discretization}{serif\+::discretization}}
|
|
\item
|
|
namespace \mbox{\hyperlink{namespaceserif_1_1discretization_1_1domain}{serif\+::discretization\+::domain}}
|
|
\item
|
|
namespace \mbox{\hyperlink{namespaceserif_1_1discretization_1_1domain_1_1schema}{serif\+::discretization\+::domain\+::schema}}
|
|
\end{DoxyCompactItemize}
|
|
|
|
|
|
\doxysubsection{Detailed Description}
|
|
File containing the Domain\+Schema class. The idea here is to prevent a class of bugs wherein the user or developer things that their mesh is valid but there is some subtle difference between their mesh and what we expect. Domain\+Schema lets us define the particular traits a mesh must have to be valid (e.\+g. must have a particular set of domain and boundary IDs, those must correspond to a particular set of topological relations). Then the first things that happens when a mesh is loaded is that it is validated against this schema.
|
|
|
|
\begin{DoxyAuthor}{Author}
|
|
Emily M. Boudreaux
|
|
\end{DoxyAuthor}
|
|
|
|
|
|
If you wish to extend the set of relations that can be validated or introduce a new more complex kind of mesh that SERiF can use you will likely want to start here or in adjacent files.
|