ltmurray
commented
3 months ago IIRC, the changes I made were to get the nested GEOS-FP grid to actually be at the same horizontal resolution as the underlying GEOS-FP meteorology, instead of being offset by half-resolution (thereby, smearing the meteorology as it was re-gridded by HEMCO on read). It is most common for raster domains to be described by their full extents, so assuming the code still correctly calculates the grid we want, I'd recommend we switch to the convention of domain edges in the description of the yml documentation.
nicholasbalasus
yantosca
Your name
Nick Balasus
Your affiliation
Harvard University
What happened? What did you expect to happen?
In the documentation, the longitude and latitude ranges are described as being grid box centers (lon and lat). For the nested simulation, I am wondering if these are actually interpreted as grid box edges.
In
input_mod.F90, NX and NY are defined based on the difference between the max and min divided by the resolution. This calculation makes sense for grid box edges (e.g., for two grid cells 0.5° in width centered on 1.0° and 1.5°, the number of grid cells is given by (1.75°-0.75°)/0.5° = 2, not (1.5°-1.0°)/0.5° = 1).https://github.com/geoschem/geos-chem/blob/6a26a6bab094dd8230247aeeb9a252b53c543417/GeosCore/input_mod.F90#L1093-L1102
Tagging @ltmurray as it looks like they wrote the code that uses this in
gc_grid_mod.F90.What are the steps to reproduce the bug?
n/a
Please attach any relevant configuration and log files.
No response
What GEOS-Chem version were you using?
14.4.2
What environment were you running GEOS-Chem on?
Local cluster
What compiler and version were you using?
gcc 10.2.0
Will you be addressing this bug yourself?
Yes, but I will need some help
In what configuration were you running GEOS-Chem?
GCClassic
What simulation were you running?
CH4
As what resolution were you running GEOS-Chem?
0.25 x 0.3125
What meterology fields did you use?
GEOS-FP
Additional information
No response