Just as with channels, compartments should also be implemented as a custom system type.
CompartmentSystem needs to implement conversion to both ODESystem and PDESystem, but we can start with just ODESystem.
Quick notes:
Instead of putting equations, states, params etc in single containers, we should divide up storage across multiple fields and lazily evaluate methods like equations(::CompartmentSystem. This will let us organize and selectively modify certain things more easily. For instance, it simplifies the logic behind pushing and popping additional membrane currents if we have a field like currents::Vector that we use to generate the current sum term for D(Vm) on demand.
We should have a better building block, analogous to GatingVariable, that can be used for defining state transformations (i.e. a replacement for AuxConversion)
In the ideal case, components in a compartment should validate whether their inputs are satisfied by the parent compartment. This should include querying whether an input type could be imputed from other available states/transformations in cases where it might not be explicitly provided by another component. MTK has the notion of inputs/outputs started, but not fully implemented afaict. So we might want to refrain from getting too carried away on this point.
Just as with channels, compartments should also be implemented as a custom system type.
CompartmentSystem
needs to implement conversion to bothODESystem
andPDESystem
, but we can start with justODESystem
.Quick notes:
equations(::CompartmentSystem
. This will let us organize and selectively modify certain things more easily. For instance, it simplifies the logic behind pushing and popping additional membrane currents if we have a field likecurrents::Vector
that we use to generate the current sum term forD(Vm)
on demand.GatingVariable
, that can be used for defining state transformations (i.e. a replacement forAuxConversion
)