Aragog input

[planetmariana]

@lsoucasse @djbower @timlichtenberg

In order to translate spider inputs into Aragog inputs, we need to clarify these items:

• Aragog manages time in seconds or years?

• What is the difference between phase_transition_width and rheological_transition_width parameters.

• Adiabatic_bulk_modulus is declared but not entirely sure where it is used, specially for the _MeshParameters section.

• When running Aragon as some of the test. ie:

  
  from aragog import CFG_DATA

filename=CFG_DATA.joinpath("abe_mixed.cfg") solver = Solver(filename) solver.initialize() solver.solve()

calculated: np.ndarray = solver.temperature_staggered[:, -1] output: Output = Output(solver) output.plot()

is not directing plotting. Is there a previous step to store the data before plotting?

[djbower]

• Internally Aragog uses scaled quantities, where the scalings are provided in SI units in the configuration file in the scalings section. You will see some mention of time in years for convenience elsewhere, like specifying start_time and end_time in years. But these should be commented accordingly.
• Phase transition width might currently be a placeholder (would need to check), but it is for smoothing the material properties across the liquidus and solidus, which can be required for numerical stability. By contrast, rheological_transition_width parameters control the viscosity between the liquidus and the solidus.
• Adiabatic bulk modulus is probably also a placeholder for using with EOS, either to compute the pressure - radius relationship for the mesh, or potentially for use with other equations of state.
• Check the code. The solver should store the temperature solution as a 2-D array, where columns represent different time steps and rows are for each pressure in the mesh.

[lsoucasse]

I have just checked the adiabatic bulk modulus, it is actually used now in the EOS to compute density and pressure, so we have to provide it (maybe it was an hardcoded parameter in Spider?): $\rho(P) = \rho_s \exp(P/K_S)$ where $K_S$ is the adiabatic modulus in Pa. By the way, if I get it right, we assume liquid and solid have the same density, is it correct?

[lsoucasse]

I am a bit confused here as in the phase module, it seems that solid and liquid density are recomputed from look up tables using temperature and pressure, the pressure being computed using the EOS in the comment above. I don't see how all this can be consistent. Maybe we should discuss it next Monday.

[djbower]

You are correct that it is not consistent. Aragog uses a single EOS (Adams Williamson) to compute a mapping between the radius and pressure at initialisation. Given this mapping, the liquid and solid phases can be evaluated for any temperature for all (fixed) pressure points in the mesh. This provides parameters that are used to compute the transport fluxes.

To do this self-consistently would require remeshing with time, because as the volume of melt and solid changes during crystallization the radius-pressure relationship would also change. So the argument is basically that it's OK to use the approximate hydrostatic pressure, which is pre-computed, because dynamic pressure contributions due to flow are small. And also, the change in volume due to melt-solid is not significant enough to change the outgoing energy (change in radius of the planet is not substantial enough to change the surface area).

So basically, I think assuming a fixed mesh is OK for now, but with accretion (which will demand a changing mesh), we could also ensure self-consistency due to the changing volumes of melt and solid. For code speed, I also wanted to avoid incorporating a static structure solver at every time step, which I think would be required to enforce self-consistency.

[lsoucasse]

Thank you for the clarification. We can imagine this remeshing takes place on the proteus side and provides aragog with consistent radius / pressure / density information which can be assumed to be constant during the time window of a single aragog run.