.TH "serif::discretization::domain::EnvelopeDomain" 3 "Version v0.0.1a" "SERiF" \" -*- nroff -*-
.ad l
.nh
.SH NAME
serif::discretization::domain::EnvelopeDomain \- The \fBEnvelopeDomain\fP is the outer, spherical, region of the star\&. It is a derived class of \fBDomain\fP\&.  

.SH SYNOPSIS
.br
.PP
.PP
\fR#include <types\&.hpp>\fP
.PP
Inherits \fBserif::discretization::domain::Domain\fP\&.
.SS "Static Public Attributes"

.in +1c
.ti -1c
.RI "static constexpr std::string_view \fBname\fP = 'envelope'"
.br
.in -1c
.SH "Detailed Description"
.PP 
The \fBEnvelopeDomain\fP is the outer, spherical, region of the star\&. It is a derived class of \fBDomain\fP\&. 


.PP
\fBNote\fP
.RS 4
This need not, and in fact generally will not, correspond to the physical 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 "Member Data Documentation"
.PP 
.SS "std::string_view serif::discretization::domain::EnvelopeDomain::name = 'envelope'\fR [static]\fP, \fR [constexpr]\fP"


.SH "Author"
.PP 
Generated automatically by Doxygen for SERiF from the source code\&.