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)
199 lines
8.5 KiB
Groff
199 lines
8.5 KiB
Groff
.TH "serif::discretization::domain::schema" 3 "Version v0.0.1a" "SERiF" \" -*- nroff -*-
|
|
.ad l
|
|
.nh
|
|
.SH NAME
|
|
serif::discretization::domain::schema
|
|
.SH SYNOPSIS
|
|
.br
|
|
.PP
|
|
.SS "Namespaces"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "namespace \fBvalidation\fP"
|
|
.br
|
|
.in -1c
|
|
.SS "Classes"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "struct \fBBoundaryID\fP"
|
|
.br
|
|
.RI "The \fBBoundaryID\fP struct is a compile-time type that associates a semantic boundary (a \fBBoundary\fP) with an integer attribute in the mesh file\&. This allows the discretization framework to identify which boundary elements in the mesh correspond to which semantic boundaries in the simulation\&. "
|
|
.ti -1c
|
|
.RI "struct \fBBoundaryIDList\fP"
|
|
.br
|
|
.RI "A list of boundary IDs in the discretization framework\&. "
|
|
.ti -1c
|
|
.RI "struct \fBDomainID\fP"
|
|
.br
|
|
.RI "The \fBDomainID\fP struct is a compile-time type that associates a semantic domain (a \fBDomain\fP) with an integer attribute in the mesh file\&. This allows the discretization framework to identify which elements in the mesh correspond to which semantic domains in the simulation\&. "
|
|
.ti -1c
|
|
.RI "struct \fBDomainIDList\fP"
|
|
.br
|
|
.RI "A list of domain IDs in the discretization framework\&. "
|
|
.ti -1c
|
|
.RI "struct \fBDomainSchema\fP"
|
|
.br
|
|
.RI "A \fBDomainSchema\fP 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 \fBschemas\&.hpp\fP for more information on this schema\&. "
|
|
.ti -1c
|
|
.RI "struct \fBRelationList\fP"
|
|
.br
|
|
.RI "Compile-time list of relations, used to group relations together for operations and forms\&. This struct is a variadic template that takes a list of relation types as template parameters\&. "
|
|
.in -1c
|
|
.SS "Concepts"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "concept \fBIsSchema\fP"
|
|
.br
|
|
.RI "Concept for a schema, which is a collection of relations that describe the relationships between domains and boundaries in a mesh\&. Something is a schema if it satisfies the is_schema_v trait\&. "
|
|
.in -1c
|
|
.SS "Typedefs"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "using \fBCoreEnvelopeVacuumDomainSchema\fP"
|
|
.br
|
|
.RI "The primary domain schema for SERiF\&. This is a three-domain, two-boundary schema that is used to validate meshes that are loaded into SERiF\&. "
|
|
.in -1c
|
|
.SS "Variables"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "template<typename S> constexpr bool \fBis_schema_v\fP = false"
|
|
.br
|
|
.RI "Trait to determine if a type is a \fBDomainSchema\fP\&. This is the default false specialization\&. "
|
|
.ti -1c
|
|
.RI "template<IsDomainIDList DomainIDs, IsBoundaryIDList BoundaryIDs, IsRelationList Relations> constexpr bool \fBis_schema_v< DomainSchema< DomainIDs, BoundaryIDs, Relations > >\fP = true"
|
|
.br
|
|
.RI "Trait to determine if a type is a \fBDomainSchema\fP\&. This is the true specialization for \fBDomainSchema\fP types\&. "
|
|
.in -1c
|
|
.SH "Typedef Documentation"
|
|
.PP
|
|
.SS "using \fBserif::discretization::domain::schema::CoreEnvelopeVacuumDomainSchema\fP"
|
|
\fBInitial value:\fP
|
|
.nf
|
|
DomainSchema<
|
|
DomainIDList<
|
|
DomainID<CoreDomain, 1>,
|
|
DomainID<EnvelopeDomain, 2>,
|
|
DomainID<VacuumDomain, 3>
|
|
>,
|
|
BoundaryIDList<
|
|
BoundaryID<StellarSurfaceBoundary, 1>,
|
|
BoundaryID<InfinitySurfaceBoundary, 2>
|
|
>,
|
|
RelationList<
|
|
|
|
relation::FullyConnected<CoreDomain>,
|
|
relation::FullyConnected<EnvelopeDomain>,
|
|
relation::FullyConnected<VacuumDomain>,
|
|
|
|
|
|
|
|
relation::Inscribed<CoreDomain, EnvelopeDomain>,
|
|
relation::Inscribed<StellarDomains, VacuumDomain>,
|
|
|
|
|
|
|
|
relation::DomainBoundary<StellarSurfaceBoundary, StellarDomains, VacuumDomain>,
|
|
relation::DomainBoundary<InfinitySurfaceBoundary, VacuumDomain>
|
|
>
|
|
>
|
|
.PP
|
|
.fi
|
|
|
|
.PP
|
|
The primary domain schema for SERiF\&. This is a three-domain, two-boundary schema that is used to validate meshes that are loaded into SERiF\&. The three domains are:
|
|
.IP "\(bu" 2
|
|
\fBCoreDomain\fP: The central, cartesian, region of the star\&.
|
|
.IP "\(bu" 2
|
|
\fBEnvelopeDomain\fP: The outer, spherical, region of the star
|
|
.IP "\(bu" 2
|
|
\fBVacuumDomain\fP: The vacuum region surrounding the star\&.
|
|
.PP
|
|
|
|
.PP
|
|
The two boundaries are:
|
|
.IP "\(bu" 2
|
|
\fBStellarSurfaceBoundary\fP: The surface of the star, which is the interface between the stellar domains and the vacuum domain\&.
|
|
.IP "\(bu" 2
|
|
\fBInfinitySurfaceBoundary\fP: The outer edge of the vacuum region, which is the interface between the vacuum domain and the exterior of the mesh\&.
|
|
.PP
|
|
|
|
.PP
|
|
\fBNote\fP
|
|
.RS 4
|
|
The core and envelope domains do not necessarily correspond to the physical core and envelope of a star\&. Rather, this is terminology used to describe the two regions where we orient the mesh differently\&. Fundamentally we cannot reasonably continue a spherical mesh to the center of a stellar model due to the r=0 singularity\&. Therefore, the mesh generation program we use (stroid) generates a cartisan mesh embedded within a spherical mesh (there is a bit more to the topology to ensure we have a nicely structured mesh, see stroid for more details)\&. It is this inner cartesian mesh (along with the transition region) that we call the core\&. The user may need to make choices about where that transition region occurs in their stellar model\&.
|
|
.RE
|
|
.PP
|
|
In addition to the three domains and two boundaries, we also impose a series of topological relations between the domains and boundaries\&. These relations are:
|
|
.IP "\(bu" 2
|
|
FullyConnected<CoreDomain>: The core domain must be fully connected (i\&.e there are no disconnected blobs of core domain)\&.
|
|
.IP "\(bu" 2
|
|
FullyConnected<EnvelopeDomain>: The envelope domain must be fully connected (i\&.e there are no disconnected blobs of envelope domain)\&.
|
|
.IP "\(bu" 2
|
|
FullyConnected<VacuumDomain>: The vacuum domain must be fully connected (i\&.e there are no disconnected blobs of vacuum domain)\&.
|
|
.IP "\(bu" 2
|
|
Inscribed<CoreDomain, EnvelopeDomain>: The core domain must be inscribed within the envelope domain (i\&.e the core domain must be fully contained within the envelope domain)\&.
|
|
.IP "\(bu" 2
|
|
Inscribed<StellarDomains, VacuumDomain>: The stellar domains (core and envelope) must be inscribed within the vacuum domain (i\&.e the stellar domains must be fully contained within the vacuum domain)\&.
|
|
.IP "\(bu" 2
|
|
DomainBoundary<StellarSurfaceBoundary, StellarDomains, VacuumDomain>: The stellar surface boundary must be the interface between the stellar domains and the vacuum domain\&.
|
|
.IP "\(bu" 2
|
|
DomainBoundary<InfinitySurfaceBoundary, VacuumDomain, ExteriorDomain>: The infinity surface boundary must be the interface between the vacuum domain and the exterior of the mesh\&.
|
|
.PP
|
|
|
|
.PP
|
|
We also specify what domain and boundary IDs are expected in the mesh\&. The expected domain IDs are:
|
|
.IP "\(bu" 2
|
|
\fBCoreDomain\fP: 1
|
|
.IP "\(bu" 2
|
|
\fBEnvelopeDomain\fP: 2
|
|
.IP "\(bu" 2
|
|
\fBVacuumDomain\fP: 3
|
|
.PP
|
|
|
|
.PP
|
|
The expected boundary IDs are:
|
|
.IP "\(bu" 2
|
|
\fBStellarSurfaceBoundary\fP: 1
|
|
.IP "\(bu" 2
|
|
\fBInfinitySurfaceBoundary\fP: 2
|
|
.PP
|
|
|
|
.PP
|
|
This lets us say at compile time that a mesh must have this structure; however, we can only validate that a mesh actually has this structure at runtime\&.
|
|
.SH "Variable Documentation"
|
|
.PP
|
|
.SS "template<typename S> bool serif::discretization::domain::schema::is_schema_v = false\fR [constexpr]\fP"
|
|
|
|
.PP
|
|
Trait to determine if a type is a \fBDomainSchema\fP\&. This is the default false specialization\&.
|
|
.PP
|
|
\fBTemplate Parameters\fP
|
|
.RS 4
|
|
\fIS\fP The type to check\&.
|
|
.RE
|
|
.PP
|
|
|
|
.SS "template<IsDomainIDList DomainIDs, IsBoundaryIDList BoundaryIDs, IsRelationList Relations> bool \fBserif::discretization::domain::schema::is_schema_v\fP< \fBDomainSchema\fP< DomainIDs, BoundaryIDs, Relations > > = true\fR [constexpr]\fP"
|
|
|
|
.PP
|
|
Trait to determine if a type is a \fBDomainSchema\fP\&. This is the true specialization for \fBDomainSchema\fP types\&.
|
|
.PP
|
|
\fBTemplate Parameters\fP
|
|
.RS 4
|
|
\fIDomainIDs\fP The list of domain IDs that are expected in the mesh\&.
|
|
.br
|
|
\fIBoundaryIDs\fP The list of boundary IDs that are expected in the mesh\&.
|
|
.br
|
|
\fIRelations\fP The list of relations that describe the relationships between the domains and boundaries\&.
|
|
.RE
|
|
.PP
|
|
|
|
.SH "Author"
|
|
.PP
|
|
Generated automatically by Doxygen for SERiF from the source code\&.
|