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

DustDead extension ignores USTAR read from meteorology #278

Open
yuanjianz opened this issue Jun 3, 2024 · 9 comments · Fixed by #279 or geoschem/geos-chem#2512
Open

DustDead extension ignores USTAR read from meteorology #278

yuanjianz opened this issue Jun 3, 2024 · 9 comments · Fixed by #279 or geoschem/geos-chem#2512
Assignees
@yantosca
Labels
category: Bug Something isn't working never stale Never label this issue as stale topic: HEMCO Extensions Pertaining to HEMCO extensions

Comments

@yuanjianz
Copy link

Your name

Yuanjian Zhang

Your affiliation

WashU

What happened? What did you expect to happen?

USTAR is one of the most significant variables used in DustDead dust emission. Currently, DustDead is calculating its own friction velocity WND_FRC from reference wind at 10m with a reference roughness length.

HEMCO/src/Extensions/hcox_dustdead_mod.F

Lines 1482 to 1497 in 3bd40ad

!=================================================================
! Surface exchange properties over erodible surfaces
! DO NEED THIS: Compute Monin-Obukhov and Friction velocities
! appropriate for dust producing regions.
!
! Now calling Stripped down (adiabatic) version tdf 10/27/2K3
! rgh_mmn_mbl parameter included directly in blm_mbl
!=================================================================
CALL BLM_MBL(
& HcoState,
& FLG_MBL_SLICE, ! I [flg] Mobilization candidate flag
& RGH_MMN, ! I [m] Roughness length momentum, Z0,m
& WND_RFR, ! I [m s-1] 10 m wind speed
& MNO_LNG, ! O [m] Monin-Obukhov length
& WND_FRC,
& RC ) ! O [m s-1] Surface friction velocity, U*

HEMCO/src/Extensions/hcox_dustdead_mod.F

Lines 2707 to 2709 in 3bd40ad

! Roughness length momentum for erodible surfaces [m]
! MaB95 p. 16420, GMB98 p. 6205
REAL*8, PARAMETER :: RGH_MMN_MBL = 100.0d-6

USTAR and Z0 read from meteorology is only read but ignored in following calculation.

HEMCO/src/Extensions/hcox_dustdead_mod.F

Lines 1467 to 1480 in 3bd40ad

!=================================================================
! Introduce Ustar and Z0 from GEOS data
!=================================================================
DO I = 1, HcoState%NX
! Just assign for flag mobilisation candidates
IF ( FLG_MBL_SLICE(I) ) THEN
WND_FRC_GEOS(I) = ExtState%USTAR%Arr%Val(I,LAT_IDX)
Z0_GEOS(I) = ExtState%Z0%Arr%Val(I,LAT_IDX)
ELSE
WND_FRC_GEOS(I) = 0.0D0
Z0_GEOS(I) = 0.0D0
ENDIF
ENDDO

Is there any historical reason for not using USTAR directly from GMAO, or is it just a bug?

What are the steps to reproduce the bug?

N/A

Please attach any relevant configuration and log files.

No response

What HEMCO version were you using?

3.9.0

What environment were you running HEMCO on?

Local cluster

What compiler and version were you using?

gcc 10.2.0

Will you be addressing this bug yourself?

Yes

In what configuration were you running HEMCO?

Standalone

As what resolution were you running HEMCO?

all

What meterology fields did you use?

Other (please explain in additional information section below)

Additional information

All meterology fields
@yuanjianz yuanjianz added the category: Bug Something isn't working label Jun 3, 2024
@yuanjianz yuanjianz mentioned this issue Jun 3, 2024
Merged
@yantosca yantosca added the topic: HEMCO Extensions Pertaining to HEMCO extensions label Jun 4, 2024
@yantosca yantosca self-assigned this Jul 16, 2024
@yantosca yantosca modified the milestones: 3.9.2, 3.10.0 Jul 16, 2024
@yantosca yantosca linked a pull request Jul 16, 2024 that will close this issue
Use USTAR read from GEOS instead of calculating from U10M and V10M #279
Merged
@yantosca
Copy link
Contributor

See comments on PR #279

@msulprizio msulprizio removed this from the 3.10.0 milestone Oct 1, 2024
@yuanjianz yuanjianz mentioned this issue Oct 11, 2024
Merged
@github-actions GitHub Actions
Copy link

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.

@github-actions github-actions bot added the stale No recent activity on this issue label Nov 14, 2024
@github-actions GitHub Actions
Copy link

Closing due to inactivity

@yantosca yantosca added never stale Never label this issue as stale and removed stale No recent activity on this issue labels Nov 21, 2024
@yantosca yantosca reopened this Nov 21, 2024
@yantosca
Copy link
Contributor

@yuanjianz This was closed by the stale action but I've reopened it.

@yantosca
Copy link
Contributor

@yuanjianz @lizziel: I've merged the HEMCO PR #279 and GEOS-Chem PR #2512 but I noticed that the GCHP emissions are much higher than the GCHP emissions.

GCClassic
Ref = gcc-4x5-1Hr-14.6.0-alpha.2-2-g8250dac
Dev = gcc-4x5-1Hr-14.6.0-alpha.4-1-g1b20e4a
                                    Ref                 Dev           Dev - Ref              % diff diffs
DST1 Natural       :           0.006879            0.008958            0.002080           30.236475   * 
DST2 Natural       :           0.017277            0.022501            0.005224           30.236484   * 
DST3 Natural       :           0.031349            0.040828            0.009479           30.236480   * 
DST4 Natural       :           0.034294            0.044664            0.010369           30.236483   * 


GCHP 
Ref = gchp-c24-1Hr-14.6.0-alpha.2-2-g13535ce
Dev = gchp-c24-1Hr-14.6.0-alpha.4-3-g7754180
                                    Ref                 Dev           Dev - Ref              % diff diffs
DST1 Natural       :           0.004585            0.090644            0.086059         1876.980035   * 
DST2 Natural       :           0.011516            0.227675            0.216158         1876.979956   * 
DST3 Natural       :           0.020896            0.413104            0.392208         1876.979840   * 
DST4 Natural       :           0.022859            0.451918            0.429059         1876.980067   *

I looked at the PR #2512 and realized that we had only added scale factors for GCClassic.

I know that most GCHP simulations use offline emissions but we use the online emissions for GCHP. Would you be able to make a new PR with the scaling factors for GCHP?

@lizziel
Copy link
Contributor

lizziel commented Jan 27, 2025 •
edited
Loading

GCHP scale factors for dustdead are set in setCommonRunSettings.sh, i.e. https://github.com/geoschem/geos-chem/blob/b0e03cc0f7c06b899824a69744b67e9632675cbd/run/GCHP/setCommonRunSettings.sh.template#L208-L241.

Notice they are the same for all meteorology data sets. They were derived by Christoph Keller.

@yantosca
Copy link
Contributor

@lizziel: I think I see the problem:

HEMCO_Config.rc (from GEOS-Chem Classic integration test rundir)
105     DustDead               : off   DST1/DST2/DST3/DST4
    --> Mass tuning factor     :       5.6659e-5

HEMCO_Config.rc (from GCHP integration test rundir)
105     DustDead               : off   DST1/DST2/DST3/DST4
    --> Mass tuning factor     :       ${RUNDIR_DUSTDEAD_TF}

It looks like the Mass tuning factor for GCHP wasn't being written to the HEMCO_Config.rc file with the right value.

@yantosca
Copy link
Contributor

The Mass tuning factor should have been replaced here but looks like it wasn't. I'll double check this.

https://github.com/geoschem/geos-chem/blob/b0e03cc0f7c06b899824a69744b67e9632675cbd/run/GCHP/setCommonRunSettings.sh.template#L676-L685

@yantosca
Copy link
Contributor

Never mind. I was looking at the fullchem but not fullchem_benchmark run directory. This is the HEMCO_Config.rc:

105     DustDead               : on    DST1/DST2/DST3/DST4
    --> Mass tuning factor     :       6.0e-4

I think Christoph's scale factors were done for DEAD dust emissions using USTAR computed from U10M and V10M. I would need some help in determining the proper scale factors for GCHP now that we use USTAR from the met fields.

@yantosca yantosca modified the milestone: 3.11.0 Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@yantosca yantosca

Labels
category: Bug Something isn't working never stale Never label this issue as stale topic: HEMCO Extensions Pertaining to HEMCO extensions
Projects
None yet
Milestone
No milestone
4 participants
@lizziel @msulprizio @yantosca @yuanjianz