Skip to content
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

Add support for 1D Spline interpolation on GPU #2257

Open
Tracked by #1980
sriharshakandala opened this issue Oct 19, 2023 · 17 comments
Open
Tracked by #1980

Add support for 1D Spline interpolation on GPU #2257

sriharshakandala opened this issue Oct 19, 2023 · 17 comments
Assignees

Comments

@sriharshakandala
Copy link
Member

sriharshakandala commented Oct 19, 2023

We currently use Spline1D interpolation from Dierckx package at a couple of locations in ClimaAtmos.
However, this package is not GPU compatible.

We would like to add a Spline1D function that is GPU compatible in ClimaAtmos.jl

@sriharshakandala
Copy link
Member Author

#2235

@charleskawczynski
Copy link
Member

Should we do this in a separate package? Maybe SimpleInterpolations.jl?

@sriharshakandala
Copy link
Member Author

sriharshakandala commented Oct 19, 2023

Currently, we just need a single function, so I was thinking of adding this in ClimaAtmos.jl!
But, I am fine either way!

@simonbyrne
Copy link
Member

https://github.com/JuliaMath/Interpolations.jl apparently is GPU compatible?

@Sbozzolo
Copy link
Member

Sbozzolo commented Dec 4, 2023

This would be useful for ClimaLSM as well. Lots of Spline1D are used there.

@simonbyrne
Copy link
Member

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?

  • domain (horizontal, vertical, temporal, do we have any 3D?)
  • source data (e.g. equally spaced column, lat long points)
  • target space (e.g. column, cubed sphere grid)
  • interpolation type (linear, cubic spline, any preprocessing): what are the requirements for this (e.g. smoothness, extrema, etc).

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)

@kmdeck
Copy link
Member

kmdeck commented Dec 11, 2023

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.

@Sbozzolo
Copy link
Member

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).

@simonbyrne
Copy link
Member

  • 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)

@kmdeck
Copy link
Member

kmdeck commented Dec 11, 2023

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)

@trontrytel
Copy link
Member

trontrytel commented Dec 11, 2023

The two bits that I'm aware of:

  • 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
  • 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

@simonbyrne
Copy link
Member

  • 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?

@trontrytel
Copy link
Member

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.

@simonbyrne
Copy link
Member

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)?

@trontrytel
Copy link
Member

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

@charleskawczynski
Copy link
Member

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?

@braghiere
Copy link
Member

braghiere commented Jan 22, 2024

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.

@charleskawczynski charleskawczynski removed this from the O1.2.5 1 SYPD for AMIP milestone Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants