Closed LiamBindle closed 3 months ago
Great analysis! My two cents:
Thanks @sdeastham and @LiamBindle for looking into this. My thoughts:
I agree, the use of albedo for ice cover is a kludge. It probably was used to implement a "tie-breaker" because some of the earlier met fields (GEOS-3, GEOS-4) had different land/water/ice flags. But we know that MERRA-2 and GEOS-FP now use the same convention for land/water/ice, so we should get rid of the ALBEDO dependency.
I wasn't aware that PARDF, PARDR were actually PARDFLAND, PARDRLAND. This might have been a change in the GMAO file specification document. Agreed, we should use PARDF, PARDR over land and oceans, since there will be photosynthesis in the oceans that generate biogenic emissions.
Thanks @yantosca and @sdeastham for your thoughts! Since you both agree the PARDR, PARDF update is desireable, and that we can stop using ALBEDO as a proxy for surface type, I'll go ahead and mark both questions as resolved.
Thanks again for your input!
Just a quick update. There are in fact some missing values in TROPPT. They are pretty infrequent, but they are there every once in a while, and they need to be filled (GCHP crashes otherwise).
Dang. Ben Auer may have some ideas on a way to fill NaNs before regridding (using a "typical" value would probably be OK, if these are very infrequent)?
Or we could use one of the other tropopause fields (based on momentum). Not sure how much that would change the base run though.
It actually crashes here believe it or not. Any idea why that might be? It also only crashs at the native resolution (if it's regridded to say C24 online it works OK).
I'd be worried about what the regridding is doing though - if it's treating the NaN as some fill value, it would be nice to know what that fill value is. I'm guessing that if it's not regridded then MAPL is just passing a NaN indicator through which is upsetting the code at the point @LiamBindle indicated, but that if it IS regridded then the value becomes "good" after the NaN is treated through some unknown process (ideally ignored, but I doubt it)
Good point—I'm not sure. I'll ask about that in our MAPL telecon next Thursday. Anyways, I thought this was worth noting for when we move to native/minimally-pre-processed metfields in the future.
@LiamBindle if it crashes at that point, it could be an e.g. out of bounds error in the pointer field. or something like that.
@yantosca It says it's a floating point exception there. Do you why if/why that could trigger an FPE?
It could be that the pointer is still pointing to NULL() (and thus has a denormal value). Or the pointer hasn't been allocated.
Re: https://github.com/GEOS-ESM/MAPL/issues/284#issuecomment-784353502 (here to avoid a tangent in the MAPL discussion)
I think we should work towards eliminating metifeld preprocessing as it is now. The programs haven't seen much love in a few years (there are incompatibilities with modern compilers), and most of the preprocessing is trivial/redundant with modern GC-Classic and GCHP capabilities.
In the near-term, the preprocessing could be rewritten as NCO and CDO scripts. This would be maintainable and pretty clean. Rewriting as NCO/CDO scripts should be pretty easy, and it can be started any time (this thread demonstrates our preprocessing programs aren't doing anything we couldn't do with NCO/CDO).
Direct ingest of fields from GEOS would be a great capability, but some level of preprocessing is likely still required at least for the official metfields (subsetting at least).
Agreed that the current processors should be eliminated. My goal is to at least make it possible to ingest the met fields directly - or at least remove as many barriers as possible. Vertical flipping strikes me as something that falls into the "avoidable oversight" capacity such that I'd like to fix it (much like finding a reliable fix for albedo and tropopause issues), but I agree that the subsetting issue is likely to make many (most?) users still rely on some level of preprocessing.
One caveat: I'm not sure what the long term status is of NCO and CDO in terms of support or development - it would be good to check that with someone at NCAR. Question would be whether we use NCO/CDO or Python 3.
Agreed.
I'd suggest NCO and CDO though because it restricts the sciprts to well-established and "standard" operations—it would be more transparent. NCO and CDO are also compliant with common conventions like appending operations to the "history" attribute, and it would be ideal if we could avoid deviating from conventions unless it's warranted.
I'm a big Python advocate in general (personally I like Python more than NCO/CDO), but it's easy to do wonky custom things in Python, and compliance with conventions isn't automatic.
Hi all, I'm late to the party on this issue. All looks good, but I'm wondering about the cloud fraction calculation that I think is still part of the pre-processing. I'm referring to this set of equations. I think the solution we talked about was to do the calculation at run-time, prior to regridding the inputs needed for the calculation. Is this still on the radar?
Closing out this issue
Hi everyone, this is a discussion/documentation thread related to running GCHP (and more broadly GEOS-Chem) with native MERRA2 metfields. Currently, I'm working on getting GCHP running with native MERRA2 metfields as a part of AIST:
The first section (below) is documentation of the things I learned from setting GCHP up to run off the MERRA2 C180 archive. The second section ("Questions") is a condensed description of some open questions I have.
Documentation
This section contains documentation of what I learned from (1) setting GCHP up to run with the MERRA2 C180 archive, and (2) structural/definition differences I found between our current MERRA2 metfields and this new MERRA2 C180 archive. This section is partly a sticky for documenting this info, because it might be useful in the future/to others.
Here are the relavant parts of my ExtData.rc for running off this C180 MERRA2 archive (note:
./CSMetDir/
is a directory with metfields that I flipped vertically offline): ExtData.txtRequired inputs
We use the following variables from the following MERRA2 collections (these are for Lizzie's C180 MERRA2 run):
The total size of the raw granules is ~2 GB/hour (or ~17.5 TB/year). The total size of subsetted and compressed granules is 0.24 GB/hour (or ~2 TB/year). These are both for MERRA2 at C180.
Problems
tavg1_2d_rad_CSx:ALBEDO
The native field is 1-hour time average surface albedo; at night ALBEDO is _FillValue. We preprocess to a 24-hour time average, which only includes daytime values; we assign albedo 0.85 for polar night.
Below is an a comparison of StateMet%ALBD for January 2, 2017.
Who it affects
Standard simulation
Albedo is used in
GeosCore/calc_met_mod.F90
to determine the surface type, specifically theIsLand
,IsWater
,IsIce
andIsSnow
flags for a grid-box. Note that the LWI metfield is a flag for land (1), water (0), and ice (2).If State_Met%ALBD is NaN (night-time), these comparisons evaluate to false. Related: http://acmg.seas.harvard.edu/geos/wiki_docs/merra/MERRA_LWI_flags.pdf
Albedo is also used in HEMCO as a proxy for land type. It is reference:
Specialty simulations
Albedo is used in RRTMG and APM simulations.
Proposed Solution
Proposed solution 1
GeosCore/calc_met_mod.F90
so it determinesIsLand
,IsWater
,IsIce
andIsSnow
based on fractional area:Note: Technically, a more accurate approach would be using derived exports for surface areas (FRXXXX*AREAM2) since the grid-boxes are quasiuniform. Using FRXXXX will slightly favor the grid-boxes towards the edges and corners of the face. The difference in weighting, however, it probably quite small.
Proposed solution 2
We set albedo to its previous value if it's undefined.
tavg1_2d_lnd_CSx:PARDF,PARDR
These fields are the downwelling photosynthetically active radiation (PAR) diffuse (DF) and direct (DR) flux at the surface. Previously we used the "PARDFLAND" and "PARDRLAND" fields from from the tavg1_2d_lnd collection; the oceans are masked in these fields. The current metfields that I'm looking at have "PARDF" and "PARDR" which do not mask the oceans.
Below is a comparison of PARDF and PARDR for January 2, 2017. Note that these are different versions of MERRA2. The point of these comparisons is to identify structural/definition differences in the fields (like masking).
PARDF:
PARDR:
The difference worth noting is the current GC metfields mask PARD[RF] over the oceans, whereas the new native metfields don't.
Who it affects
MEGAN emission (negligible)
These fields are used for biogenic emissions, specifically, MEGAN. Here is the 1-day benchmark results for
InvMEGAN_*
: MEGAN_emis_native_par.pdfIt looks like MEGAN emissions are explicitly masked for land-only. Therefore, the differences from this incoming change to PARD[RF] look like they're negligible.
tavg1_2d_lnd_CSx:SNOMAS
In old versions of GEOS, SNOMAS for ice-covered areas was arbitrarily set to 4 m. The current GEOS-Chem metfield preprocessing step converts the native SNOMAS values to the older definition (it sets it to 4 m for ice-covered areas).
Who it affect (no one?)
I don't see
SNOMAS
used anywhere in GEOS-Chem or HEMCO. Therefore, I don't think this affects anyone.Notes
Questions