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)
62 lines
2.6 KiB
Groff
62 lines
2.6 KiB
Groff
.TH "src/include/serif/discretization/domain/physical_domains.hpp" 3 "Version v0.0.1a" "SERiF" \" -*- nroff -*-
|
|
.ad l
|
|
.nh
|
|
.SH NAME
|
|
src/include/serif/discretization/domain/physical_domains.hpp \- File containing the physical domain types for SERiF\&. These are domain sets that are more useful physically since they group together computationally separate domains that may have no physically meaningful distinction\&. For example, the core and envelope domains are computationally distinct but physically they are both stellar domains\&.
|
|
|
|
.SH SYNOPSIS
|
|
.br
|
|
.PP
|
|
\fR#include 'serif/discretization/domain/types\&.hpp'\fP
|
|
.br
|
|
\fR#include 'serif/discretization/domain/concepts\&.hpp'\fP
|
|
.br
|
|
|
|
.SS "Namespaces"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "namespace \fBserif\fP"
|
|
.br
|
|
.ti -1c
|
|
.RI "namespace \fBserif::discretization\fP"
|
|
.br
|
|
.ti -1c
|
|
.RI "namespace \fBserif::discretization::domain\fP"
|
|
.br
|
|
.in -1c
|
|
.SS "Typedefs"
|
|
|
|
.in +1c
|
|
.ti -1c
|
|
.RI "using \fBserif::discretization::domain::StellarDomains\fP = \fBDomainSet\fP<\fBCoreDomain\fP, \fBEnvelopeDomain\fP>"
|
|
.br
|
|
.RI "The set of domains that make up the stellar region of the mesh\&. "
|
|
.ti -1c
|
|
.RI "using \fBserif::discretization::domain::AllDomains\fP = \fBDomainSet\fP<\fBCoreDomain\fP, \fBEnvelopeDomain\fP, \fBVacuumDomain\fP>"
|
|
.br
|
|
.RI "The set of all domains in the mesh\&. "
|
|
.in -1c
|
|
.SH "Detailed Description"
|
|
.PP
|
|
File containing the physical domain types for SERiF\&. These are domain sets that are more useful physically since they group together computationally separate domains that may have no physically meaningful distinction\&. For example, the core and envelope domains are computationally distinct but physically they are both stellar domains\&.
|
|
|
|
|
|
.PP
|
|
\fBAuthor\fP
|
|
.RS 4
|
|
Emily M\&. Boudreaux
|
|
.RE
|
|
.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
|
|
|
|
.SH "Author"
|
|
.PP
|
|
Generated automatically by Doxygen for SERiF from the source code\&.
|