Wrong surface type field when using raw meteorology file

[yuanjianz]

Name and Institution (Required)

Name: Yuanjian Zhang Institution: WashU

Confirm you have reviewed the following documentation

• [x] Support guidelines
• [x] User manuals
• [x] Debugging GEOS-Chem and HEMCO errors
• [x] Current and past Github issues

Description of your issue or question

Issue

I am evaluating dust discrepancies between processed wind and raw mass flux GEOS-IT fullchem benchmark. Difference shown in BudgetConvection and further WetLossConvFrac indicate something is wrong with raw run. *left panel is processed wind

Over-water WetLossConvFrac in raw mass flux run is equivalent to land, in contrary to processed wind run.

    IF ( .NOT. VUD_DEFINED ) THEN
       IF ( State_Met%IsWater(I,J) ) THEN
          VUD = 5e+0_fp
       ELSE
          VUD = 10e+0_fp
       ENDIF
    ENDIF

    IF ( Vud > TINY_FP ) THEN
       F = 1.0_fp - EXP( -K * TMP / Vud )
    ELSE
       F = 0.0_fp
    ENDIF

GEOS-Chem WetScav module determines VUD based on surface type IsWater and further determines WetLossConvFrac. The image above apparantly indicates there is something wrong with IsWater in raw meteorology runs.

Test

I ran several tests using

• raw cube-sphere mass flux
• raw cube-sphere wind
• raw lat-lon wind

All raw meteorolgy input runs show wrong surface type over water comparing to processed meteorology input. *left panel is processed wind

However, all meteorological fields (FRLAND, FRSNO, FRLAKE, FRLANDIC, FRSEAICE, FROCEAN) used to determine IsWater have slight changes in diagnositics between processed and raw, except FRSNO, which is showing strange biases. *left panel is processed wind

Temporary fix

To further investigate the issue, I replaced FRSNO and FRSEAICE, which are the only time-varying inputs among those mentioned above, to processed version. The results show the IsWater issue is fixed, but I am still not sure why.

I am doubting it comes from MAPL ExtData handling since the inputs themself seem fine. It would be great if someone familiar with raw meteorology fields and how MAPL handles them can offer some help.

[lizziel]

@yuanjianz, interesting. I will take a look at this.

[lizziel]

I believe the primary issue you are running into is a bug in use of State_Met%FRSNO when setting the State_Met logicals for surface type (land, water, ice, or snow). This line should be this instead: FRSNO = State_Met%FRLAND(I,J)*State_Met%FRSNO(I,J)

Here is before the fix:

And here is after the fix:

The question then is why is this happening for raw files only. I suspect it is because the raw files contain missing entries for FRSNO where there is no land. For processed files we set all values to zero except where FRSNO has values. This may also explain discrepancies in the other fraction fields but I need look into this further to verify.

[lizziel]

I confirmed that FRSNO is being set equal to missing values in the model (1e15!). These values are not showing up in plots because they correspond exactly to the missing value metadata (or perhaps fillvalue, not sure which). You can see this in the output field for Met_FRSNO.

Met_FRSNO in processed GMAO file run sample output:

  0, 2.065287e-09, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0,
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0.0003413867, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0,
  0, 0, 0, 0, 0, 0, 0, 0.003698541, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0,
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ;

Met_FRSNO in raw GMAO file run sample output:

  0, 2.139596e-09, 0, 0, 0, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, 
    _, _, _,
  0, 0, _, _, 0, _, _, _, _, 0.05538759, _, _, _, _, _, _, _, _, _, _, _, _, 
    _, _,
  0, 0, _, _, _, _, _, 0.0521307, _, _, _, _, _, _, _, _, _, _, _, _, 0, _, 
    _, _,
  0, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
  0, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
  0, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _ ;

Multiplying values by FRLAND effectively removes the missing values. I will put together a PR with a fix that covers all uses of State_Met%FRSNO.

Note that the regridding is also affected by this. Regridding using processed files incorporates zeros during the regridding. Regridding with missing values skips the missing values completely in MAPL. I believe this is why we see the higher values of Met_FRSNO in the raw file run towards the poles.

Meteorology input files:

State_Met%FRSNO output:

[lizziel]

There remain small differences between the raw and processed files for the fraction surface types in the constant file. FRSEAICE (time-varying) is exactly the same between raw and processed. I am not sure where these differences in the constants file are coming from. They are small but should be looked at eventually.

Note that I have used GEOS-FP for all of these analyses.

[yuanjianz]

Thanks @lizziel, really appreciate your help. The surface type anomaly could have some impacts on raw file fullchem benchmark including wet scavenging and several chemistry processes. I will rerun the raw mass flux fullchem benchmark again after the fix.

[lizziel]

See https://github.com/geoschem/geos-chem/pull/2254 for the fix that will go into 14.4.0. The updates are more extensive than the quick fix I gave earlier in this thread, but both are sufficient to address the issue in full chemistry runs using raw GMAO input meteorology files.

[lizziel]

The fix for this issue is now merged into 14.4.0.