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.

Sign up for GitHub

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

Jump to bottom

[BUG/ISSUE] Negative values error in FLUXNO stops nested grid simulation #380

Closed
tianjialiu opened this issue Jul 20, 2020 · 3 comments
Closed

[BUG/ISSUE] Negative values error in FLUXNO stops nested grid simulation #380

tianjialiu opened this issue Jul 20, 2020 · 3 comments
Assignees
@lizziel @yantosca
Labels
category: Bug Something isn't working topic: HEMCO Submodule Related to HEMCO topic: Nested Grid Simulation Related to GEOS-Chem nested model simulations
Milestone
12.9.2

Comments

@tianjialiu
Copy link

tianjialiu commented Jul 20, 2020 •
edited by yantosca

A "negative values found" error in FLUXNO stopped my nested grid run on day 342 (Dec 8) of 2013. This issue was first reported by Eimy Bonilla.

HEMCO ERROR: Negative values found!
ERROR LOCATION: HCO_EmisAdd (HCO_FLUXARR_MOD.F90)
HEMCO ERROR: HCO_EmisAdd error: FLUXNO
ERROR LOCATION: Evolve_Plume (hcox_paranox_mod.F90)
ERROR LOCATION: HCOX_ParaNOx_Run (hcox_paranox_mod.F90)
ERROR LOCATION: HCOX_RUN (hcox_driver_mod.F90)

HEMCO.log
GC.log
@tianjialiu tianjialiu added the category: Bug Something isn't working label Jul 20, 2020
@tianjialiu tianjialiu changed the title [BUG/ISSUE] Negative values in FLUXNO stops nested grid simulation [BUG/ISSUE] Negative values error in FLUXNO stops nested grid simulation Jul 20, 2020
@lizziel
Copy link
Contributor

lizziel commented Jul 20, 2020

@msulprizio looked into this issue with the following results and recommendations:

I found there are negative NO concentrations coming into PARANOX in your simulation for some reason. I added the following print statements to hcox_paranox_mod.F90:

       !---------------------------
       ! Calculate NO emissions
       !---------------------------
       IF ( Inst%IDTNO > 0 ) THEN
           ! Of the total ship NOx, the fraction SHIP_FNOx
           ! survives after plume dilution and chemistry.
           ! FNO_NOx is the ratio of NO / NOx.
           ! Unit: kg/m2/s
           FLUXNO(I,J) = ShipNoEmis(I,J,1) * SHIP_FNOx * FNO_NOx
           IF ( FLUXNO(I,J) < 0 ) THEN
              Print*, 'Negative FLUXNO', I, J, FLUXNO(I,J), &
                   ShipNoEmis(I,J,1), SHIP_FNOx, FNO_NOx
              Print*, 'NO ', ExtState%NO%Arr%Val(I,J,1)
              Print*, 'NO2', ExtState%NO2%Arr%Val(I,J,1)
           ENDIF
       ENDIF

and got:

---> DATE: 2013/06/30  UTC: 05:20  X-HRS:      3.333333
 Negative FLUXNO          88          25 -2.091128014432859E-023
  4.633619622571765E-015  0.667191946995445      -6.764091053656804E-009
 NO  -4.496931290122641E-020
 NO2  1.019397083332783E-011
 Negative FLUXNO          88          26 -5.062449583636140E-024
  1.148761012021977E-015  0.663186263584066      -6.645007896927583E-009
 NO  -4.364733349923269E-020
 NO2  1.007160756590786E-011

FNO_NOx is computed using NO and NO2, so having a negative FNO_NOx led me to look at those species concentrations. I'm still digging into why there's a negative NO value for those two grid boxes.

I'm finding the differences are coming in during transport, always at the same timestep. I will check the met fields.

I've added a bunch of print statements in the transport code. I printed out minimum values of NO before and after different subroutines to see where the negative values were coming in. Negative values seem to come in several timesteps before the model actually crashes, so I'm not sure if there's a correction later on that addresses them. I also printed out the values of met fields used in tpcore (where the negative values seem to be coming in) and don't see anything especially strange. U and V (for wind) have negative values, but that's to be expected with those fields.

I'm not sure where to go from here because the tpcore code is essentially a black box. I think you have a few options: (1) Contact the nested model leaders to see if they have any advice; (2) add a fix in main.F after transport to set negative species concentration values to 0 or some low value like 1e-20, (3) add a fix in PARANOX to check for negative value. For the third option you could for example change the .OR. to a .AND. in this IF statement:

       ! Split the ship NOx emission into NO and NO2
       ! following the ambient ratio
       ! Now check for zero ambient air concentrations. In this
       ! case, arbitrarily emit everything as NO (ckeller, 04/10/15).
       IF ( ExtState%NO%Arr%Val (I,J,1) > 0.0_hp .OR. &
            ExtState%NO2%Arr%Val(I,J,1) > 0.0_hp       ) THEN
          FNO_NOx = (ExtState%NO%Arr%Val(I,J,1)/Inst%MW_NO) / &
                  ( (ExtState%NO%Arr%Val(I,J,1)/Inst%MW_NO) + &
                    (ExtState%NO2%Arr%Val(I,J,1)/Inst%MW_NO2) )
       ELSE
          FNO_NOx = 1.0_hp
       ENDIF

@lizziel
Copy link
Contributor

lizziel commented Jul 20, 2020 •
edited

Regarding recommdation #3, to change FNO_NOx calculation from using an .OR. to an .AND.. It seems like an .AND. is more appropriate than .OR. and would be the simplest way to prevent this error.

@christophkeller, do you recall why this code block has an .OR. rather than .AND.? You implemented it back in 2015 so it might be too ancient to recall. If there are no objections we can update to use .AND. in 12.9.2.

! Split the ship NOx emission into NO and NO2
       ! following the ambient ratio
       ! Now check for zero ambient air concentrations. In this
       ! case, arbitrarily emit everything as NO (ckeller, 04/10/15).
       IF ( ExtState%NO%Arr%Val (I,J,1) > 0.0_hp .OR. &
            ExtState%NO2%Arr%Val(I,J,1) > 0.0_hp       ) THEN
          FNO_NOx = (ExtState%NO%Arr%Val(I,J,1)/Inst%MW_NO) / &
                  ( (ExtState%NO%Arr%Val(I,J,1)/Inst%MW_NO) + &
                    (ExtState%NO2%Arr%Val(I,J,1)/Inst%MW_NO2) )
       ELSE
          FNO_NOx = 1.0_hp
       ENDIF

@lizziel lizziel self-assigned this Jul 22, 2020
@yantosca yantosca added the topic: HEMCO Submodule Related to HEMCO label Jul 24, 2020
@yantosca yantosca added this to the 12.9.2 milestone Jul 24, 2020
@yantosca yantosca self-assigned this Jul 24, 2020
yantosca added a commit that referenced this issue Jul 24, 2020
@yantosca
Make sure NO and NO2 are positive when computing FNO_NOx
ff0a547 
In routine Evolve_Plume (in HEMCO module src/Extensions/paranox_mod.F90),
we need to make sure that both NO and NO2 are nonzero before computing
FNO_NOx.  This involves changing an .or. to an .and. in the IF block.
Otherwise, set FNO_NOx = 1.0.

This commit resolves the issue brought up in:
#380

We will make a corresponding commit in the HEMCO repository.

Signed-off-by: Bob Yantosca <yantosca@seas.harvard.edu>
@yantosca
Copy link
Contributor

This issue is now resolved by commit ff0a547. We have changed the .OR. to an .AND. in that IF block. This will go into 12.9.2.

yantosca added a commit to yantosca/HEMCO that referenced this issue Jul 24, 2020
@yantosca
Make sure NO and NO2 are positive when computing FNO_NOx
2bf1293 
In routine Evolve_Plume (in HEMCO module src/Extensions/paranox_mod.F90),
we need to make sure that both NO and NO2 are nonzero before computing
FNO_NOx.  This involves changing an .or. to an .and. in the IF block.
Otherwise, set FNO_NOx = 1.0.

This commit resolves the issue brought up in:
geoschem/geos-chem#380

This update corresponds to commit ff0a547 in geoschem/geos-chem.

Signed-off-by: Bob Yantosca <yantosca@seas.harvard.edu>
@msulprizio msulprizio added the topic: Nested Grid Simulation Related to GEOS-Chem nested model simulations label Aug 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lizziel lizziel

@yantosca yantosca

Labels
category: Bug Something isn't working topic: HEMCO Submodule Related to HEMCO topic: Nested Grid Simulation Related to GEOS-Chem nested model simulations
Projects
None yet
Milestone
12.9.2
Development

No branches or pull requests
4 participants
@lizziel @msulprizio @yantosca @tianjialiu