-
Notifications
You must be signed in to change notification settings - Fork 25
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
MARBL reset module #85
Comments
There are efficiency concerns with copying the full tracer arrays in and out of MARBL un-necessarily. |
Idea would be that preformed tracers have no source / sink term, and every timestep the surface value is reset to match the non-preformed version of the same tracer. |
@matt-long and @kristenkrumhardt -- I think this will be a fairly trivial feature to implement. It will require a Also, it doesn't seem like we would need any preformed-specific diagnostics because we would just rely on the GCM's tracer diags. So we need a place in the code to reset the preformed surface values, but that's it. (There will also be some infrastructure work, but I think that's mostly introducing a Anyway, I think a day or two would be plenty of time to get it up and running, with maybe another half-day to run sanity checks and look at output. What's the timeline for this experiment? I definitely want to wait until we bring in #330 (later this week if all goes well) but I can spend a few days working on this before finishing #156. |
Oh, I forgot to ask the big question: which tracers will have preformed counterparts? All the tracers are listed in the indexing type:
Would the |
@klindsay28 pointed out that POP already has a Other design details that came up:
|
In order to represent "preformed" tracers, we need a tracer reset capability, which will likely entail a new MARBL interface.
The text was updated successfully, but these errors were encountered: