-
Notifications
You must be signed in to change notification settings - Fork 170
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
[FEATURE REQUEST] Better documentation about boundary conditions and masks in for nested-grid simulations #1596
Comments
Thanks @jennyfisher for the feedback. Would you be able to provide examples that didn't work and that did work? We can incorporate that into the doc. |
Sure! Also tagging @smm997 as the one who's actually doing the work. :) We're running a nested grid simulation over a non-standard Asian domain with longitude bounds 100.0-140.0 and latitude bounds 20.0 to 50.0. In addition to global emissions, we have two Asian inventories that cover different regions. Example shown for one part of species TOLU from each inventory. In the Base Emissions section:
In the Masks section:
Because MEIC has a larger hierarchy (56) than KORUS (55), and both have a larger hierarchy than the CEDS global inventory (5), what should happen is that we get CEDS emissions globally, overwritten by KORUS in the 1006 mask region, further overwritten by MEIC in the (smaller) 1009 mask region. Indeed, this is what happens in our global simulations. In our nested simulations, however, the HEMCO-defined mask region boundaries (i.e. 70/10/140/60 for the 1009 mask) extend beyond the bounds of our domain, so the simulation treats all 3 as effectively "global" and only reads/uses the emissions for the highest hierarchy (MEIC). That ends up being a problem as the actual China mask (the 1s in the file) is much smaller than the 70/10/140/60 rectangle and smaller than our domain, so we need the underlying emissions from the KORUS inventory for the rest of the domain (in our case we don't need CEDS - KORUS covers the region - so I'm ignoring that here, but it would have the same issue). We suspected this was the root of the problem and found it was true when looking at a verbose HEMCO log that had a number of messages about skipping reading KORUS emissions because of MEIC. The fix is to make the boundaries of the defined mask region at least a little bit smaller than the boundaries of the nested domain (which requires inspecting the mask itself to make sure we're not dropping gridboxes we shouldn't). In our case, we were able to fix by changing I think there could easily be some automated error checking here, i.e. in this case identifying that these two masks were bigger than our domain and prompting the user to check this. I'm also thinking perhaps the defaults used in the HEMCO_Config.rc could be a bit more precise, going just to the edges of where the mask=1 rather than a semi-random choice about where to define the bounding box (most likely based on someone eyeballing a global map at some stage). Hope that helps! |
Thanks @jennyfisher. In the future we can try to add better error checking but it may be a while before we can get to this. |
Thanks @yantosca - might be useful if the discussion today about adding KORUS + MEIC emissions inventories leads to both ending up in the model! :) |
Hi @jennyfisher @smm997, I've added a section to ReadTheDocs describing this issue (although I made it a more general w/o reference to KORUS or MEIC). See: https://hemco.readthedocs.io/en/latest/hco-ref-guide/hemco-config.html#caveat-for-simulations-using-cropped-horizontal-grids This is in the "latest" version of ReadTheDocs (which is our |
I can close out this issue since this update is now in the GEOS-Chem 14.1.0 / HEMCO 3.6.0 development branch. |
Thanks @yantosca ! |
@jennyfisher: Further developments will be tracked at geoschem/HEMCO#187 |
Request a new GEOS-Chem feature:
Hi there GCST,
We've just spent a lot of time debugging an emissions issue in our nested run. In the end it was (sort of) our fault, but I think some clarifications in the documentation (or possibly some automated checking if that is possible) would have prevented it.
The issue had to do with mask boundary definitions in HEMCO_Config.rc. It's actually described in a global context here: https://hemco.readthedocs.io/en/stable/hco-ref-guide/more-examples.html?highlight=defining%20masks#exercise-care-in-defining-mask-regions
From that page:
The issue we had was with a pre-defined mask in HEMCO_Config.rc, which was defined with boundaries that were larger than our nested region, triggering the issue described. It took a lot of digging to find this.
My suggestions would be:
Thanks!
-Jenny
The text was updated successfully, but these errors were encountered: