-
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
Interface changes pulled from #90 #93
Conversation
hey! Not sure what happened, but the buildkite plots no longer are saving correctly - they did as of this PR: The file paths look fine/unchanged, so maybe more likely that the plot is not being generated? |
FT = eltype(F_A) | ||
@. slab_sim.integrator.p.bucket.ρ_sfc = ρ_sfc | ||
@. slab_sim.integrator.p.bucket.SHF = F_A | ||
function land_pull!(cs) |
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.
How do we execute the different methods of land_pull? prior to this, they dispatched on the type of land model.
I think we need land_pull!(land_sim::BucketSimulation, cs) and land_pull!(land_sim::SlabSimulation, cs). in general we will have to dispatch on the type of model, so this format might be nice for all (land, ocean, ice)?
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.
@kmdeck's suggestion works for sure, or you can do an if
block. Not terribly important imo; when the Simulations
+ CouplerState
are introduced at each level, the push/pull
operations can more easily dispatch on simulation and model type.
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.
Yeah, this was just a temporary solution for this AMIP case, until we deploy Ben's Simulations
interface, which will def allow this multiple dispatch - I should have been clearer in the PR description above. Are you guys happy with this for now, since land_pull.jl
will be scrapped eventually anyway?
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.
Hm, not sure I understand. If we leave as is, what method of land_pull! will be executed if the land model is a bucket, vs the land modeling being a slab? Alternatively, we can scrap the slab being an option for the land?
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.
(having a stand-in is fine, but my point was more to make sure the temporary soln has the capabilities we want to support)
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.
No, it is a good point! From the AMIP roadmap perspective, I don't think we need to support a thermal-slab land, but if you think it would be valuable to have it here, then I can add it. Lmk when you're free next, maybe we can chat on Zoom and decide 😎 .
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.
free anytime this morning! I'm fine losing the thermal slab land in this experiment directory though 🌤️
function land_pull!(cs) | ||
slab_sim = cs.model_sims.lnd | ||
csf = cs.fields | ||
FT = eltype(csf.F_A) |
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.
csf has FT stored directly.
ocean_pull!(slab_ocean_sim, F_A, F_R) | ||
reinit!(slab_ocean_sim.integrator) | ||
end | ||
coupler_fileds, |
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.
coupler_fileds, | |
coupler_fields, |
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.
Needs to be changed in a few other spots, too!
land_mask = cs.mask | ||
|
||
# mask of all models (1 = land, 0 = ocean, -2 = sea ice) | ||
univ_mask = parent(land_mask) .- parent(ice_mask .* FT(2)) |
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.
get FT from coupler sim object, right now it is looking up in global here I think
end | ||
|
||
prescribed_sst = true |
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.
should be read in from command line - this overwrites it. I think this is why the buildkite plot isnt being made.
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.
Also, it seems like prescribed_sst now flips between aquaplanet and AMIP. Should we be passing that in, instead? i.e. pass in a CLI called mode which is either amip or aquaplanet, rather than pass in prescribed_sst? Because prescribed_sst also affects what ice is doing. maybe a bit confusing as is.
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.
Oops! This line shouldn't be there (it was leftover from a test - nice catch!). As for changing this flag to prescribed_sst
-> mode
(or something like that), that can be done. :)
walltime = @elapsed for t in ((tspan[1] + Δt_cpl):Δt_cpl:tspan[end]) | ||
cs = coupler_sim |
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? why not use coupler_sim directly?
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.
it's needed in the next PR - I didn't want to change everything in the stepping loop only to change it all back in the next PR... 😳
end | ||
|
||
## Slab ice | ||
ice_pull!(slab_ice_sim, F_A, F_R) | ||
step!(slab_ice_sim.integrator, t - slab_ice_sim.integrator.t, true) | ||
cs.mode.prescribed_sst ? ice_pull!(cs) : nothing |
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.
should these be in a single if statement? otherwise we check multiple times.
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.
Largely looks great @LenkaNovak - this is a good intermediate update of the interface and its clear how it will converge with the sea breeze interface work. Nice to see! Some small changes to fix before merging that I noted.
It might be possible to remove some of the |
Hmm, this is really odd. Looks like this was already an issue in #89, but we hadn't picked it up. I'll investigate further. |
review fixes format
8961704
to
3146a58
Compare
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.
looks great Lenka! Nice work!
bors r+ |
90: Monthly updating of BCs from file r=LenkaNovak a=LenkaNovak # PULL REQUEST ## Purpose and Content This PR adds functionality to collect BC field information in a struct `..._info`, which is then updated each month with a new file read of the regridded data. In the next PR `..._info` will contain two Fields read from a file, which will be used for the daily interpolation. ## Benefits and Risks - benefit: prerequisite for the monthly to daily interpolation - risk: changes the way the BCs are read, but most of it is abstracted ## Linked Issues - SDI: #74 - Design: #88 ## Dependent PRs - no not merge before - [x] #87 - [x] #89 - [x] #93 ## Coupling loop performance - the macro is comparable to using functions (though `@time` larger variability). The pros and cons for this method are [here](#95), are will be revisited post AMIP (and well as including the unit test in the same file). - in either case the monthly update does not cause noticeable performance change from the previous commit for the full AMIP setup. ## PR Checklist - [x] This PR has a corresponding issue OR is linked to an SDI. - [x] I have followed CliMA's codebase [contribution](https://clima.github.io/ClimateMachine.jl/latest/Contributing/) and [style](https://clima.github.io/ClimateMachine.jl/latest/DevDocs/CodeStyle/) guidelines OR N/A. - [x] I have followed CliMA's [documentation policy](https://github.com/CliMA/policies/wiki/Documentation-Policy). - [x] I have checked all issues and PRs and I certify that this PR does not duplicate an open PR. - [x] I linted my code on my local machine prior to submission OR N/A. - [x] Unit tests are included OR N/A. - [x] Code used in an integration test OR N/A. - [x] All tests ran successfully on my local machine OR N/A. - [x] All classes, modules, and function contain docstrings OR N/A. - [x] Documentation has been added/updated OR N/A. Co-authored-by: LenkaNovak <lenka@caltech.edu>
PULL REQUEST
Purpose and Content
This PR introduces interface changes which are used in PR #90 . They are split from the main PR to make reviewing of the functionality easier. The changes here include:
push!
andpull
functions by introducing aCouplerSimulation
structif.. else..
statements when running with prescribed or modeled SSTs.SST
andSIC
in their respective simsWhile these interface changes are not part of the final coupler interface design, they facilitate the development and running of the models from the coupler in the intermediate term, and will be used in the first AMIP showcase.
Benefits and Risks
Linked Issues
see #90
PR Checklist