Morrigan is the protoplanet accretion module of PROTEUS (/ΛproΚtiΙs/, PROH-tee-Ιs), a modular Python framework for the coupled evolution of the atmospheres and interiors of rocky planets and exoplanets. A schematic of PROTEUS components and corresponding modules can be found below. Click any module in the diagram to open its documentation, or navigate to it from the sidebar.
Both figures on this page are loaded from the PROTEUS repository rather than copied into this one, so they follow that repository as it changes.
Schematic of PROTEUS components and corresponding modules.
Where Morrigan sits
Morrigan occupies the accretion slot. It answers the question the rest of the loop cannot: what did this planet's assembly look like, and when did it get hit?
Unlike the other modules it is not called on each iteration. It runs once, before the loop starts, and returns a schedule of impacts that the loop then replays. See Coupling to PROTEUS for why.
The framework's code architecture shows the same arrangement from the software side: an Accretion stage inside the coupling loop, between Interior and Orbit & Tides, and the accretion module group it dispatches to, with Morrigan as one of its three implementations. Every box in the figure links to the source that implements it.
PROTEUS code architecture: the accretion module group and the loop stage that applies an impact.
What Morrigan exchanges with
The schematic above links every module. Morrigan interacts directly with two of them:
| Module | Exchange |
|---|---|
| MORS and the stellar block | Morrigan reads the host star's mass from star.mass rather than repeating it, so the dynamics and the rest of the run cannot disagree about the star |
| ZEPHYRUS | Morrigan models no atmosphere, so impact erosion is left to the consumer. When a coupled run selects atmloss_module = "zephyrus", PROTEUS passes each scheduled impact's collision parameters to ZEPHYRUS's collision law to work out how much atmosphere it strips. The call is PROTEUS's; Morrigan has no ZEPHYRUS dependency |
Conventions the ecosystem shares
- SI internally. Modules exchange quantities in kg, m and s. Configuration files use the units a user thinks in, converted once at the boundary.
- One module per slot per run. Where several modules serve the same slot they are alternatives, chosen in the configuration.
- The interface is the contract. A module's public entry point and the schema it returns are what the framework depends on; changing either is a breaking change for the coupled run and is flagged as such.