You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Individual Module implementations should be able to designate fields that are (otherwise) internal to that particular implementation to be advected by the dynamics. This should be possible without requiring the field be defined in the interface class and thereby polluting all the other implementations.
The text was updated successfully, but these errors were encountered:
An example that arose during the 2023 SASIP annual meeting was an ice thermodynamics implementation that recorded ice salinity. The current thermodynamics implementations should continue to know nothing about a possible ice salinity field. The variable salinity implementation should be able to designate the ice salinity field to be advected by the dynamics.
ModelComponent can provide the interface for fields to be advected.
Only HFields? No, ZFields too, at least
The advection code can deal with the per ModelArray::Type details.
Depends on ModelArrayDetails.
Perhaps the conversions from ModelArray::Type to Dynamics types should be in ModelArrayDetails.
ModelArrayDetails is conceptually part of the dynamics: discontinuousgalerkin goes with the DG dynamics, finitevolume would go with some finite volume dynamics, lagrangian would go with Lagrangian (neXtSIM-LG) dynamics
A static string, ModelArray map of name (as ModelComponent::field) to ModelArray address.
ModelArrayRef would require a particular implementation of a Module to be able to add its own ModelArrayRef name to the list of available names. MAR3 might make that easier, but would need access to all backing stores. Plus the access for advection is inherently RW, even if the fields would otherwise be RO (don't know how often this would apply).
For example, an ice age value. This would need to be advected and to only have the values updated by the ice age module (other than advection), so if it was shared, it would be shared RO. However, advection using MAR would require the field to be shared RW, since it will need to use the reference and also to change the values.
Individual Module implementations should be able to designate fields that are (otherwise) internal to that particular implementation to be advected by the dynamics. This should be possible without requiring the field be defined in the interface class and thereby polluting all the other implementations.
The text was updated successfully, but these errors were encountered: