Small differences in JOH and JNO2 restart variables upon 14.3.0 restart

[lizziel]

Name and Institution (Required)

Name: Lizzie Lundgren
Institution: Harvard University

Description of your issue or question

I am doing reproducibility tests of GCHP upon restart, meaning I am checking that all diagnostics and restart files are bit-for-bit reproducible regardless of how a run is broken up in time. Transport tracer simulation passes the test as do full chemistry diagnostic output (benchmark simulation). However, I am seeing small differences in some grid boxes for JNO2 and JOH in the restart file. This needs to be further investigated.

[yantosca]

@lizziel: Wondering if these are from the PARANOx HEMCO extension. If so, that would explain it, as those would be REAL*4.

[yantosca]

@lizziel: Indeed, these come from HEMCO. In GCClassic these fields would be saved to the HEMCO restart file, but in GCHP these are all saved to checkpoint/restarts. The arrays are of type ExtDat_2R, which use the Arr_2D_HP type.

     TYPE(ExtDat_2R),  POINTER :: JNO2        ! J-Value for NO2 [1/s]
     TYPE(ExtDat_2R),  POINTER :: JOH         ! J-Value for O3->OH  [1/s]

Also note; I believe the data are stored internally in hcox_paranox_mod.F90 as REAL*4. So even if the HEMCO precision hp is set to REAL\8, you would still get roundoff errors.

[lizziel]

@yantosca, I don't think HEMCO is what is causing this. The JNO2 and JOH arrays are copied between the MAPL internal state and State_Chm%JNO2/State_Chm%JOH. The State_Chm arrays are used to set the arrays used in HEMCO, but they are not modified by HEMCO, and the values in State_Chm are set from the ZPJ arrays in fullchem_mod.F90 in GEOS-Chem:
GeosCore/fullchem_mod.F90:1613: State_Chm%JNO2(:,:) = State_Chm%Phot%ZPJ(1,State_Chm%Phot%RXN_NO2,:,:)

[lizziel]

A quick test for this is to turn off paranox. This is not an urgent issue because GEOS does not use paranox and thus does not include JNO2 and JOH in the internal state.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days it will be closed. You can add the "never stale" tag to prevent the issue from closing this issue.