[QUESTION] Output frequency setting for HEMCO_Diagnostics does work? Is is possible to set output frequency and location for HEMCO_restart?

[FeiYao-Edinburgh]

Hello,

I am using GC 12.2.1, I just found that that my DiagnFreq defined in HEMCO_Config.rc does not work well. I did not change the DiagnFreq value, which is END, for the downloaded HEMCO_Config.rc file. However, the output HEMCO_diagnostics files are on a daily basis. I have also talked with others who use GC 12.5, which seems to output HEMCO_diagnostics files on a monthly basis even if the DiagnFreq value is set to END. I am wondering if this value can be read into GC correctly?

Meanwhile, is it possible to set output location, frequency, and time stamp for HEMCO_restart files as HEMCO_diagnostics files? It is said here that default output frequency for HEMCO_restart files is END. Again however, I have received daily files. For GC 12.5, it seems to be monthly files.

Thanks in advance!

Yours faithfully,
Fei

[yantosca]

Thanks for writing. In the main HEMCO standalone file, HEMCO_sa_Config.rc, try removing all of the diagnostics settings:

DefaultDiagnOn:      false
DefaultDiagnSname:   TOTAL_
DefaultDiagnLname:   HEMCO_total_emissions_
DefaultDiagnDim:     2
DefaultDiagnUnit:    kgm-2s-1
DiagnPrefix:         output/HEMCO_sa.diagnostics
DiagnFreq:           00000100 000000

Then the HEMCO standalone should just take the diagnostic settings from HEMCO_Config.rc.

The HEMCO_sa_Config.rc is the "Driver" configuration file, but then it just includes a HEMCO_Config.rc that can be taken directly from one of the GEOS-Chem run directories.

[FeiYao-Edinburgh]

Thanks for your reply but I am sorry that I do not catch all the points. I do not run a HEMCO standalone simulation so I do not have HEMCO_sa_Config.rc file. For instance, the following shows the screenshot of a standard complexSOA_SVPOA rundir which only holds HEMCO_Config.rc file.

• A screenshot of a geosfp_2x25_complexSOA_SVPOA simulation

I think by using unit tester I can only obtain the HEMCO_sa_Config.rc file in geosfp_4x5_HEMCO rundir (see the following)? Did you mean changing the HEMCO_sa_Config.rc file under .../UT/runs/4x5_HEMCO (see the following). But frankly, I do not think that will have any impact since that file is not shared by other rundirs?

• A screenshot of a geosfp_4x5_HEMCO simulation

• A screenshot of a .../UT/runs/4x5_HEMCO simulation

BTW, is it possible to specify output location, frequency, and time stamp for HEMCO_restart files as we do for HEMCO_diagnostics files, not in my desired way now though?

Thanks in advance!

[yantosca]

I think the easiest thing for you to do is to generate a geosfp_4x5_HEMCO folder from the unit tester, and then just copy the HEMCO_Config.file from your complexSOA folder there. That should set up a HEMCO standalone simulation for complex SOA. There are some other files you need like HEMCO_sa_Config.rc, HEMCO_sa_Grid.rc, HEMCO_sa_Time.rc which specify the input grid and start and end times.

I think HEMCO restart will be generated at the same frequency as the HEMCO diagnostics, if I remember correctly. You might want to check the HEMCO User's Guide on the wiki.

[FeiYao-Edinburgh]

to generate a geosfp_4x5_HEMCO folder from the unit tester, and then just copy the HEMCO_Config.file from your complexSOA folder there

I am so sorry that I may have not expressed my problem. I do not need to run a HEMCO standalone simulation. I just run normal GC simulations. Below is one of my geosfp_2x25_complexSOA_SVPOA HEMCO_Config setting, but I have received many monthly HEMCO_diagnostics and HEMCO_restart files within the rundir shown as follows, which should not be for DiagnFreq: End. You can also see that I only have the HEMCO_Config.rc file.

Moreover, I also found DiagnFreq: End in nested running gives daily HEMCO_diagnostics and HEMCO_restart files as follows.

To conclude, I just wonder why DiagnFreq: End does not work for normal simulations?

[FeiYao-Edinburgh]

Have I expressed my concern clearly?

BTW, is it possible to detect the HEMCO version within GEOS-Chem since many functions are available to certain version of HEMCO described in this page.

This can be found in HEMCO.log file anyway.

[msulprizio]

I verified that when we run simulations shorter than one month, we get HEMCO restart files saved out at the end of the simulation. It may be that when you run simulations for longer than one month (or one day for nested simulations) that HEMCO defaults to saving out the diagnostic at monthly (or daily) frequencies. Can you run a simulation with Verbose and Warnings set to 3 at the top of your HEMCO_Config.rc and send us the resulting GEOS-Chem and HEMCO log files? You should be able to attach them to this thread. That will allow us to take a closer look at what is going on.

[FeiYao-Edinburgh]

Can you run a simulation with Verbose and Warnings set to 3 at the top of your HEMCO_Config.rc and send us the resulting GEOS-Chem and HEMCO log files?

OK. I will do it and report in a later time.

I think HEMCO restart will be generated at the same frequency as the HEMCO diagnostics, if I remember correctly. You might want to check the HEMCO User's Guide on the wiki.

I only found how to set location, frequency, and time stamp for HEMCO_diagnostics but not HEMCO_restart files. Can you confirm they are by default the same?
More specifically, from this page I found that the default frequency for HEMCO_restart files is END but I receive daily or monthly files depending nested vs. global simulations, which I will report more details in a later time. Hence, is there a way to change the default setting for HEMCO_restart files as we do for HEMCO_diagnostic files?

[yantosca]

I am not sure. I think the HEMCO_restart will get saved at the same frequency as the other diagnostics. Have you looked at the HEMCO User's Guide? I am wondering if it says anything about it.

[FeiYao-Edinburgh]

@yantosca

I think the HEMCO_restart will get saved at the same frequency as the other diagnostics.

Not necessarily. When I tried to set DiagFreq larger than the simulation length, no HEMCO_diagnostics but still default HEMCO_restart.

I am wondering if it says anything about it.

It is said here that The updated variables become automatically written into the HEMCO restart file (HEMCO_restart.YYYYMMDDhhmmss.nc) at the end of a simulation.

The following might be another issue...

I found that when I remove the line DiagnFile: HEMCO_Diagn.rc from the top of HEMCO_Config.rc, I will still receive dry files which I explained here, where I still have one remaining question that appreciate your help. I will also get 'dry' HEMCO_restart files if I only collect one entry of HEMCO_diagnostic as follows. So I wonder the variables contained in HEMCO_restart files are also determined by HEMCO_Diagn.rc??

 ###############################################################################
 #####   ACET emissions                                                    #####
 ###############################################################################
 EmisACET_Total     ACET   -1     -1  -1   3   kg/m2/s  ACET_emission_flux_from_all_sectors
 ...

[FeiYao-Edinburgh]

@msulprizio

Can you run a simulation with Verbose and Warnings set to 3 at the top of your HEMCO_Config.rc and send us the resulting GEOS-Chem and HEMCO log files?

GC version: 12.5.0
Compiler: GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Simulation: geosfp_2x25_complexSOA_SVPOA

I compile the model using make realclean; make -j4 mpbuild NC_DIAG=y BPCH_DIAG=n BPCH_TPBC=n BPCH_TIMESER=n. You can find these information in the following attached lastbuild.mp file.
lastbuild.mp.txt

I have turned off almost all chemistry, transport, deposition but aerosol (as I use complexSOA_SVPOA) to save model run time in input.geos, which I attach as follows.
input.geos.txt

For HEMCO_Config.rc, I have replaced GEOS FP FLAHS_DENS and CONV_DEPTH with MERRA2 FLASH_DENS and CONV_DEPTH since I run for year 2013. I have also set verbose and warning to 3. You can find this file below.
HEMCO_Config.rc.txt

For HEMCO_Diagn.rc, I commented all collections but the first one to save model run time. Again you can find it below.
HEMCO_Diagn.rc.txt

For HISTORY.rc, I only enabled the restart file collection as follows.
HISTORY.rc.txt

Now I provide you the GC and HEMCO log files as below. It is surprisingly to receive daily HEMCO_diagnostic and HEMCO_restart files even I set DiagnFreq as END. Maybe it is the issue of simulation range? Or maybe it depends on simulation type? I appreciate your investigation.
GC.log
HEMCO.log

Many thanks in advance!

[neyranaz]

Hello, we are running a 4x5 aerosol only, using GC 12.7 to obtain Boundary Conditions for a nested grid simulation. When we do our runs, (Which are at least 4 months long) we are just obtaining restart files at the end of the simulation. So we wanted to know how could we get Daily Restart files as Fei-Yao was obtaining, instead of End restart files as Fei Yao wanted.

Also is there some sort of sintax that we could use to set the restart frequency to Daily instead of End in HISTORY.rc?

[msulprizio]

@neyranaz To save out daily restart files, you can change the frequency and duration of the Restart collection in HISTORY.rc from 'End' to 00000001 000000 (YYYYMMDD hhmmss format). For example:

#==============================================================================
# %%%%% THE Restart COLLECTION %%%%%
#
# GEOS-Chem restart file fields
#
# Available for all simulations
#==============================================================================
  Restart.filename:           './GEOSChem.Restart.%y4%m2%d2_%h2%n2z.nc4',
  Restart.format:             'CFIO',
  Restart.frequency:          00000001 000000,
  Restart.duration:           00000001 000000,
  Restart.mode:               'instantaneous'
  Restart.fields:             'SpeciesRst_?ALL?               ', 'GIGCchem',
                              'Chem_H2O2AfterChem             ', 'GIGCchem',

See this wiki page for more details: https://wiki.seas.harvard.edu/geos-chem/index.php/Overview_of_History_diagnostics.

[neyranaz]

It works! thanks a lot @msulprizio

[yantosca]

Thanks @neyranaz. I'll close out this issue.