Unreasonable CO2/CH4/OCS data in GCHP carbon simulation

[Aosrain]

Your name

Longtao Wu

Your affiliation

JPL

What happened? What did you expect to happen?

In the GCHP carbon simulation that includes all species, I am encountering the following issues with the default settings.

1. The default CO2 emissions do not accurately reflect the diurnal cycle of CO2. I adopted Hannah's CO2 emission data in GCClassic (as in the HEMCO_Config.rc), and now the CO2 emissions appear good to me, as shown in the attached CO2 figure.
2. Several variables in the default CH4 emissions had mismatched units between HEMCO_Config.rc and Extdata.rc. I updated them to ensure consistent units.
3. There are issues with converting CH4 emissions from molec/cm2/s to kg/m2/s. The output emissions are still in the magnitude of molec/cm2/s. I disabled those emission sources, such as GHGI_v2_Express_Ext, Scarpelli_Mexico and JPL_WETCHARTS. Now the CH4 emissions appear reasonable to me, as shown in the attached CH4 figure.
4. After fixing the emission issues, no apparent issues are observed in the CO simulations, as shown in the attached CO figure. However, the CO2/CH4/OCS values seem unreasonable, possibly related to issue GCHP run provides unreasonable CO2 values #437? Would you please help fix it?

The GCHP output data are daily-average.

HEMCO_Config.rc.txt
ExtData.rc.txt

What are the steps to reproduce the bug?

Set up the GCHP carbon simulation with the default settings.

Please attach any relevant configuration and log files.

No response

What GCHP version were you using?

GCHP 14.4.0

What environment were you running GCHP on?

Other (please explain below)

What compiler and version were you using?

ifort 19.1.3.304 20200925

What MPI library and version were you using?

MPT: libxmpi.so 'HPE MPT 2.28 04/24/23 12:22:36-mraymond'

Will you be addressing this bug yourself?

Yes, but I will need some help

Additional information

No response

[lizziel]

Hi @Aosrain, we are aware there are problems in the new GCHP carbon simulation and plan to apply fixes in version 14.5.1. Thank you for your report and I will apply these fixes first. I will follow up when I get to the rest. Thanks for your patience!

[Aosrain]

@lizziel Thank you for the information!

[lizziel]

I will keep this issue open until all the problems are resolved.

[lizziel]

The default CO2 emissions do not accurately reflect the diurnal cycle of CO2. I adopted Hannah's CO2 emission data in GCClassic (as in the HEMCO_Config.rc), and now the CO2 emissions appear good to me, as shown in the attached CO2 figure.

Do you plan on submitting these emissions for use in the standard model? Forgive me if you already have and I am not aware of it!

Several variables in the default CH4 emissions had mismatched units between HEMCO_Config.rc and Extdata.rc. I updated them to ensure consistent units.

Technically this does not matter for GCHP. The units in HEMCO_Config.rc are ignored since HEMCO does not handle data read when using GCHP. The units in ExtData.rc are used for informational purposes only when creating the imports. Unlike when HEMCO reads data, GCHP does not automatically do unit conversions based on the configured units.

There are issues with converting CH4 emissions from molec/cm2/s to kg/m2/s. The output emissions are still in the magnitude of molec/cm2/s. I disabled those emission sources, such as GHGI_v2_Express_Ext, Scarpelli_Mexico and
JPL_WETCHARTS. Now the CH4 emissions appear reasonable to me, as shown in the attached CH4 figure.

Yes, this is a case where HEMCO is doing automatic unit conversions to kg/m2/s but GCHP is not. The solution is to either apply scale factors in HEMCO or apply scale factors in ExtData.rc (there is a scaling column to indicate scaling, if any, per input). I will include the fix in my PR for GCHP carbon fixes.

After fixing the emission issues, no apparent issues are observed in the CO simulations, as shown in the attached CO figure. However, the CO2/CH4/OCS values seem unreasonable, possibly related to issue #437? Would you please help fix it?

