[BUG/ISSUE] Failing to import Yuan_LAI in GCHP 13.2.1

[davidyung-GitHub]

Hi,

The model (GCHP 13.2.1 out of the box without modifications) cannot initialize after setting YUAN_MODIS_LAI as true in HEMCO_Config.rc. Whereas no issues occurred when set as false.

The ncdf files do exist on our cluster and the files are not corrupted.

Please see the logs and scripts attached and I will gladly attached any files missing. allPEs.log ExtData.rc.txt GCHP_run.slurm.txt gchp.env.txt HEMCO_Config.rc.txt runConfig.sh.txt 335675_error.log 335675_print_out.log HEMCO.log

I look forward to any possible insight on this issue and thank you for your time.

P.S. I have tried to investigate by looking into ExtData.rc, and am confused by how the Yuan LAI is read in with the variable XLAIMULTI. I have not found any information on how GCHP imports such variable. May I ask where I can learn about this?

[lizziel]

Hi @davidyung-GitHub, thanks for asking about this. While a logical for Yuan LAI is present within GCHP's HEMCO_Config.rc it should never actually be set as true. This is also the case for meteorology and Olson land map. We realize this is a counter-intuitive and plan on removing entries in GCHP's HEMCO_Config.rc that are not needed. Historically these entries have been kept only so that GCHP and GC-Classic config files closely match.

There are three different approaches for getting imports into GCHP and I'll go over all of them here. Note that all options include putting the import in ExtData.rc and one other place, and that other place is what differs between them. Technically imports can be excluded from ExtData.rc if they are exports from one of GCHP's gridded components, but I won't go into that in much detail here.

1. Add import to ExtData.rc and HEMCO_Config.rc
2. Add import to ExtData.rc and in source code file Chem_Registry.rc *this is what is done for XLAIMULTI
3. Add import to ExtData.rc and explicitly declare and set pointers to MAPL Imports in file Chem_GridCompMod.F90

Option 1: Only certain functionalities of HEMCO are used in GCHP. These include masking and scaling imports as well as applying hierarchies. The file paths, file variable names, dates, read flags, dimensions, and units are not used other than checking that the HEMCO_Config.rc expected format is correct. As such, we only really need to put entries in HEMCO_Config.rc for some imports and not others. If it is included and enabled in the file then HEMCO will handle declaring the import and creating a pointer to it. If it is not also in ExtData.rc, which is where the file paths, variable names, read frequency etc are specified, then GCHP will crash.

Option 2: An import that does not need HEMCO functionalities can be included in config file Chem_Registry.rc. This is a config file that is included in the source code rather than the run directory. At compile time the file is parsed by a perl script in the GCHP I/O component (MAPL) called mapl_acg.pl. The script auto-generates fortran files that declare the imports and creates pointers to them. Those fortran files are then included inline within high-level GCHP file Chem_GridCompMod.F90. For example, see here. You can view what those auto-generated files look like by going to src/GCHP_GridComp/GEOSChem_GridComp/geos-chem/Interfaces/GCHP/Registry within your build directory after you compile GCHP. You will see files that end in ___.h. For example, GEOSchem_ImportSpec___.h contains the auto-generated code to declare imports. The top of the file looks like this:

! ------------------- ! W A R N I N G ! ------------------- ! ! This code fragment is automatically generated by mapl_acg. ! Please DO NOT edit it. Any modification made in here will be overwritten ! next time this file is auto-generated. Instead, enter your additions ! or deletions in the .rc file. !

All of the imports in the auto-generated files must be either in ExtData.rc or declared as an export in one of GCHP's gridded components (e.g. AREA here).

Option 3: For some imports we explicitly have import declarations etc in file Chem_GridCompMod.F90 rather than auto-generate them using the perl script. We do this for the Olson land mask which has lots of variables with similar names. Rather than generate code for each variable we can do it in a loop, as shown here. We also do this if the import has special attributes we want to include in the declaration that wouldn't be included, or specified as something else, in the auto-generated code.

Let me know if this does not make sense or if you have any other questions!

[davidyung-GitHub]

Hi Lizzie,

Thank you for the thorough explanation! I apologise for overlooking the information on this in the wiki (http://wiki.seas.harvard.edu/geos-chem/index.php/Running_GCHP:_Configuration_v12).

Just for some peace of mind, I want to verify that is Yuan MODIS LAI read in and used by default in GCHP? And how is this shown in the log files?

I understand now that HEMCO is mainly concerned with emissions and thank you for this clarification that resolves most of my issues!

[lizziel]

Yes, the Yuan MODIS LAI is used in GCHP. The file used is specified in ExtData.rc as this in your config file:

#==============================================================================
# Yuan-processed MODIS Leaf Area Index
#==============================================================================
#
# Use file with land type stored as 3rd dimension to speed up file read
XLAIMULTI cm2_cm-2 N Y %y4-%m2-%d2T00:00:00 none none XLAIMULTI ./HcoDir/Yuan_XLAI/v2021-06/Condensed_Yuan_proc_MODIS_XLAI.025x025.%y4.nc

You can confirm this by increasing the prints to logging file allPEs.log, do a short run, and then search the file for XLAIMULTI. To increase the prints follow the instructions in the debugging section of runConfig.sh, or follow instructions here.

[davidyung-GitHub]

Many thanks Lizzie, this resolves my issues, greatly appreciate your help and effort in the development of GCHP.