GCHP full chemistry simulation #355

ast222340 · 2023-11-11T18:01:20Z

Name and Institution (Required)

Name: Subhadeep Ghosh
Institution:IIT Delhi

Confirm you have reviewed the following documentation

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

Description of your issue or question

Respected sir/madam,
Even if the configuration is done properly,the simulation is not running,some error is coming.I don't really understand what they are trying to say.The cmake, make logs and the runsettings files are attached.

CmakeLog.txt
log.make.txt
MakeLog.txt

Here I attached my setCommonRunSettings and PBS job script.It would be great if you could tell me about my mistake.

CAP.txt
ExtData.txt
GCHP.log
gchp_int.txt
HEMCO_Config.txt
HISTORY.txt
setCommonRunSettings.txt

lizziel · 2023-11-16T15:38:49Z

Hi @ast222340, this looks like a compiler problem. The error is occurring in one of the 3rd party libraries from NASA GMAO. Try using a newer version of intel. I think 2018 may be too old.

ast222340 · 2023-11-20T15:12:41Z

Thank you @lizziel. Now using 2019 version...Then again some errors come...please help me..don't understand.

lizziel · 2023-11-27T21:19:13Z

Hi @ast222340, the error "FATAL: mpp_domains_define.inc: not all the pe_end are in the pelist" is referring to a mismatch in number of processors configured versus how many you are running with. Check how many processors/nodes you configure in setCommonRunSettings.sh and compare that against the number of processors and cores you actually have available for your run, e.g. what you put in your run script. If it looks okay and you are still having problems please drag and drop your log file into the GitHub issue comment box. You should first rename the log file to have .txt extension so GitHub recognizes it as a text file (this used to be required, not sure if it still is).

ast222340 · 2023-11-29T11:04:50Z

Thank you @lizziel.You are helping me a lot.I tried but can't do anything the same error is coming.I have attached the GCHP.log file and setCommonRunSettings file.
I would greatly appreciate it if you could point out my mistake.
GCHP.txt
setCommonRunSettings.txt

lizziel · 2023-11-29T15:12:58Z

Your log file indicates you set GCHP to run with six cores:

 Integer*4 Resource Parameter: NX:1
 Integer*4 Resource Parameter: NY:6

However, it also indicates you only have one core available:

 Starting PEs :            1
 Starting Threads :            1

This indicates that when you run the GCHP program you are only assigning one core. What command are you using to run GCHP?

ast222340 · 2023-11-29T22:43:07Z

Thank you @lizziel .Our HPC team says all libraries are set up.Go to the run directory and write"gchp".

lizziel · 2023-11-30T18:45:07Z

If you execute GCHP by simply typing gchp then you will only run the program with one core. Perhaps the sysadmins are not aware this is an MPI program. We have example run scripts, including a script to run interactively (locally) rather than submitting to a job scheduler. Go to the directory sampleRunScripts in the run directory. See also our ReadTheDocs page on running GCHP.

ast222340 · 2024-01-03T12:30:30Z

Thank you @lizziel. Happy New Year.
Even after running with 'mpirun -np 12 ./gchp' comments,but error is coming.I attached all the log files.

gchp_mpirun12.logs.txt
logfile.000000.out.txt
setCommonRunSettings.log
allPEs.log

lizziel · 2024-01-05T14:31:09Z

Hi @ast222340, Happy New Year to you as well! The log shows there is a new error than the one before, which is a good thing. There is also a traceback of the error that shows where in the code there is a problem. What model version are you using? The next step is to look at file MAPL_CapGridComp.F90 within the MAPL package in src/MAPL to find out what happens in line 324. This will indicate why the model is failing.

pe=00006 FAIL at line=00324    MAPL_CapGridComp.F90                     <something impossible happened>
pe=00006 FAIL at line=00959    MAPL_CapGridComp.F90                     <status=1>
pe=00006 FAIL at line=00311    MAPL_Cap.F90                             <status=1>
pe=00006 FAIL at line=00258    MAPL_Cap.F90                             <status=1>
pe=00006 FAIL at line=00192    MAPL_Cap.F90                             <status=1>
pe=00006 FAIL at line=00169    MAPL_Cap.F90                             <status=1>
pe=00006 FAIL at line=00029    GCHPctm.F90                              <status=1>

