-
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
dss operations within coupler pass an unused t
argument.
#396
Comments
@akshaysridhar @sriharshakandala @kmdeck As @gdecker1 found earlier, Float32 runs now break in ClimaLSM due to For some reason our FT32 Buildkite was set with FT64, which is why we didn't catch this earlier! Error is reproducible if the driver on this branch is run interactively. (Note, FT32 didn't cause problems in these interactive Coupler runs before the ClimaLSM.dss! PR. ) Unless we're doing something silly here, are you all happy to remove the type specification (like we did in the coupler #387) in ClimaLSM, before this issue gets resolved in ClimaTimeSteppers? As it stands, we can't test AMIP for FT32. |
Adding notes from Slack here: ( |
You should probably just drop the unnecessary |
hi all - catching up here. We may need to do this in multiple functions because we had assumed that |
Hi @kmdeck , thanks for following up on this! 🚀 That's right! Looks like removing the type specification would be the quick (and probably only) fix. Thanks @dennisYatunin for the explanation. I agree that it would be better to have consistent types, but I also get the float precision issue. Do you guys have tests that run with Float32? |
We have unit tests that run with Float32 but all of our integrations (in experiments, etc) use Float64, I think. Ill make sure we can run with Float32 before merging anything! |
@LenkaNovak it turns out that we have implicit requirements that t be the same float type as the state in a lot of places. so it will be a bigger change for us to get this to run. For example, whenever we prescribe time varying BC (reanalysis data, etc), the BC ends up being the same type as t, or a combination of quantities that are of type (t) and of the state FT). what is the priority on this? |
Hmm... I thought you guys don't use the |
The issue is actually that we assume t is the same type as the state in many places (not just here - also in time varying boundary conditions, using renalysis data, etc). We didnt adequately test running with Float32; I think since switching to ClimaTimesteppers we lost this capability/can only run with Float64. |
It depends on what right now means. It's not crucial, I think, for the 4-6 weeks or so. But beyond that, we'd like to be able to do coupled runs (on GPUs) in Float32. |
It's also worth noting that we will probably continue to avoid using |
Following the
CTS
interface, theweighted_dss_slab!
function definition requires a thirdt
(time) argument which is unused within theClimaCore.Spaces.weighted_dss!
function. We may want to remove this from our general design pattern.The text was updated successfully, but these errors were encountered: