-
Notifications
You must be signed in to change notification settings - Fork 10
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
Preallocate thermal state #589
Conversation
5bedf2e
to
f5897b9
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.
I think we should discuss where the ts is allocated/stored. In this particular case, I think it could make sense to store it/add it to p
in:
p.drivers.ts_atmos
, and update not withevaluate!
like the other driver variables, but instead update with theset_atmos_ts!
function you wrote. We already have anupdate_drivers
function which this would be easy to add to. This is consistent also in that it will update only update whenupdate_drivers
is called (as a callback), which is when the other drivers are updated, and not every timestep/stage (even though the drivers may not be changing each step).
More generally - if we need to add scratch variables - we can do so pretty easily via our existing auxiliary_vars
and boundary_vars
functionality. We may already have some, actually. then they would be stored in p.soil.scratch
(e.g.) and we can choose which models need them/for which boundary conditions. We could also make a new function like you did and add scratch variables for a model to p.scratch
, like we do for driver variables. But that is a little bigger of a job and I dont think it is needed for this PR.
if certain boundary conditions or source terms require scratch, but others dont, we could make a |
f5897b9
to
7ff391a
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.
This looks great! I agree with Kat's comment, and it looks like those changes have already been incorporated.
Can we fully remove the construct_atmos_ts
function and remaining calls to it now? (e.g. in exp/Standalone/Soil/evaporation.jl, and a couple of the tests)
For GPU compatibility
0dc9767
to
01f24d2
Compare
01f24d2
to
36dc942
Compare
36dc942
to
87de665
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.
This looks good to me, thank you! nice improvement to the code.
Fixes #588
Leads to x2 improvement:
https://buildkite.com/clima/climaland-benchmark/builds/65#018f3174-1371-42ee-8dc2-eca52228dc0c
Average time: 5.3 s
https://buildkite.com/clima/climaland-benchmark/builds/53#018f3104-e10b-4e7e-af80-0a2476646201
Average time: 10 s