ast222340 · 2024-01-08T14:41:28Z

Thank you @lizziel, Model version is GCHP 14.2.3.... Running with 'mpirun -np 1 ./gchp' comments and 'mpirun -np 2 ./gchp'.
I went to the MAPL package and checked the 324 line.I just don't know what to do. I don't understand the meaning of there being a npes word in that line _ASSERT(CoresPerNode <= npes, 'something impossible happened') ,since then the code is crashing.
This model is used in the main part of my thesis.If you write me a little and give me the solution then I will be very much benefited.

MAPL_CapGridComp.F90.txt

lizziel · 2024-01-08T16:55:35Z

Hi @ast222340, you cannot run GCHP with fewer than 6 cores. If you do mpirun -np 1 ./gchp then you are running with less than 6 cores and you will hit an error. Try mpirun -np 6 ./gchp, making sure to change the compute resources in setCommonRunSetting.sh to use 1 node, 6 cores, and 6 cores per node.

Also see the GCHP 14.2.3 User Guide on running GCHP. The guide specifies 6 cores as minimum and recommends using script gchp.local.run to run if not submitting to a scheduler. The script includes several pre- and post- run commands that are needed for successfully using GCHP. You can do them manually at the command line as you are now but it increases the likelihood of error.

ast222340 · 2024-01-10T18:29:15Z

Thank you @lizziel. I did as you suggested and now facing this error.I don't understand what the error means.It looks like the model is starting to run.Am i right?I attached GCHP.log file.

GCHP.log

lizziel · 2024-01-10T20:48:44Z

Hi @ast222340, I wonder if you are running out of memory. Also, it looks like the model is running multiple times at once given your log file. Are you running using the gchp.local.run script? How much memory do you have available? You can also try running with more cores than 6. If you are running on a compute cluster we suggest running your job as a batch job, submitted to a scheduler with specification of number of nodes, cores, and memory. Your system administrators should be able to help you learn how to do that.

ast222340 · 2024-01-11T21:50:04Z

Thank you @lizziel. I tried to run on HPC with 400gb space(Interactive node).Even taking more than 6 core shows the same error.(please check gchp.log file) qsub -I -lselect=1:ncpus=24:mpiprocs=24:mem=400gb -lwalltime=01:00:00 -P geoschem.spons
qsub -I -lselect=4:ncpus=24:mpiprocs=24:mem=400gb -lwalltime=01:00:00 -P geoschem.spons(It's not even possible)
So we tried to take job in batch script.Having to face the same problem.(please check gchp.20190701_0000z.log file).I attached job script(geoschem_spons),setCommonRunSettings and log files along with it.Where is the problem?

gchp.20190701_0000z.log
gchp.log
geoschem_spons.log
setCommonRunSettings.log
allPEs.log

lizziel · 2024-01-12T18:56:21Z

I followed the error traceback to the line of code where it is failing. The traceback is this:

pe=00014 FAIL at line=00287    MaplGrid.F90                             <status=508>
pe=00014 FAIL at line=00120    MaplGrid.F90                             <status=508>
pe=00014 FAIL at line=10225    MAPL_Generic.F90                         <status=508>
pe=00014 FAIL at line=00306    GCHP_GridCompMod.F90                     <status=508>
pe=00014 FAIL at line=01807    MAPL_Generic.F90                         <status=508>
pe=00014 FAIL at line=00655    MAPL_CapGridComp.F90                     <status=508>
pe=00014 FAIL at line=00959    MAPL_CapGridComp.F90                     <status=508>
pe=00014 FAIL at line=00311    MAPL_Cap.F90                             <status=508>
pe=00014 FAIL at line=00258    MAPL_Cap.F90                             <status=508>

The first line is the code that I found, which is here.

        call ESMF_DistGridGet(distGrid,MaxIndexPDe=oldMaxIndex,MinIndexPDe=oldMinIndex, &
                              deToTileMap=deToTileMap,rc=status)
        _VERIFY(STATUS)

This is a call to the ESMF library. What version are you using? Do you have file ESMF.rc in your run directory. If yes, open it and set the logKindFlag parameter to ESMF_LOGKIND_MULTI_ON_ERROR and run again. You should then get an ESMF error log file with more information. There will be one log file per core. The traceback indicates which core the error is on (PE #), e.g. the above traceback shows it is core 14.

ast222340 · 2024-01-13T19:23:51Z

Thank you @lizziel .Model version is GCHP 14.2.3.ESMF version is 8.4.2.ESMF.rc file is present in run directory.
module list

lib/XScrnSaver/1.2.2
suite/intel/parallelStudio/2019
lib/intel/2019/esmf/esmfv8.4.2
apps/cmake/3.23.1/gnu
lib/bzip2/1.0.6/gnu

20240114 003137.511 ERROR PET0 ESMCI_DistGrid_F.C:481 c_esmc_distgridget() Argument sizes do not match - 2nd dim of minIndexPDimPDe array must be of size 'deCount'

PET0.ESMF_LogFile.txt

lizziel · 2024-01-16T22:28:22Z

@tclune, have you ever seen this ESMF error before?
20240114 003137.511 ERROR PET0 ESMCI_DistGrid_F.C:481 c_esmc_distgridget() Argument sizes do not match - 2nd dim of minIndexPDimPDe array must be of size 'deCount'

It is occurring during this call in MaplGrid.F90 (MAPL 2.26.0 - sorry, we are still on a very old version!)

        call ESMF_DistGridGet(distGrid,MaxIndexPDe=oldMaxIndex,MinIndexPDe=oldMinIndex, &
                              deToTileMap=deToTileMap,rc=status)
        _VERIFY(STATUS)

tclune · 2024-01-17T13:23:33Z

@lizziel No - does not ring a bell. And we use DistGrid very rarely in MAPL, so have relatively little experience. I'm sure the error message is correct - some incorrect assumption about rank/sizes going on.

Including @atrayanov and @nasa-ben in case they have further insights.

Do you have any other context you can provide? And/or what was different about this run? Stack trace?

lizziel · 2024-01-17T17:58:17Z

As far as I know only @ast222340 has run into this problem. The configuration files look normal and the resource configuration is simple (1 node, 24 cores). The error itself is strange given the array with the size mismatch is allocated directly before the call.

@ast222340, you could try going into this code and printing out deCount to see what is printed for each core.

@tclune, here is the stack trace. Is this getting dimensions for the grid per core, and so would possibly have different deCount per core?

MaplGrid.F90 line 287

deCount = size(minIndex,2)
allocate(deToTileMap(deCount),stat=status)
_VERIFY(STATUS)
allocate(oldMinIndex(2,deCount),oldMaxIndex(2,deCount),stat=status)
_VERIFY(STATUS)
call ESMF_DistGridGet(distGrid,MaxIndexPDe=oldMaxIndex,MinIndexPDe=oldMinIndex, &
                              deToTileMap=deToTileMap,rc=status)
_VERIFY(STATUS)

MaplGrid.F90 line 120:

! Processors in each direction
!-----------------------------
call MAPL_DistGridGet(distgrid, &
         minIndex=minindex, &
         maxIndex=maxindex, rc=status)
_VERIFY(STATUS)

MAPL_Generic.F90 line 10225:
call state%grid%set(grid, __RC__)

GCHP_GridCompMod.F90 line 306:

! Create Atmospheric grid
!------------------------
call MAPL_GridCreate( GC, rc=status )
_VERIFY(STATUS)

MAPL_Generic.F90 line 1807:

      call func_ptr (GC, &
           importState=IMPORT, &
           exportState=EXPORT, &
           clock=CLOCK, PHASE=PHASE_, &
           userRC=userRC, _RC )
      _VERIFY(userRC)

MAPL_CapGridComp.F90 line 655:

call ESMF_GridCompInitialize(cap%gcs(cap%root_id), importState = cap%child_imports(cap%root_id), &
            exportState = cap%child_exports(cap%root_id), clock = cap%clock, userRC = status)
_VERIFY(status)

MAPL_CapGridComp.F90 line 959:

call ESMF_GridCompInitialize(this%gc, userRC=status)
_VERIFY(status)

MAPL_Cap.F90 line 311:

call this%cap_gc%initialize(rc=status)
_VERIFY(status)

MAPL_Cap.F90 line 258:
call this%run_model(comm=split_comm%get_subcommunicator(), rc=status); _VERIFY(status)

MAPL_Cap.F90 line 192:
call this%run_member(rc=status); _VERIFY(status)

MAPL_Cap.F90 line 169:
call this%run_ensemble(rc=status); _VERIFY(status)

tclune · 2024-01-17T18:13:33Z

Thank you for the additional info. Hmm.

In general, MAPL expects exactly 1 DE per PET. (one local domain per process). There are some exceptions in History and ExtData to deal with coarse grids that end up with missing DE's on some PET's. But that should not be the case here.

Hoping @nasa-ben or @atrayano have advice.

ast222340 · 2024-01-17T20:08:44Z

Thank you @lizziel @tclune.A problem has arisen.After seeing your discussion,I went to check the error from beginning.

NOT using buffer I/O for file: cap_restart
NOT using buffer I/O for file: cap_restart
CoresPerNode 24
npes 1
CoresPerNode 24
CoresPerNode 24
npes 1
pe=00005 FAIL at line=00326 MAPL_CapGridComp.F90
pe=00005 FAIL at line=00961 MAPL_CapGridComp.F90 <status=1>
pe=00005 FAIL at line=00299 MAPL_Cap.F90 <status=1>
pe=00011 FAIL at line=00326 MAPL_CapGridComp.F90
pe=00011 FAIL at line=00961 MAPL_CapGridComp.F90 <status=1>
pe=00011 FAIL at line=00299 MAPL_Cap.F90 <status=1>
CoresPerNode 24
pe=00005 FAIL at line=00258 MAPL_Cap.F90 <status=1>
pe=00005 FAIL at line=00192 MAPL_Cap.F90 <status=1>
pe=00011 FAIL at line=00258 MAPL_Cap.F90 <status=1>
pe=00005 FAIL at line=00169 MAPL_Cap.F90 <status=1>
pe=00005 FAIL at line=00031 GCHPctm.F90 <status=1>
pe=00011 FAIL at line=00192 MAPL_Cap.F90 <status=1>
pe=00011 FAIL at line=00169 MAPL_Cap.F90 <status=1>
pe=00011 FAIL at line=00031 GCHPctm.F90 <status=1>

Then I looked at file MAPL_CapGridComp.F90 within the MAPL package in src/MAPL.This will indicate the model is failing.
!call ESMF_VMGet(cap%vm, petcount=npes, mpicommunicator=comm, rc=status)
! _VERIFY(status)
! _ASSERT(CoresPerNode <= npes, 'something impossible happened')
An attempt was made to run model with the above section switched off in "MAPL_CapGridComp.F90".Turned it off from system admin.I apologize to you for this.

Then came this error.Please check conversation 5 days back.I just copied your conversation.
I followed the error traceback to the line of code where it is failing. The traceback is this:

pe=00014 FAIL at line=00287 MaplGrid.F90 <status=508>
pe=00014 FAIL at line=00120 MaplGrid.F90 <status=508>
pe=00014 FAIL at line=10225 MAPL_Generic.F90 <status=508>
pe=00014 FAIL at line=00306 GCHP_GridCompMod.F90 <status=508>
pe=00014 FAIL at line=01807 MAPL_Generic.F90 <status=508>
pe=00014 FAIL at line=00655 MAPL_CapGridComp.F90 <status=508>
pe=00014 FAIL at line=00959 MAPL_CapGridComp.F90 <status=508>
pe=00014 FAIL at line=00311 MAPL_Cap.F90 <status=508>
pe=00014 FAIL at line=00258 MAPL_Cap.F90 <status=508>

The first line is the code that I found, which is here.

    call ESMF_DistGridGet(distGrid,MaxIndexPDe=oldMaxIndex,MinIndexPDe=oldMinIndex, &
                          deToTileMap=deToTileMap,rc=status)
    _VERIFY(STATUS)

This is a call to the ESMF library. What version are you using? Do you have file ESMF.rc in your run directory. If yes, open it and set the logKindFlag parameter to ESMF_LOGKIND_MULTI_ON_ERROR and run again. You should then get an ESMF error log file with more information. There will be one log file per core. The traceback indicates which core the error is on (PE #), e.g. the above traceback shows it is core 14.
I have attached all the compilation log files.
cmake.log.txt
compile.log.txt
install.log.txt
lddGCHP.txt
GCHP.log.txt

lizziel · 2024-01-17T20:19:55Z

Hi @ast222340, I am not quite following what you mean. Is your problem the ESMF_DistGridGet call, or is there a different
problem instead?

ast222340 · 2024-01-17T20:42:07Z

Thank you for quick reply @lizziel .yes..My problem is ESMF_DistGridGet call part..that error..Crash code.Full details are in GCHP.log file(Previously uploaded)

ast222340 · 2024-01-22T20:22:58Z

@lizziel.If you're not busy,I haven't solved this problem yet,so take a look.I don't understand,I have to do it right.

lizziel · 2024-01-23T02:29:36Z

@ast222340, I'm afraid it is difficult to figure out the issue here without being able to reproduce. As I suggested earlier you can add print statements to the location in the traceback where the error is happening and try to figure out what the issue is there. @tclune said that there should be 1 DE per PET, meaning variable deCount should be one when printed from each core.

ast222340 · 2024-01-23T10:17:54Z

Thank you @lizziel.I don't have any idea about this error.Mainly error is showing this file "MAPL_CapGridComp.F90" at 324 line.
using mpirun -np 144 ./gchp 2>&1 | tee GCHP.log comments(6 node, 24 cores).
call ESMF_VMGet(cap%vm, petcount=npes, mpicommunicator=comm, rc=status)
_VERIFY(status)
_ASSERT(CoresPerNode <= npes, 'something impossible happened')

GCHP.log.txt

lizziel · 2024-01-23T14:59:25Z

Previously you said your error was in ESMF_DistGridGet but now you say your error is elsewhere. Please clarify whether you encounter an error at ESMF_DistGridGet.

ast222340 · 2024-01-23T16:10:58Z

@lizziel. I have deleted everything.I have configured the model again for the GCHP 14.2.3.Now I am facing the above mentioned problem.

lizziel · 2024-01-23T16:56:25Z

If you follow the traceback you will see this error in the code:

    call ESMF_VMGet(cap%vm, petcount=npes, mpicommunicator=comm, rc=status)
    _VERIFY(status)
     _ASSERT(CoresPerNode <= npes, 'something impossible happened')

This indicates cores per node greater than the number of cores available. You ran into this same issue earlier in this thread and I believe you had resolved it.

ast222340 · 2024-01-23T17:39:10Z

Thank you @lizziel.Error have not been solved before.If you tell me how to solve it,so this is my now situation.

lizziel · 2024-01-23T18:28:38Z

Aha, I figured out what the issue is. I searched for "something impossible happened" on the GCHP GitHub issues page and found this very old issue with the same error: #8. Apologies that I forgot about this possibility.

You (or your system administrators) built ESMF with setting ESMF_COMM=mpiuni. This limits ESMF to a single core (or rather, makes ESMF on each core think it is root). You should rebuild it with the proper ESMF_COMM setting. If using Intel this would be intelmpi. See also the GCHP ReadTheDocs page on installing ESMF here which specifies ESMF environment variables required when building ESMF for use with GCHP.

Tagging @tclune that this is resolved.

tclune · 2024-01-23T18:41:31Z

Whew. Was afraid I'd have to dig into this one ...

tclune · 2024-01-24T18:56:25Z

@lizziel we hope to add either build time logic in CMake or a clearer runtime message in MAPL to minimize confusion the next time this happens. (Basically ensuring via Murphy that it will never happen again.)

lizziel · 2024-01-24T22:04:46Z

@tclune Thank you!

@ast222340 Please confirm this works.

ast222340 · 2024-01-25T21:27:30Z

Thank you @lizziel @tclune.I apologize for late reply.Because our system admin was compiling ESMF with openmpi.I have put it in the run for two days,the run is getting an error at the end.Two output files are also created in the "OutputDir".

GCHP.log.txt

tclune · 2024-01-25T21:32:43Z

First guess is that the checkpoint file already exists. GEOS separately moves files out of the way, so default MAPL settings crash if the file already exists. GCHP is different if I recall, so we added an option to overwrite an existing file. But I do not immediately remember how that option is activated. If @lizziel cannot provide those details, I'll look again in the morning. (Am in a meeting, but have enough spare cycles to type this message.)

atrayano · 2024-01-26T00:55:23Z

@tclune is correct, some time ago (in 2021-01-08 for MAPL 2.5.0) we changed the default to be "clobber" for netCDF formatter in PFIO

lizziel · 2024-01-26T15:53:19Z

GCHP will crash if gcchem_internal_checkpoint is found in the Restarts subdirectory. This is not an issue for GCHP because the file is always renamed within the run script after GCHP is executed. The file is renamed to GEOSChem.Restart.YYYYMMDD_mmddz.cN.nc4, where the timestamp is the end time fo the run and N is the grid resolution. This is by design so that GCHP can be run sequentially without overwriting restarts and so that the appropriate restart file can be automatically found based on start time and grid resolution. It also avoids the issue of a failed run if gcchem_internal_checkpoint is already present.

@ast222340, make sure you are using a GCHP run script from the runScriptSamples subdirectory. See the GCHP ReadTheDocs page on running GCHP.

@atrayano, we are using MAPL 2.26.0 but the default is still PFIO_NOCLOBBER (see code here).

      if (present(mode)) then
         pfio_mode=mode
      else
         pfio_mode=PFIO_NOCLOBBER
      end if

      select case (pfio_mode)
      case (pFIO_CLOBBER)
         mode_ = NF90_CLOBBER
      case (pFIO_NOCLOBBER)
         mode_ = NF90_NOCLOBBER
      end select
         
      !$omp critical
      status = nf90_create(file, IOR(mode_, NF90_NETCDF4), this%ncid)
      !$omp end critical
      _VERIFY(status)

tclune · 2024-01-26T15:55:42Z

My memory is that we only added a switch and preserved the original GEOS behavior as the default. The override would be at a much higher level in MAPL.

ast222340 · 2024-01-26T20:38:38Z

Thank you @lizziel @tclune @atrayano. when I run it for one day ,the cap_restart was updated.Then i run for two days,the last part of error comes and no update cap_restart file,not created updated restart file because I didn't remove the 'gcchem_internal_checkpoint' file that was created for a day.please clear this part.
I have some doubt:
1.In GCHP.rc file
METEOROLOGY_VERTICAL_INDEX_IS_TOP_DOWN: .false.
IMPORT_MASS_FLUX_FROM_EXTDATA: .false.
USE_TOTAL_AIR_PRESSURE_IN_ADVECTION: 0
CORRECT_MASS_FLUX_FOR_HUMIDITY: 1
allPEs.log is doing some for these options.These options will have no effect on model simulation.please tell me.

2.In HEMCO_Config.rc
DiagnFreq: Monthly
When I want to create daily file should I write daily here?
Only unitless scale factors: false
Verbose: false
VerboseOnCores: root
what is the actual meaning of these options?
METEOROLOGY : false
When I ran the GEOS Chem classic its option was set to true here is the false does it have any different significance?

3.In HISTORY.rc
GRID_LABELS: #PE24x144-CF
#PC360x181-DC
#REGIONAL1x1
Even though the PE24x144-CF in commented,but the model like this.So should I leave this option as a comment?
AerosolMass.monthly: 1
AerosolMass.frequency: 010000
AerosolMass.duration: 010000
if we create monthly output file then above option set to 1,7440000(jan),7440000
if we create daily output file then above option set to 1,240000,240000...............Did I say it right?

In setCommonRunSettings.sh

MODEL PHASE

#------------------------------------------------

FORWARD for forward model, ADJOINT for adjoint model

Model_Phase=FORWARD
Here we choose ADJOINT,So will it work like the "GEOS Chem Adjoint" model?It is very important to know this information,one of our group is working on this "GEOS Chem Adjoint" modeling.

The study domain of my research is from 2016.Here the restart file of 2019 is provided.what can I do for when I go to run from January 2016?

Thank you...

lizziel · 2024-01-26T21:00:28Z

Hi @ast222340, it sounds like you have GCHP successfully running now. As I said before, make sure you use a GCHP run script when submitting to ensure you do not have gcchem_internal_checkpoint for sequential runs, and to make sure you get all of the other functionality in the run script.

Regarding your questions:

These settings are related primarily to use of mass fluxes in GCHP advection, which is only possible if you use GEOS-FP native meteorology fields. The settings indicate your meteorology input is not top-down (meaning level 1 is surface), you are not using mass fluxes (winds will be used instead within advection), and you are not using total air in advection (dry air is used instead). The setting for moisture pertains only to mass fluxes which you are not using. All of the settings you have in your run are standard for GCHP.
You do not need to change the heading of HEMCO_Config.rc. Please read the section of GCHP ReadTheDocs on this configuration file: https://gchp.readthedocs.io/en/stable/user-guide/config-files/HEMCO_Config_rc.html.
Please read GCHP ReadTheDocs section on configuration files, as well as the comments within file runSettingsConfig.sh and HISTORY.rc. See also the section of GCHP ReadTheDocs on configuring your run.
GEOS-Chem Adjoint in GCHP is not supported. The option is present for research purposes only and currently does not run.

Regarding restart files, we recommend spinning up a GEOS-Chem restart file by starting a run prior to when your research period begins. You can rename the restart file to use for any date. However, due to seasonality we recommend only changing the year.

lizziel · 2024-01-26T21:04:46Z

Any additional issues should go into a new GitHub issue.

ast222340 · 2024-01-27T12:42:35Z

Thank you @lizziel. I am not reopen new issue because doubt comes from above discussion.
2.There is no information about my doubt part(using above link).Some Items at the top of the file(HEMCO_Config.rc) that are ignored include(written on the documentation page).
Only unitless scale factors: false
Verbose: false
VerboseOnCores: root
what is the actual meaning of these options?
METEOROLOGY : false
When I ran the GEOS Chem classic its option was set to true here is the false does it have any different significance?

That means you say that I have a restart file "GEOSChem.Restart.fullchem.20190701_0000z.c48.nc4"..when i start my simulation from 2016,change above file name "GEOSChem.Restart.fullchem.20160101_0000z.c48.nc4" for january..So is this right way?because original file created for 20190701 time..is there any effect on simulation?
Not properly understand "However, due to seasonality we recommend only changing the year"..

lizziel self-assigned this Nov 16, 2023

lizziel closed this as completed Jan 26, 2024

GCHP full chemistry simulation #355

GCHP full chemistry simulation #355

Comments

ast222340 commented Nov 11, 2023

Name and Institution (Required)

Confirm you have reviewed the following documentation

Description of your issue or question

lizziel commented Nov 16, 2023

ast222340 commented Nov 20, 2023

lizziel commented Nov 27, 2023

ast222340 commented Nov 29, 2023

lizziel commented Nov 29, 2023

ast222340 commented Nov 29, 2023

lizziel commented Nov 30, 2023 • edited Loading

ast222340 commented Jan 3, 2024

lizziel commented Jan 5, 2024

ast222340 commented Jan 8, 2024

lizziel commented Jan 8, 2024

ast222340 commented Jan 10, 2024

lizziel commented Jan 10, 2024 • edited Loading

ast222340 commented Jan 11, 2024

lizziel commented Jan 12, 2024 • edited Loading

ast222340 commented Jan 13, 2024

lizziel commented Jan 16, 2024

tclune commented Jan 17, 2024

lizziel commented Jan 17, 2024

tclune commented Jan 17, 2024

ast222340 commented Jan 17, 2024

lizziel commented Jan 17, 2024

ast222340 commented Jan 17, 2024

ast222340 commented Jan 22, 2024

lizziel commented Jan 23, 2024

ast222340 commented Jan 23, 2024

lizziel commented Jan 23, 2024

ast222340 commented Jan 23, 2024

lizziel commented Jan 23, 2024

ast222340 commented Jan 23, 2024

lizziel commented Jan 23, 2024 • edited Loading

tclune commented Jan 23, 2024

tclune commented Jan 24, 2024

lizziel commented Jan 24, 2024

ast222340 commented Jan 25, 2024

tclune commented Jan 25, 2024

atrayano commented Jan 26, 2024

lizziel commented Jan 26, 2024

tclune commented Jan 26, 2024

ast222340 commented Jan 26, 2024

MODEL PHASE

FORWARD for forward model, ADJOINT for adjoint model

lizziel commented Jan 26, 2024 • edited Loading

lizziel commented Jan 26, 2024

ast222340 commented Jan 27, 2024

lizziel commented Nov 30, 2023 •

edited

Loading

lizziel commented Jan 10, 2024 •

edited

Loading

lizziel commented Jan 12, 2024 •

edited

Loading

lizziel commented Jan 23, 2024 •

edited

Loading

lizziel commented Jan 26, 2024 •

edited

Loading