-
Notifications
You must be signed in to change notification settings - Fork 306
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
Plumber2 Implementation #2406
base: b4b-dev
Are you sure you want to change the base?
Plumber2 Implementation #2406
Conversation
This PR will also address #2186 |
We'll also need to add the new CDEPS tag to this PR. |
Per conversation with Erik, we'll move this to bfb once the other Plumber-related PRs are in bfb next week. |
To Do for this PR:
|
We don't currently have restart files for PLUMBER2, which has brought up the question: to what extent do we want to provide support for PLUMBER tower sites? Two options that @wwieder and I discussed this morning are described below:
@danicalombardozzi @slevis-lmwg @olyson let me know if you have thoughts on this. We were planning to chat on Tuesday at 9am but it looks like there is a NCAR-NEON-Community partnership meeting that will be taking that time slot and I'd ideally like to make a decision before August 20th; also happy to tag up an additional time if that's easier than a GitHub discussion. |
My guess is that most users will want to change the model and will likely have to do their own spinups anyway. So I might lean toward not providing initial files if it requires significant work to generate, keep track of, and update those files. |
I would agree with this. These runs are cheap and the point is to have a
set of tower sites that can be run quickly and easily with different model
configurations and with new model versions. The ICs quickly become
irrelevant as the model changes.
…On Tue, Aug 6, 2024 at 7:02 PM Keith Oleson ***@***.***> wrote:
My guess is that most users will want to change the model and will likely
have to do their own spinups anyway. So I might lean toward not providing
initial files if it requires significant work to generate, keep track of,
and update those files.
—
Reply to this email directly, view it on GitHub
<#2406 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFABYVB663VOB5R7GAWPZJDZQFIYNAVCNFSM6AAAAABELMMUA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZSGMYDEMBTHA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Ok, thank you both for this feedback! |
Thanks for weighing in here. Teagan since Dave and Keith came to the same conclusion we did yesterday lets move forward with the plan to support 'spinup' and 'transient' PLUMBER2 cases, without providing initial conditions. It might be nice to differentiate how we do this for SP (fast spinup, ~20 or 40 years) vs. BGC (more involved, like NEON) cases. Would that be difficult to integrate into the run_towers workflow? |
That sounds good. I have successfully run the AD & postAD case (with a bit of hard-coding), so this will require the following updates, which should be feasible:
@wwieder To clarify, regarding the option for SP vs BGC, are you envisioning a flag that allows users to pick between these options? |
A few comments:
Happy to have a quick that if it's helpful. |
Ok, in that case, I'll just plan to change the default for PLUMBER to AD and add some documentation on this anticipated workflow for users. Thanks for clarifying! Why don't I plan to get that first part implemented and then we can talk more about the BGC vs. SP options. |
It seems like perhaps the SP vs BGC option should come later. It will be
useful for both PLUMBER and NEON and therefore might require more in-depth
work to do it well.
We should also create a separate tutorial for people to check the stability
of their site spin up. We apply a standard number of years for the AD and
post-AD NEON site simulations and it would be useful to help users evaluate
the stability after making changes. I don't recall that we evaluated all
sites for stability thoroughly, either, so perhaps it would also help us to
know if the number of years we use is effective everywhere.
…On Wed, Aug 7, 2024 at 11:41 AM Teagan King ***@***.***> wrote:
Ok, in that case, I'll just plan to change the default for PLUMBER to AD
and add some documentation on this anticipated workflow for users. Thanks
for clarifying!
Why don't I plan to get that first part implemented and then we can talk
more about the BGC vs. SP options.
—
Reply to this email directly, view it on GitHub
<#2406 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGHW2QOYGE75H6BHKVQVDGLZQJL4RAVCNFSM6AAAAABELMMUA6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZTHE4TINRTGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Dr. Danica Lombardozzi
she/her/hers
Terrestrial Sciences Section
Climate and Global Dynamics
NSF National Center for Atmospheric Research
Boulder, CO 80305
email: ***@***.***
office: (303) 497-1777
|
This is about ready to go, but once #2485 is in, I'll run the unit and system tests once more and perform a few final tests to make sure the various |
I just wanted to note here a few things that I still need to fix:
|
One limitation of this implementation is that if both neon and plumber cases are run simultaneously (not recommended), that the default run type becomes transient. While this could be changed by adding the following lines at line 197 to
Overall, I think it's most reasonable to expect users to run plumber and neon cases separately (although both with the run_tower command), but I'm open to others thoughts. |
Tests on derecho currently pass for The |
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.
This is great. Thanks @TeaganKing. My only bigger comment is that by default PLUMBER is typically run in SP mode. I think it's out of scope in this PR to add this additional functionality, but it's something we may want to think about down the road to define compsets with an --SP or --BGC flag
for site_name in valid_plumber_sites: | ||
|
||
# start_year and end_year are set in shell commands, so these get overwritten | ||
start_year = 2018 |
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.
Is this needed? I'll let you investigate.
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.
I changed these start and and years to be very clearly dummy years. I think this is necessary because the PlumberSite class must be implemented with a start/end time. However, this is changed later in the shell commands and is not a known parameter at the time of the object instantiation.
That said, if someone has a better suggestion for implementation, I'm all ears!
|
||
|
||
if __name__ == "__main__": | ||
unit_testing.setup_for_tests() |
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 for adding more testing. Will defer to Erik on extent and timing of tests.
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.
Just to add some detail, this system test now takes 30 minutes (each case setup takes about ten minutes). We currently test:
- setup of a NEON site (BART) with a specified experiment and output root
- setup of a NEON site (ABBY) AD case and specified output root
- setup of a PLUMBER site (AR-SLu) with a specified experiment and output root
If we were going to remove one of these for the sake of time, I would probably remove the ABBY case since it is a secondary NEON case and PLUMBER is also going to run AD as default behavior. This does however test that non-default run types are working, which is useful.
Hi @ekluzek , I have now addressed the comments from @wwieder 's review. Two outstanding issues that Will and I discussed are the following (more details in comments above):
And a software-focused review of the code would be helpful now that Will reviewed some of the functionality pieces. Before merging (and after @ekluzek 's review), I will be sure to run the following tests one last time (I ran them before Will's review but there are changes that we should test again before merging):
Lastly, note that there are some related outstanding issues that have been documented that are outside the scope of this PR. |
This PR will use the TowerSite class (parent to both NEON and PLUBMER sites) and create a Plumber2Site class as well as implement capabilities for running single point simulations at PLUMBER sites.
Contributors other than yourself, if any:
@ekluzek
@adrifoster
CTSM Issues Fixed (include github issue #):
Addresses part of #1487
Are answers expected to change (and if so in what way)?
No, this PR should be BFB. However, it should expand existing capabilities to allow users to run at PLUMBER sites.
Any User Interface Changes (namelist or namelist defaults changes)?
Additional flags will be implemented for run_neon