the seed system has two jobs, get the lane-emden solution for a reasonable n and project that onto the mesh. Note that the seed system does not solve lane-emden, that is in utils/laneemden (so that it can be reused by other systems). Currently SERiF only solves polytrope so the lane-emden initial guess is generally very good; however, as we move to non polytropic EOS we will still use a projected lane-emden as our initial guess for the starting model
The system matrix for a problem may be poorly conditioned, preconditioners are supposed to efficiently estimate the inverse of the system matrix so that a simpler problem, with the approximate identity matrix may be solved instead. The problem is that the best approach to this varies with different fields. The preconditioner system implements infrastructure to define seperate preconditioners for different fields which are then composed together.
The dynamical range of different fields SERiF must solve for is massive. This just breaks any reasonable preconditioner / spreads the eigen modes of the system matrix out. This is a normalization system which uses charectaristic scale factors (e.g. the approximate radius estimated using the lane-emden equation) to rescale different fields to a more similar numeric scale. This turns out to be essential for stable convergence. Broadly this implements Riesz normalization along with exact diagnoal normalization.
This uses a linear solver from solver/linear which then calls some linear solver from the backend. Note that MFEM's build in newton solver is very simplistic and not sufficient for our needs; therefore we implement a more robust one here (and this is why newton is in the frontend and not the backend)
As with much of the code, the actual solvers are implemented (through MFEM) in the backend. This provides an interface so we can more easily swap out the linear solvers on the backend in the future
A representative example is angular momentum. It may be useful to not spin a model up all the way initially (due to convergence issues) rather the continuation system allows for a model to be spun up over a few solves so that it can more reliably reach a stable state
Operators defines how SERiF concepts map into MFEM (or generally any backend) concenpts and types. Since we are trying to seperate the specific MFEM implementation out of SERiF most of the code that was here has moved to backend. However, what remains is some general code related to the block layout of a systen and the contributions of different equations to different parts of that block layout
SERiF defines a so-called "model" subsystem. A model is a fully compile-time description of a problem. Note that this is a description not an evaluation tool. The basic idea is that since we have this robust description we can more easily serialize and be confident that others who load a model are getting the exact same thing. Further, this provides a convient place to do things like validate that all options are compatible, do some limited initial construction of the needed computational graph, allocate needed memory, etc... Some of the stuff that might initially seem to belong to a model will be in the discritization system though (e.g. FEM object lifetimes)
The mapping code is fundamentally backend dependent. Previously we had DomainMapper here; however, since it depende on MFEM we have moved it to the backend. The mapping module now just includes parts of the backend so that prior code will not break
The surface needs some defined condition (e.g. Isobaric) This module defines how the surface is defined. Again, much like the deformation system this does not actually implement much of the code to deform the surface to that condition; rather, it implements code to allow the prescription to be described robustly at compile time
The model must be able to deform to capture the shape induced by rotation or an external potential. Here we add the precription to descibe how we allow deformation. Note that the code to define how deformation is actually implemented is in the backend.
previously we modeled gravity as a mixed formulation. However, this turns out to not be needed with the improved surface prescription. Removing this and returning to a simpler gravity system dramatically reduces the number of unknowns and therefore speeds up the system.
Note, I say this in the todo's in the files too. This system is something of a holdover from the older MeanField system which used a bespoke (per module) caching system. We may want to consider ripping this out in favor of the more general depedencies graph system now that we have it in SERiF
This is a class which adds some helper utilities for computing the effective potential and the hessian of a body under rigid rotation. Note this is not an equation in and of itself
added equation that sums pressure, gravity, and rotation together to get the displacement force. Note that some of the dependencies of this have not been commited yet as they lack documentation
These help constrain what are valid equations at compile time thereby preventing invalid equations from causing runtime crashes due to missing methods and members (this does not validate anythinng about the physics of an equation, only that the form of the equation is right). Note that this is done at compile time rather than with runtime polymorphism to avoid both indirection cost but more imporantly to allow the compiler to more easily inline functions and preform other optimizations that indirection can hide.
This equation provides a constraint on central density through specific enthalpy (I think this is general so long as the eos can convert, though I wrote this for the barotropic case). This may need to be changed latter to be more general (though also generally we should not constrain central density). this is really there to deal with the specific non-rotating n=3 case where the central density is ill-defined due to a singularity.
