Closed adigitoleo closed 5 months ago
The regime history array would end up duplicated for olivine + enstatite simulations leading to unnecessary memory or storage usage. There's not any reasonable use case that I can see for having different regime histories for distinct mineral phases. So, to track the history, I suggest instead adding another arg get_regime
to update_orientations
:
import pydrex
start_regime = pydrex.DeformationRegime.matrix_dislocation
regimes = [[start_regime, 1]]
olA = pydrex.Mineral(phase=pydrex.MineralPhase.olivine, fabric=pydrex.MineralFabric.olivine_A, regime=start_regime)
ens = pydrex.Mineral(phase=pydrex.MineralPhase.enstatite, fabric=pydrex.MineralFabric.enstatite_AB, regime=start_regime)
def get_regime(t, x):
# Dummy example, normally do something more complicated with some f(t, x).
return pydrex.DeformationRegime.matrix_dislocation
deformation_gradient = np.eye(3)
# Define config, get_velocity_gradient, pathline.
# Only store the new deformation gradient for the last phase.
ens.update_orientations(config, deformation_gradient, get_velocity_gradient, get_regime, pathline)
deformation_gradient = olA.update_orientations(config, deformation_gradient, get_velocity_gadient, get_regime, pathline)
In this way, the history of deformation regimes can be obtained with get_regime()
given any t, x
along the pathline (or even without a pathline, for time-dependent flows)
The only thing needed in this case is some logic in update_orientations
to also update the .regime
attribute of a mineral, will add that shortly.
Done in 2992bf3
Regimes are
IntEnum
instances so shouldn't be to memory heavy, but either way we can collapse the history to either a sequence of tuples:(regime, duration)
or just imply the encoding[regime, duration, regime, duration, ...]
. Numba may decide for us which of these works. Duration is a number of timesteps, also an int.Just making an issue so I don't forget. Feel free to merge #195 if the other things are fine, then I'll do this in a quick PR tonight.