Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation fields for advection #337

Open
Tracked by #457
timspainNERSC opened this issue Jun 29, 2023 · 2 comments · May be fixed by #668
Open
Tracked by #457

Implementation fields for advection #337

timspainNERSC opened this issue Jun 29, 2023 · 2 comments · May be fixed by #668
Assignees
Labels
enhancement New feature or request

Comments

@timspainNERSC
Copy link
Collaborator

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.

@timspainNERSC timspainNERSC added this to the 3 Stand-alone model milestone Jun 29, 2023
@timspainNERSC timspainNERSC self-assigned this Jun 29, 2023
@timspainNERSC timspainNERSC moved this from Todo to Discussion in neXtSIM_DG overview Jun 29, 2023
@timspainNERSC timspainNERSC added the enhancement New feature or request label Jun 29, 2023
@timspainNERSC
Copy link
Collaborator Author

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.

@timspainNERSC
Copy link
Collaborator Author

Some notes on advection:

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.

@timspainNERSC timspainNERSC moved this from Discussion to In Progress in neXtSIM_DG overview Aug 26, 2024
@timspainNERSC timspainNERSC linked a pull request Aug 28, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

1 participant