Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG/ISSUE] GCHP recognizing _Fillvalue (negative values) as valid values and crashed. #251

Closed
inder-math opened this issue Sep 8, 2022 · 4 comments
Assignees
Labels
category: Bug Something isn't working stale No recent activity on this issue
Milestone

Comments

@inder-math
Copy link

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 .

@inder-math inder-math added the category: Bug Something isn't working label Sep 8, 2022
@lizziel
Copy link
Contributor

lizziel commented Sep 8, 2022

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.

@lizziel lizziel self-assigned this Sep 13, 2022
@stale
Copy link

stale bot commented Oct 15, 2022

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.

@stale stale bot added the stale No recent activity on this issue label Oct 15, 2022
@stale
Copy link

stale bot commented Oct 23, 2022

Closing due to inactivity

@stale stale bot closed this as completed Oct 23, 2022
@lizziel lizziel added this to the 14.1.0 milestone Oct 24, 2022
@lizziel
Copy link
Contributor

lizziel commented Oct 24, 2022

This issue is fixed in #258 which will be included in 14.1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: Bug Something isn't working stale No recent activity on this issue
Projects
None yet
Development

No branches or pull requests

2 participants