template<eos::models::PressureForceEOS EOST>
class serif::equations::DisplacementForce< EOST >
- Template Parameters
-
| EOST | The equation of state type, this must satisfy the PressureForceEOS concept. The requires section below lays out what the PressureForceEOS concept requires. |
| Requirements |
-
The equation of state type must publish a valid Relation catalog
-
The equation of state type must implement all relations required by the catalog it publishes
-
The equation of state type must support the relation pressure from specific enthalpy
-
The equation of state type must support the partial derivative pressure from specific enthalpy with respect to specific enthalpy
|
This class represents the mechanical balance equation in SERiF. It is a sum of the pressure force, gravity force, and rotational force equations.
As I have said in a number of other locations this is an important file / class to understand. You might note that this file is where we actually build the momentum equation (though in the case of a polytrope it looks a lot more like a mechanical balance equation). You may note though how little code there actually is here. That is because we have split up the separated physics into the gravity_force, the pressure_force, and the rotational_force equations. Then we use the arithmetic equation routines sum their contributions together. Further, this is where we actually define the rotational axis of the star (note how we set it along the z-axis) and the center of rotation.
Generally this equation should be used as a model for how to implement other multi-term equations. We want to avoid monolithic equations. There are a few reasons for this, one would be maintainability. This software is, by requirement, exceedingly complex, the more we can break things up into semantically meaningful pieces the easier it will be for a developer to hold parts of the code in their head. However, more than just maintainability there is a performance reason for this (though one that we admittedly do not exploit at the moment). The backend of SERiF makes heavy use of a computational graph with aggressive inter-node caching. If we split equations up into smaller pieces and then represent their sums as operations on this graph the backend can more aggressively avoid recomputing certain parts which may, provably, have not changes from one evaluation to the next. Currently, we do not do this; however, this is future optimization will not require modifying this code at all only the equation sum backend.
- Note
- The DisplacementForce equation owns all three contributing equations