Post process geogrid output to compute GWD input fields directly from source data#281
Post process geogrid output to compute GWD input fields directly from source data#281islas wants to merge 27 commits into
Conversation
mgduda
left a comment
mgduda
left a comment
There was a problem hiding this comment.
I'll take more time to try out domains over different parts of the globe, but for now I thought I'd leave some minor initial comments.
|
|
||
|
|
||
| # https://stackoverflow.com/a/34325723 | ||
| def progerss_bar( iteration, total, prefix="", suffix="", precision=1, length=100, fill="*", empty="-", end="\r"): |
There was a problem hiding this comment.
Would it be better to name this function progress_bar?
| Index slices, multiple key-value pairs on the same line, | ||
| and other features are NOT supported. For full support | ||
| please utilize f90nml. | ||
| Spaces between key and value and commas does not matter. |
There was a problem hiding this comment.
"Spaces" -> "do not matter"
| self.box = box | ||
|
|
||
| self.mean = np.mean( self.box ) | ||
| # var (actulally stddev) |
|
|
||
| class SourceData: | ||
| def __init__( self, name, path ): | ||
| self._earth_radius = 6371229.0 |
There was a problem hiding this comment.
I think the WPS and WRF use 6370000.0 m as the sphere radius (MPAS uses 6371229.0 m).
| self._subgrid_m_dx = 2.0 * np.pi * self._earth_radius / self._npts_x | ||
|
|
||
| self._tile_data = TileData( | ||
| int( int( 360.0 / self._index.dx ) / self._index.tile_x ), |
There was a problem hiding this comment.
Rather than repeating int( 360.0 / self._index.dx ), would it be better to use self._npts_x?
|
|
||
| self._tile_data = TileData( | ||
| int( int( 360.0 / self._index.dx ) / self._index.tile_x ), | ||
| int( int( 180.0 / self._index.dy ) / self._index.tile_y ), |
There was a problem hiding this comment.
Would it make sense to define self._npts_y as we do for self._npts_x, and to use that value here?
|
|
||
| def main(): | ||
| parser = argparse.ArgumentParser( | ||
| "./compute_gwdo.py", |
There was a problem hiding this comment.
What do you think about removing the ./ prefix from the program name? Since this resides in the ./util subdirectory, my guess is that most users will run this as ./util/compute_gwdo.py in practice; but it's possible that users may also have an entirely separate run directory from which they will run this script.
There was a problem hiding this comment.
What about something like <path to script>/compute_gwdo.py?
There was a problem hiding this comment.
I think it would be reasonable to assume (expect?) that users have some experience working in a shell, and they will understand that they can either (1) provide a relative or absolute path to the compute_gwdo.py program when running it, or (2) add the path to compute_gwdo.py to their PATH environment variable and subsequently run compute_gwdo.py with no path specified.
| ) | ||
| parser.add_argument( | ||
| "-d", "--dataset", | ||
| help="Topographic dataset to use, in geogrid format", |
There was a problem hiding this comment.
Should we add more info here (or elsewhere?) to indicate that only global datasets on a lat-lon grid will work? For example, using the SRTM 3s data with -d SRTM_topo_3s will fail.
There was a problem hiding this comment.
A quick investigation found that taking a subset will require further work and analysis. For the sake of time I think this is sufficient to at least allow working with the global gmted data and noting it.
2 participants
These changes calculate the necessary fields in a manner that accounts for subgrid-scale orography. This in in support of subgrid orographic parameterization revisions for GWD in WRF.
Currently the gravity wave drag (GWD) input fields from WPS/geogrid are computed from averaging of the source data then performing the calculations for oa1-oa4, ol1-ol4, var, and con. This utility program instead calculates these orographic statistics directly from the source data at a subgrid-scale assuming the domain dx/dy are larger than the source data extent per value.
The code is designed to be run using the entry point
./util/compute_gwdo.pyand will use./namelist.wpsif no namelist is provided.The namelist is read to determine the geogrid domains output, source data tiles locations, and domain spacing. To avoid recalculating lat/lon positioning, the values are read from the mass staggered lat/lon locations within
geo_em.d00.nc,geo_em.d01.nc, and so on. Source data is loaded as tiles are needed to compute the orographic statistics for a given domain cell based on the dx/dy extent of the cell at that lat/lon.Once all calculations are done for all cells within a domain file, that file's original oa1-oa4, ol1-ol4, var, and con are modified with the newly calculated subgrid-scale statistics. Additionally, a
MAX_ELfield is created. This is repeated for all domains listed within the namelist.