Open sriharshakandala opened 10 months ago
Should we do this in a separate package? Maybe SimpleInterpolations.jl
?
Currently, we just need a single function, so I was thinking of adding this in ClimaAtmos.jl
!
But, I am fine either way!
https://github.com/JuliaMath/Interpolations.jl apparently is GPU compatible?
This would be useful for ClimaLSM as well. Lots of Spline1D are used there.
Before we can make progress on solving the problem, we need to clarify exactly what the problem is.
Can we collect all the places we do this?
There will be some overlap with regridding/remapping: lets just consider places where we need it for input data (forcings, initial conditions, trace gas concentrations, topography)
Current ClimaLSM interpolating function uses:
Current ClimaLSM interpolating function uses:
- For global simulations, we use and are planning to use tempest remap for regridding parameters/forcing data read from netcdf files to the simulation grid. These would be functions of lat/long, lat/long/t, and possibly lat/long/z. Most of these fields do not need conservative remapping (e.g. temperature, soil properties), but tempest remap works for us and it may be simpler for us to use one regridding tool. Time dependence is handled via linear interpolation as a separate step currently.
- Single column runs with prescribed forcing. Right now we also use Dierckx and fit splines to these data as a function of time only. It's possible we would fit soil properties as a function of depth with a Spline1D also.
- Linear interpolation in time should be fine (we are driving with ~ hourly data to capture the diurnal cycle), but we may need to look into preserving extremes in precipitation.
Please, correct if I am wrong, but we can also assume that data is provided on constant and known time intervals (and if not, we will pre-process to do so).
- Linear interpolation in time should be fine (we are driving with ~ hourly data to capture the diurnal cycle), but we may need to look into preserving extremes in precipitation.
For things like precipitation, do you have point values or totals? (i.e. if you have totals, presumably you would want conservative interpolation so that the total interpolated precipitation matches the source data)
It looks like fluxes and precip are given as accumulations in ERA5: https://confluence.ecmwf.int/pages/viewpage.action?pageId=82870405#ERA5:datadocumentation-Table3 while for flux tower sites, precip is accumulated, but fluxes are instantaneous: https://ameriflux.lbl.gov/data/aboutdata/data-variables/ Temperature, wind speed, specific humidity in the air, etc would all be instantaneous @braghiere @AlexisRenchon could you confirm that these are the types of forcing data we would use?
It would be good to be conservative for these. but for parameters describing the soil/vegetation, a simpler regridding would suffice (but we can use a conservative one also)
The two bits that I'm aware of:
AtmosphericProfilesLibrary.jl
repo that stores profiles needed for single column test cases. It uses Dierckx spline. It will not be needed for the global runs. See an example here(lat, lon, p, t)
files with trace gases and aerosol for the global runs. My plan was to pre-process them into (lat, lon, z, t)
by myself somewhere (ClimaUtilities
?) and then use the regridding we already have. My notes on this are here
- We have
AtmosphericProfilesLibrary.jl
repo that stores profiles needed for single column test cases. It uses Dierckx spline. It will not be needed for the global runs. See an example here
Would linear interpolation suffice for these?
- We will need to read in and interpolate
(lat, lon, p, t)
files with trace gases and aerosol for the global runs. My plan was to pre-process them into(lat, lon, z, t)
by myself somewhere (ClimaUtilities
?) and then use the regridding we already have. My notes on this are here
You would still need temporal interpolation during the simulation though?
Would linear interpolation suffice for these?
Yes
You would still need temporal interpolation during the simulation though?
Yes, but very coarse one. - I have one dataset per month.
Yes, but very coarse one. - I have one dataset per month.
Does the data represent snapshots (e.g. end of month values) or averages (over the month)?
Yes, but very coarse one. - I have one dataset per month.
Does the data represent snapshots (e.g. end of month values) or averages (over the month)?
Monthly mean
domain (horizontal, vertical, temporal, do we have any 3D?)
This issue says "Add support for 1D spline interpolation on GPU", should we update the title? Or make a separate issue?
It looks like fluxes and precip are given as accumulations in ERA5: https://confluence.ecmwf.int/pages/viewpage.action?pageId=82870405#ERA5:datadocumentation-Table3 while for flux tower sites, precip is accumulated, but fluxes are instantaneous: https://ameriflux.lbl.gov/data/aboutdata/data-variables/ Temperature, wind speed, specific humidity in the air, etc would all be instantaneous @braghiere @AlexisRenchon could you confirm that these are the types of forcing data we would use?
It would be good to be conservative for these. but for parameters describing the soil/vegetation, a simpler regridding would suffice (but we can use a conservative one also)
Precipitation needs to be given as a flux too, units of mm.s-1. A mm of rain is equivalent to 1 kg.m-2. It is just a simple conversion needed. Even if it is cumulative rain in the previous 30 min, or whatever, we take that volume of rain and divide by the time window.
We currently use
Spline1D
interpolation fromDierckx
package at a couple of locations inClimaAtmos
. However, this package is not GPU compatible.We would like to add a
Spline1D
function that is GPU compatible inClimaAtmos.jl