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

Add a design document for Tracers #68

Merged
merged 1 commit into from
Mar 18, 2024

Conversation

philipwjones
Copy link

@philipwjones philipwjones commented Mar 12, 2024

This is an initial design document for tracer infrastructure. Comments, modifications, alternative approaches are all welcome.

Checklist

  • Documentation:
    • Design document has been generated and added to the docs
    • Documentation has been built locally and changes look as expected

@vanroekel
Copy link

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?

@philipwjones
Copy link
Author

philipwjones commented Mar 13, 2024

@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.

@vanroekel
Copy link

Thanks @philipwjones! I read the document too fast and missed that.

Copy link

@sbrus89 sbrus89 left a 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.

@philipwjones
Copy link
Author

@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.

@sbrus89
Copy link

sbrus89 commented Mar 15, 2024

Thanks @philipwjones , that sounds good to me.

Copy link

@mark-petersen mark-petersen left a 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.

@philipwjones philipwjones merged commit cbef720 into E3SM-Project:develop Mar 18, 2024
2 checks passed
@philipwjones philipwjones deleted the omega/tracer-design branch March 18, 2024 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants