You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, This is Inderjeet. I have been trying to implement the new emission file into the GCHP version 13.4.0. I created this emission file by converting 2D GFAS flux data into 3D data using injection height information. (First, I converted injection height into GEOS-Chem levels and then uniformly distributed emission fluxes among those levels.) ( the Netcdf (emission file) has been attached)
However, while running GCHP i encountered following error (log file has been attached. please find 'runGCHPrun.log')
**HEMCO ERROR [0005]: Negative emissions in: GFAS_CO. To allow negatives, edit settings in the configuration file.
There is no negative value in my file. but my _FillValue=-100000. I noticed that jennyfisher had same problem ([BUG/ISSUE] Problems using RCP emissions #369) and it was advised to check if the emission file is COARDS compliant. To the best of my knowledge, My emission file is COARDS compliant. Can you please check it for me??
I also looked onto HEMCO.log file (please find the attached file) after setting verbose and warning in HEMO_Config.rc to 3. I noticed that everything is fine until GCHP starts reading from ExtData (also attached). it reads as follow
Reading from ExtData: GFAS_CO
HEMCO: Leaving HCOIO_READ (hcoio_read_mapl_mod.F90) ( 5)
HEMCO: Leaving HCOIO_DATAREAD (HCOIO_DATAREAD_MOD.F90) ( 4)
HEMCO: Entering tIDx_Assign (HCO_TIDX_MOD.F90) ( 4)
HEMCO: Leaving tIDx_Assign (HCO_TIDX_MOD.F90) ( 4)
HEMCO: Entering EmisList_Pass (HCO_EMISLIST_MOD.F90) ( 4)
HEMCO: Entering EmisList_Add (HCO_EMISLIST.F90) ( 5)
HEMCO: Entering Add2EmisList (HCO_EMISLIST_MOD.F90) ( 6)
HEMCO: Leaving Add2EmisList (HCO_EMISLIST_MOD.F90) ( 6)
Container added to EmisList:
Container GFAS_CO
-->Data type : 1
-->Container ID : 280
-->Target ID : 280
-->File data home? 1
-->Source file : GFAS_CO
-->ncRead? T
-->Shared data file? F
-->Source parameter: cofire
-->Year range : 2020 2020
-->Month range : 7 7
-->Day range : 1 1
-->Hour range : 0 0
-->SpaceDim : 3
-->Array dimension : 24 24 72 -->Array sum : -2.0720833E+09
-->Array min & max : -100000.6 0.0000000E+00
-->Time dimension : 1
-->Delta t[h] : 0
-->Local time? F
-->Tempres : Constant
-->OrigUnit : kg/m2/s
-->Concentration? F
-->Coverage : -999
-->Extension Nr : 0
-->Species name : CO
-->HEMCO species ID: 56
-->Category : 5
-->Hierarchy : 3
I suspect that GCHP is reading _Fillvalue as a valid value from ExtData which crashed my test simulation.
If i set negative values option to 1 in HEMCO_Config.rc, GCHP is running fine but i would not trust that simulation results.
Any advise will be appreciated. Thanks!!
I added GFAS data files in HEMCO_Config.rc with dimension "xyz" with 'C' (cycling) option. I created only one file for testing purposes, so 'Sourcetime' option is set accordingly. Corresponding changes have been made in ExtData.rc files. You will notice in HEMCO_Config.rc and ExtData.rc file that i am calling only one species "GFAS_CO", other species are commented out. This is done only for testing purposes.
Log files
attached zip file contains HEMCO.log, runGCHPrun.log, GFAS-20200701.nc, HEMCO_Config.rc and ExtData.rc .
The text was updated successfully, but these errors were encountered:
Hi Inderjeet, you are correct. MAPL ExtData in GCHP 13.4 does not identify fill values as missing values. If a data point is equal to the fill value in the file then it will be treated as regular data unless the fill value happens to be the fill value defined within MAPL.
I did an ncdump of your file and it contains many missing values, meaning _FillValue will be used for those data points. For example, this is part of the variable dump for cofire:
_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
_, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _, _,
Upon read, MAPL will regrid using the _FillValue, in your case -100000, and the negative values will be detected by HEMCO later on.
The simple way to fix this is to update your netcdf file to use _FillValue of 0, or to replace the missing values in the file with actual zero data values. In GCHP it is currently safest to avoid using fill value and set your data to what you want it to be read as.
This issue is tangentially related to #183, which identified problems using the 2D GFAS injection height data due to missing values. There should be a fix in 14.1 which includes an update to ExtData.
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 Stale bot from closing this issue.
What institution are you from?
Washington University in St. Louis
Description of the problem
Hi, This is Inderjeet. I have been trying to implement the new emission file into the GCHP version 13.4.0. I created this emission file by converting 2D GFAS flux data into 3D data using injection height information. (First, I converted injection height into GEOS-Chem levels and then uniformly distributed emission fluxes among those levels.) ( the Netcdf (emission file) has been attached)
However, while running GCHP i encountered following error (log file has been attached. please find 'runGCHPrun.log')
**HEMCO ERROR [0005]: Negative emissions in: GFAS_CO. To allow negatives, edit settings in the configuration file.
There is no negative value in my file. but my _FillValue=-100000. I noticed that jennyfisher had same problem ([BUG/ISSUE] Problems using RCP emissions #369) and it was advised to check if the emission file is COARDS compliant. To the best of my knowledge, My emission file is COARDS compliant. Can you please check it for me??
I also looked onto HEMCO.log file (please find the attached file) after setting verbose and warning in HEMO_Config.rc to 3. I noticed that everything is fine until GCHP starts reading from ExtData (also attached). it reads as follow
Reading from ExtData: GFAS_CO
HEMCO: Leaving HCOIO_READ (hcoio_read_mapl_mod.F90) ( 5)
HEMCO: Leaving HCOIO_DATAREAD (HCOIO_DATAREAD_MOD.F90) ( 4)
HEMCO: Entering tIDx_Assign (HCO_TIDX_MOD.F90) ( 4)
HEMCO: Leaving tIDx_Assign (HCO_TIDX_MOD.F90) ( 4)
HEMCO: Entering EmisList_Pass (HCO_EMISLIST_MOD.F90) ( 4)
HEMCO: Entering EmisList_Add (HCO_EMISLIST.F90) ( 5)
HEMCO: Entering Add2EmisList (HCO_EMISLIST_MOD.F90) ( 6)
HEMCO: Leaving Add2EmisList (HCO_EMISLIST_MOD.F90) ( 6)
Container added to EmisList:
Container GFAS_CO
-->Data type : 1
-->Container ID : 280
-->Target ID : 280
-->File data home? 1
-->Source file : GFAS_CO
-->ncRead? T
-->Shared data file? F
-->Source parameter: cofire
-->Year range : 2020 2020
-->Month range : 7 7
-->Day range : 1 1
-->Hour range : 0 0
-->SpaceDim : 3
-->Array dimension : 24 24 72
-->Array sum : -2.0720833E+09
-->Array min & max : -100000.6 0.0000000E+00
-->Time dimension : 1
-->Delta t[h] : 0
-->Local time? F
-->Tempres : Constant
-->OrigUnit : kg/m2/s
-->Concentration? F
-->Coverage : -999
-->Extension Nr : 0
-->Species name : CO
-->HEMCO species ID: 56
-->Category : 5
-->Hierarchy : 3
I suspect that GCHP is reading _Fillvalue as a valid value from ExtData which crashed my test simulation.
If i set negative values option to 1 in HEMCO_Config.rc, GCHP is running fine but i would not trust that simulation results.
Any advise will be appreciated. Thanks!!
GCHP_issue.zip
GEOS-Chem version
GCHP 13.4.0
Description of code modifications
I added GFAS data files in HEMCO_Config.rc with dimension "xyz" with 'C' (cycling) option. I created only one file for testing purposes, so 'Sourcetime' option is set accordingly. Corresponding changes have been made in ExtData.rc files. You will notice in HEMCO_Config.rc and ExtData.rc file that i am calling only one species "GFAS_CO", other species are commented out. This is done only for testing purposes.
Log files
attached zip file contains HEMCO.log, runGCHPrun.log, GFAS-20200701.nc, HEMCO_Config.rc and ExtData.rc .
The text was updated successfully, but these errors were encountered: