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

Interpolation schemes #43

Open
NoraLoose opened this issue Jun 18, 2024 · 3 comments
Open

Interpolation schemes #43

NoraLoose opened this issue Jun 18, 2024 · 3 comments
Milestone

Comments

@NoraLoose
Copy link
Collaborator

NoraLoose commented Jun 18, 2024

We may have to change the interpolation scheme at several places in roms-tools. So far, roms-tools uses linear interpolation because this is the only scheme (besides nearest neighbor interpolation) that xarray supports when interpolating over multiple dimensions.

The MATLAB-based scripts use a modified akima scheme for the following fields:

  • for the topography fieldhraw, see here; since a smoother is applied after this, the interpolation scheme does arguably not matter that much
  • for the zonal and meridional wind forcing, as well as the SWR correction, which leads to significant differences in the MATLAB0 vs. python-generated forcing fields, see Atmospheric forcing #41. An argument for using more complex interpolation schemes for wind is that with linear interpolation the wind stress curl (which is the dynamically relevant quantity) looks ugly with unphysical features.

For the remaining atmospheric forcing fields and tidal forcing fields, the MATLAB-based scripts use linear interpolation.

@NoraLoose
Copy link
Collaborator Author

I started refactoring the code to use xesmf for the regridding.

However, xesmf (and supposedly ESMF) only supports 2D regridding in horizontal dimensions. This works fine for the tidal forcing and surface forcing. But we need more than that, namely

  • for the initial conditions: 3D regridding
  • for the boundary forcing:
    a) 2D (one depth, one horizontal dimension) regridding onto the 4 boundaries, resulting in four 2D regrid operations per time step
    b) alternatively, 3D regridding, and then just grab the 4 boundaries of the interpolated field, resulting in one 3D regrid operation per time step.

Regridding the boundary forcing is an expensive operation because it may have to happen for many time steps (for the initial conditions we only have one time step). So it would be great to be able to reuse pre-computed weights for the boundary forcing at each time step, no matter if we use option a) or b).

The question is: Is there a library out there that can help us with the weight generation for the boundary forcing, or do we need to write something new?

@matt-long @TomNicholas @sdbachman

@TomNicholas
Copy link
Member

TomNicholas commented Sep 12, 2024

What type of regridding is this? If it's regridding within the same rectilinear coordinate system then we might have a few more options.

The question is: Is there a library out there that can help us with the weight generation for the boundary forcing, or do we need to write something new?

I don't know, but if it already exists it should be in this list, and if we need something new we should perhaps join forces with the people already thinking about this in the discussions linked at the bottom of that page.

@NoraLoose
Copy link
Collaborator Author

What type of regridding is this?

We need regridding

regular lat-lon grids --> curvilinear (ROMS) grids

Okay, I will look through this list and report back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants