Read CO2 from file #3522
Merged
Read CO2 from file #3522
+205
−13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sbozzolo
force-pushed
the
gb/co2
branch
6 times, most recently
from
d26180d to
c6460fd
Compare
Sbozzolo
force-pushed
the
gb/co2
branch
2 times, most recently
from
0680575 to
d40b6db
Compare
szy21
approved these changes
Jan 17, 2025
NEWS.md
Outdated
| ### Read CO2 from file | ||
|
|
||
| `ClimaAtmos` now uses data from the Mauna Loa CO2 measurements to set CO2 | ||
| concentration. This is currently only relevant for radiation transport with |
There was a problem hiding this comment.
Suggested change
| concentration. This is currently only relevant for radiation transport with | |
| concentration. This is currently only relevant for radiation transfer with |
src/cache/tracer_cache.jl
Outdated
| function co2_cache(::PrescribedCO2, Y, start_date) | ||
| FT = Spaces.undertype(axes(Y.c)) | ||
| # co2 is well mixed, so it is just a number, but we create an array to | ||
| # update it with evalaute! |
There was a problem hiding this comment.
Suggested change
| # update it with evalaute! | |
| # update it with evaluate! |
szy21
reviewed
Jan 17, 2025
Sbozzolo
force-pushed
the
gb/co2
branch
3 times, most recently
from
900462f to
ee10e56
Compare
Sbozzolo
added a commit
to CliMA/ClimaCoupler.jl
that referenced
this pull request
Jan 17, 2025
CO2 is read in Atmos: CliMA/ClimaAtmos.jl#3522
Sbozzolo
added a commit
to CliMA/ClimaCoupler.jl
that referenced
this pull request
Jan 17, 2025
CO2 is read in Atmos: CliMA/ClimaAtmos.jl#3522
Sbozzolo
added a commit
to CliMA/ClimaCoupler.jl
that referenced
this pull request
Jan 17, 2025
CO2 is read in Atmos: CliMA/ClimaAtmos.jl#3522
Sbozzolo
force-pushed
the
gb/co2
branch
3 times, most recently
from
7b2558c to
3c8bd25
Compare
szy21
approved these changes
Jan 18, 2025
Sbozzolo
force-pushed
the
gb/co2
branch
5 times, most recently
from
077ed0c to
5f465a8
Compare
Sbozzolo
added a commit
to CliMA/ClimaUtilities.jl
that referenced
this pull request
Jan 21, 2025
Recent PRs in `ClimaCore` and `ClimaComms` (CliMA/ClimaCore.jl#2114 and CliMA/ClimaComms.jl#103) changed how contexts are adapted to GPUs. This, coupled with CliMA/ClimaAtmos.jl#3522, prompted me to look again at the `TimeVaryingInputs0D` struct. This struct is used in two main ways: - to set site-level forcings/parameters (in ClimaLand) - to set fields that have constant value on the globe (e.g., CO2) The previous implementation achieved GPU compatibility by moving everything to the GPU. This is not a great idea when the operation being performed is some variation of linear interpolation in one dimension (time) and for just one data point, as there is nothing really to be parallelized. This choice was made because initially this feature was only used in single-site ClimaLand runs, where all we cared about was to be able to run on GPU. The other day, I realized that I could have GPU compatibility in a much simpler and more robust way by leveraging the `fill!` function. With this commit, 0D interpolation (1D in time, 0D spatially) is changed to be always on the CPU, and the result is written to the Field (or destination in general) using `fill!`. As a result, the CUDA extension is no longer needed.
Sbozzolo
added a commit
to CliMA/ClimaUtilities.jl
that referenced
this pull request
Jan 21, 2025
Recent PRs in `ClimaCore` and `ClimaComms` (CliMA/ClimaCore.jl#2114 and CliMA/ClimaComms.jl#103) changed how contexts are adapted to GPUs. This, coupled with CliMA/ClimaAtmos.jl#3522, prompted me to look again at the `TimeVaryingInputs0D` struct. This struct is used in two main ways: - to set site-level forcings/parameters (in ClimaLand) - to set fields that have constant value on the globe (e.g., CO2) The previous implementation achieved GPU compatibility by moving everything to the GPU. This is not a great idea when the operation being performed is some variation of linear interpolation in one dimension (time) and for just one data point, as there is nothing really to be parallelized. This choice was made because initially this feature was only used in single-site ClimaLand runs, where all we cared about was to be able to run on GPU. The other day, I realized that I could have GPU compatibility in a much simpler and more robust way by leveraging the `fill!` function. With this commit, 0D interpolation (1D in time, 0D spatially) is changed to be always on the CPU, and the result is written to the Field (or destination in general) using `fill!`. As a result, the CUDA extension is no longer needed.
Sbozzolo
added a commit
to CliMA/ClimaUtilities.jl
that referenced
this pull request
Jan 21, 2025
Recent PRs in `ClimaCore` and `ClimaComms` (CliMA/ClimaCore.jl#2114 and CliMA/ClimaComms.jl#103) changed how contexts are adapted to GPUs. This, coupled with CliMA/ClimaAtmos.jl#3522, prompted me to look again at the `TimeVaryingInputs0D` struct. This struct is used in two main ways: - to set site-level forcings/parameters (in ClimaLand) - to set fields that have constant value on the globe (e.g., CO2) The previous implementation achieved GPU compatibility by moving everything to the GPU. This is not a great idea when the operation being performed is some variation of linear interpolation in one dimension (time) and for just one data point, as there is nothing really to be parallelized. This choice was made because initially this feature was only used in single-site ClimaLand runs, where all we cared about was to be able to run on GPU. The other day, I realized that I could have GPU compatibility in a much simpler and more robust way by leveraging the `fill!` function. With this commit, 0D interpolation (1D in time, 0D spatially) is changed to be always on the CPU, and the result is written to the Field (or destination in general) using `fill!`. As a result, the CUDA extension is no longer needed.
Sbozzolo
added a commit
to CliMA/ClimaUtilities.jl
that referenced
this pull request
Jan 21, 2025
Recent PRs in `ClimaCore` and `ClimaComms` (CliMA/ClimaCore.jl#2114 and CliMA/ClimaComms.jl#103) changed how contexts are adapted to GPUs. This, coupled with CliMA/ClimaAtmos.jl#3522, prompted me to look again at the `TimeVaryingInputs0D` struct. This struct is used in two main ways: - to set site-level forcings/parameters (in ClimaLand) - to set fields that have constant value on the globe (e.g., CO2) The previous implementation achieved GPU compatibility by moving everything to the GPU. This is not a great idea when the operation being performed is some variation of linear interpolation in one dimension (time) and for just one data point, as there is nothing really to be parallelized. This choice was made because initially this feature was only used in single-site ClimaLand runs, where all we cared about was to be able to run on GPU. The other day, I realized that I could have GPU compatibility in a much simpler and more robust way by leveraging the `fill!` function. With this commit, 0D interpolation (1D in time, 0D spatially) is changed to be always on the CPU, and the result is written to the Field (or destination in general) using `fill!`. As a result, the CUDA extension is no longer needed.
Sbozzolo
added a commit
to CliMA/ClimaUtilities.jl
that referenced
this pull request
Jan 21, 2025
Recent PRs in `ClimaCore` and `ClimaComms` (CliMA/ClimaCore.jl#2114 and CliMA/ClimaComms.jl#103) changed how contexts are adapted to GPUs. This, coupled with CliMA/ClimaAtmos.jl#3522, prompted me to look again at the `TimeVaryingInputs0D` struct. This struct is used in two main ways: - to set site-level forcings/parameters (in ClimaLand) - to set fields that have constant value on the globe (e.g., CO2) The previous implementation achieved GPU compatibility by moving everything to the GPU. This is not a great idea when the operation being performed is some variation of linear interpolation in one dimension (time) and for just one data point, as there is nothing really to be parallelized. This choice was made because initially this feature was only used in single-site ClimaLand runs, where all we cared about was to be able to run on GPU. The other day, I realized that I could have GPU compatibility in a much simpler and more robust way by leveraging the `fill!` function. With this commit, 0D interpolation (1D in time, 0D spatially) is changed to be always on the CPU, and the result is written to the Field (or destination in general) using `fill!`. As a result, the CUDA extension is no longer needed.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when running AMIP, ClimaCoupler is responsible for updating the concentration of CO2 used for the radiation transport. This means that:
The reason for why this was done is because originally only ClimaCoupler had the infrastructure to read in files. However, this is no longer the case and ClimaAtmos is already updating values read from files for aerosols and ozone.
This PR adds CO2 to the list.