search

geoschem / GCHP

The "superproject" wrapper repository for GCHP, the high-performance instance of the GEOS-Chem chemical-transport model.
https://gchp.readthedocs.io
Other
23 stars 27 forks source link

Questions regarding the GCHP restart file #441

Closed mmmjjj527 closed 2 months ago

mmmjjj527 commented 2 months ago

Your name

Mao Jia

Your affiliation

CUHK

Please provide a clear and concise description of your question or discussion topic.

Hi, I am currently using GCHP version 13.2.1. I have a question regarding the default restart file in GCHP. The restart file is named GCHP.Restart.fullchem.20190701_0000z.c90.nc4. I'm not sure if I can use this restart file to initiate my simulation from January 2015 for both spin-up and subsequent simulations, or if I am restricted to starting only from July 2019. If it's the latter, I’m not sure if there is a way for me to download the corresponding restart file prior to July 2019?

lizziel commented 2 months ago

Hi @mmmjjj527, you can reuse the July 1st restart for other days of the year, or other years, by creating a symbolic link to it with the same restart filename format but with the actual day the run will start on. That being said, we recommend spinning up the model using the sample restart in order to create a restart for the day you want to start. A typical spin-up is 1-year, or longer for long-lived species.

mmmjjj527 commented 2 months ago

Hi @lizziel, thanks for the reply! Also, I have a question about emission inventories. I now want to use the MEIC inventory for China's region instead of the original CEDS inventory. I'm wondering if there are any specific requirements for the units of inventory species (I am currently using kg/m2/s). Does HEMCO automatically standardize the units when processing input data?

lizziel commented 2 months ago

Hi @mmmjjj527, great question! This recently came up because of a bug in GCHP carbon simulation where input units were molecules/cm2/s but HEMCO needs them in kg/m2/s.

HEMCO does apply automatic unit conversion to kg/m2/s when reading input files BUT... HEMCO is not used for file read in GCHP, only in GC-Classic. GCHP uses the MAPL library to read files and that software does not do automatic unit conversion. However, you can specify a scale factor in ExtData.rc for the dataset to manually configure conversion. MAPL will apply that factor upon read.

So, in summary:

  1. Input emissions that are stored as kg/m2/s in the file do not need unit conversion upon read, but data with other units do.
  2. You can manually configure a unit conversion scale factor in the scaling column in ExtData.rc.
mmmjjj527 commented 2 months ago

Thank you @lizziel! These are all my questions for now. I really appreciate it. :)

mmmjjj527 commented 2 months ago

Sorry @lizziel, since we’re on this topic, I actually have one more question. In GCHP, HEMCO in MAPL uses the MAPL data input layer, which simply retrieves data from ExtData. However, since HEMCO can effectively handle regridding and unit conversion, could I ask about the purpose and function of using the ExtData component in GCHP? It could be a little bit confusing.

lizziel commented 2 months ago

Hi @mmmjjj527. ExtData is the MAPL data input layer. GCHP is made up of a hierarchy of three layers of ESMF gridded components. The top one is CAP. The next level (child components of CAP) are ExtData (inputs, including regridding), History (outputs), and GCHP. GCHP has three child components of its own (the third layer): FV3 (advection), ctmEnv (prepares raw inputs for advection), and GEOS-Chem (which includes HEMCO). All of these gridded components have imports and exports that can go between them. HEMCO can retrieve imports from ExtData, as can GEOS-Chem. HEMCO applies masks and scalings to the ExtData imports, but it is agnostic of units and expects that the import is already on the run grid.

Does this make sense? I am happy to further explain this!

lizziel commented 2 months ago

Also note that we have long-term goals of splitting up the HEMCO_Config.rc file into two different files: one used by HEMCO for reading data (so used by GC-Classic but not GCHP), and the other for masking/scaling (for use by both GC-Classic and GCHP). It's been on the todo list for quite some time but we hope to actually get to it with the roll-out of MAPL3 next year when ExtData.rc is replaced by a yaml file.

mmmjjj527 commented 2 months ago

Hi @lizziel, thank you for your response, your explanation was very clear! I now understand that this design was made based on architectural considerations. In GCHP, ExtData is responsible for reading emission data and performing regridding. I now have a clearer understanding of the structure and data flow in GCHP. :)

lizziel commented 2 months ago

Great! If you want to dive even deeper into MAPL there is a wiki maintained by NASA GMAO at https://github.com/GEOS-ESM/MAPL/wiki.