-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add a design document for Tracers #68
Add a design document for Tracers #68
Conversation
pinging @maltrud and @katsmith133 for input relative to BGC tracers. @philipwjones one question I recall from BGC folks is the lack of capability to output just select members of a tracer group. If you wanted a member of a tracer group you'd get the whole group. Are we able to fix that in OMEGA? |
@vanroekel Yes, @maltrud had mentioned this to me earlier and 4.1.2 addresses that. If you want a subset of the group members, you can specify them individually and omit the group name from the configuration file. They will still appear as members of the group internally but can continue to be treated as individual tracers too. |
Thanks @philipwjones! I read the document too fast and missed that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philipwjones, this looks like a really nice design. One question I had is about how we plan to handle different source/sink terms for specific tracers/tracer groups.
@sbrus89 The source/sink terms, like the advection/mixing algorithms, will be mostly managed by the modules that own them (eg the BGC, ecosystem routines, debug/diagnostic tracers). For T,S, they may be sitting in forcing modules or specific modules associated with frazil or other terms. There may need to be tendency driver routine(s), but I'm not certain whether that should sit here or in the time integration routines. There will be too many tracer and algorithmic combinations to manage in a single monolithic tracer module, so this is really just a container to manage the storage and grouping of tracers. |
Thanks @philipwjones , that sounds good to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @philipwjones. I read the design document carefully, and it covers the topics I thought of, which are tracer groups and a time index for arbitrary number of steps in memory. I read through the methods section and appreciate your work here, and I have no comments.
This is an initial design document for tracer infrastructure. Comments, modifications, alternative approaches are all welcome.
Checklist