I believe the problem is not correctly vertically flipping some of the non-emissions inputs. We input several files that were output of GEOS-Chem Classic. The problem is that the lev dimension in those files are a dimensionless pressure proxy. The MAPL software in GCHP handles vertical flipping so that all inputs are stored as top-of-atmosphere for level 1. It can figure out what to do when lev is pressure, specifically if units are hPa or Pa, but relies on the lev positive attribute otherwise. For the inputs to the carbon simulation some of the files use positive up and some use positive down, which is an error. What we should be doing is handling these like they are pressures since like pressure they decrease in value when going up in the atmosphere. I am working on a fix now to do this.

[kbowman77]

How long do you expect the update to take? Is It possible to "preflip" the input files until we get a longer term fix?

[lizziel]

GCHP carbon should be fixed in 14.5.1 which will be released in the next couple months I expect.

[lizziel]

In the meantime you can get around this flipping issue by updating MAPL to include this fix: geoschem/MAPL#37. Note that there may be other issues, however, that are still being investigated.

[kbowman77]

In the meantime you can get around this flipping issue by updating MAPL to include this fix: geoschem/MAPL#37. Note that there may be other issues, however, that are still being investigated.

I'm puzzled why this is an issue with the carbon simulations but not with the full-chemistry version.

[lizziel]

This issue only affects reading output files generated by GEOS-Chem Classic. In general we do not do this with GCHP except in the carbon simulation.

[Aosrain]

In the meantime you can get around this flipping issue by updating MAPL to include this fix: geoschem/MAPL#37. Note that there may be other issues, however, that are still being investigated.

carbon_MAPL_update.pdf
@lizziel @kbowman77 I've updated the MAPL code, and the results are attached. The changes improve the carbon simulations, particularly for CH4. However, there are still some strange patterns in the simulations, especially with CO2. Do you have any suggestions for further improvement?

[lizziel]

Hi @Aosrain, @msulprizio is looking into issues with CO2 in carbon simulations that affect both GC-Classic and GCHP. Once that is complete in the next couple weeks I will continue validation of GCHP carbon. If you want to try to fix it now rather than wait I suggest turning on/off various components in geoschem_config.yml and emissions in HEMCO_Config.rc.

[msulprizio]

@Aosrain I've created a draft pull request (geoschem/geos-chem#2510) to track the fixes that I've made already for CO2 in the carbon simulation. I'm still tracking down differences in chemistry and will mark the pull request as ready once those are complete. These fixes will go into 14.5.1.

[msulprizio]

Several fixes for CO2 in the carbon simulation have been pushed to the dev/no-diff-to-benchmark branch (i.e. 14.5.1 development branch) in the geos-chem repository. See pull request geoschem/geos-chem#2510 for details.

Differences in CO2 (in the carbon simulation) still exist between GCClassic and GCHP even after these fixes. I'm attaching several difference plots to help evaluate. These plots compare output from GCClassic and GCHP integration tests (1-hour runs) for the carbon simulation with CO2 only.

• SfcCO2_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf
• ZonalCO2_gcc_vcarbon-CO2_vs_gchp_carbon-CO2.pdf
• EmisTotal_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf <-- Note diagnostic issue here for GCHP (all zeroes)
• EmisFossil_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf
• EmisShip_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf
• EmisOcean_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf
• EmisCO2SurfCorr_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf
• EmisNetTerrExch_gcc_carbon-CO2_vs_gchp_carbon-CO2.pdf

[lizziel]

Like @Aosrain, I see the hot spots even when I turn off everything. I am able to remove them by altering the GCHP source code to skip using DELP_DRY to update mixing ratio using the restart file pressure value in the first timestep. There seems to be a weird striping in DELP_DRY in the GCHP restart file which is introducing the altitude-dependent hot spots. I will further investigate tomorrow.