Atmospheric forcing #41
Conversation
|
@TomNicholas pinging you in case you have any thoughts on this PR. But no rush if you are busy with other stuff. |
| import xarray as xr | ||
| import dask | ||
| from dataclasses import dataclass, field | ||
| from roms_tools.setup.grid import Grid | ||
| from datetime import datetime, timedelta | ||
| import glob | ||
| import numpy as np | ||
| from typing import Optional, Dict, Union | ||
| from scipy.sparse import spdiags, coo_matrix | ||
| from scipy.sparse.linalg import spsolve | ||
| from roms_tools.setup.fill import lateral_fill | ||
| import warnings | ||
| import calendar |
There was a problem hiding this comment.
We want to be running the linting tool isort on this repo, which would automatically organize these according to which are builtins vs external dependencies vs internal imports.
There was a problem hiding this comment.
Would it be useful to use pre-commit to run isort and other linting tools? https://pycqa.github.io/isort/docs/configuration/pre-commit.html
There was a problem hiding this comment.
Definitely! ruff does a lot of the formatting as one tool now though, e.g.
https://github.com/zarr-developers/VirtualiZarr/blob/main/.pre-commit-config.yaml
There was a problem hiding this comment.
Excellent! @dafyddstephenson you might want to steal what Nora has done here for the C-Star repo.
| # Load the dataset | ||
| with dask.config.set(**{'array.slicing.split_large_chunks': False}): | ||
| # initially, we wawnt time chunk size of 1 to enable quick .nan_check() and .plot() methods for AtmosphericForcing | ||
| ds = xr.open_mfdataset(self.filename, combine='nested', concat_dim=self.dim_names["time"], chunks={self.dim_names["time"]: 1}) |
There was a problem hiding this comment.
You probably want coords='minimal', compat='override' here - see pydata/xarray#8778
There was a problem hiding this comment.
Thanks! Done via commit 0556bf1.
Co-authored-by: Tom Nicholas <[email protected]>
|
@TomNicholas do we want to wait until the dask deployment issue is fixed to merge this PR? Maybe we should defer this to another PR? |
As long as this code runs successfully for some dask setup somewhere, we can separate out the problem of deploying dask on other machines. So if this runs on Casper/your laptop that's good enough to merge this IMO. Generally merging something which works first, then creating separate issues to track getting it to run in other setups or improving performance is a good idea. |
|
Sounds good! In my latest test, it actually ran on Perlmutter as well (with the default |
Completes step 4 in #1.
This adds three classes:
AtmosphericForcing,SWRCorrrection, andForcingDataset, where the first two are the ones the user will interact with. I added an example notebook to the documentation that illustrates how the classes can be used in practice.ToDo
There are two things left to do, and I will open two separate issues to address these:
Python vs. MATLAB-based results
Both the
roms-toolsand the MATLAB-based scripts create 7 atmospheric forcing fields that are necessary to run a ROMS simulation. To create these fields both follow the same two-step procedure:Here is a comparison for all 7 fields for a randomly chosen time step. For each atmospheric field, there are 4 panels.
We make the following observation:
Tair,qair,rain,lwrad, theroms-toolsand the MATLAB-based scripts lead to very similar results over the ocean. The reason is that both solutions use linear interpolation.uwnd,vwnd, andswradbecause for the time beingroms-toolsuses linear interpolation while the MATLAB-based scripts use a modified akima scheme.