geoschem / geos-chem

GEOS-Chem "Science Codebase" repository. Contains GEOS-Chem science routines, run directory generation scripts, and interface code. This repository is used as a submodule within the GCClassic and GCHP wrappers, as well as in other modeling contexts (external ESMs).
http://geos-chem.org
Other
164 stars 156 forks source link

[DISCUSSION] Luo et al 2019 wetdep scheme has too much scavenging in the stratosphere #211

Closed yantosca closed 4 years ago

yantosca commented 4 years ago

Describe the issue

The new Luo et al 2019 wet scavenging option in GEOS-Chem seems to have way too much scavenging in the stratosphere. I am not sure if this is a coding issue or a scientific algorithm issue.

To Reproduce

  1. Set up two geosfp_4x5_TransportTracers run directories (Ref & Dev).

  2. I used the GEOS-Chem dev/12.7.1 branch (but the problem is still apparent in 12.7.0).

  3. In the Ref run directory: a. Delete the passive species menu from the input.geos file (we only need the radionuclides). b. Compile GEOS-Chem from scratch with make -j4 build c. Run a 1-month simulation (Jan 2016)

  4. In the Dev run directory: a. Delete the passive species menu from the input.geos file (we only need the radionuclides). b. Compile GEOS-Chem from scratch with make -j4 build LUO_WETDEP=y c. Run a 1-month simulation (Jan 2016)

  5. Compare results (especially the WetLossLS diagnostic collection).

Expected behavior

I believe that we should not see as much scavenging in the stratosphere with the Luo et al 2019 wetdep scheme.

Plots

Pb210

pb210

Be7

be7

Discussion

@ganluoasrc Do you know if this behavior is expected, or if this is indicative of a bug? I believe I was able to ingest all of the code changes from your original pull request properly, but there may still be a bug.

Also, could this be due to the fact that we are computing the condensed water content instead of using a constant value (such as in the default wetdep)?

ganluoasrc commented 4 years ago

The overestimation of wet scavenging in the stratosphere is caused by:

  1. Rainout efficiency for cold cloud (T<237 K) Water-soluble aerosols were assumed 100 % removed via homogeneous freezing nucleation in cold cloud (Wang et al., 2014; Liu et al., 2001). Liu et al. (2001) reported that cold cloud rainout efficiency could vary from 0 to 100% due to large uncertainties of ice formation and uptake process. 100 % assumption let their simulation match well with observations. Strom et al. (1997) observed that ~ 40 % of preexisting aerosol mass is incorporated in ice crystal. So in our recent work, we used 40 % rainout efficiency for cold cloud.

  2. ICCW for cold cloud Luo et al. (2019) replaced the fixed ICCW with cloud water and rain water. However, water-soluble aerosols in cold cloud (T < 237 K) can also exist in ice due to freezing of supercooled water, therefore, we calculate ICCW for cold cloud as ICCW=(LCW+ICW+P*dt)/fc in our recent work.

More details can be found in our recent published paper: Luo, G., Yu, F., and Moch, J. M.: Further improvement of wet process treatments in GEOS-Chem v12.6.0: Impact on global distributions of aerosol precursors and aerosols, Geosci. Model Dev. Discuss., https://doi.org/10.5194/gmd-2020-11, in review, 2020.

Best

Gan

References Liu, H. Y., Jacob, D. J., Bey, I., and Yantosca, R. M.: Constraints from Pb-210 and Be-7 on wet deposition and transport in a global three-dimensional chemical tracer model driven by as-similated meteorological fields, J. Geophys. Res.-Atmos., 106,12109–12128, 2001.

Luo, G., Yu, F., and Schwab, J.: Revised treatment of wet scavenging processes dramatically improves GEOS-Chem 12.0.0 simulations of surface nitric acid, nitrate, and ammonium over the United States, Geosci. Model Dev., 12, 3439–3447, https://doi.org/10.5194/gmd-12-3439-2019, 2019.

Strom, J., B. Strauss, T. Anderson, F. Schroder, J. Heintzenberg, and P. Wendhng: In situ observations of the microphysical properties of young cirrus clouds, J. Atmos. Sci., 541, 2542-2553, 1997.

Wang, Q., Jacob, D. J., Spackman, J. R., Perring, A. E., Schwarz, J.P., Moteki, N., Marais, E. A., Ge, C., Wang, J., and Barrett, S. R.H.: Global budget and radiative forcing of black carbon aerosol: constraints from pole-to-pole (HIPPO) observations across the Pacific, J. Geophys. Res., 119, 195–206, 2014.


From: Bob Yantosca notifications@github.com Sent: Monday, February 3, 2020 5:45 PM To: geoschem/geos-chem geos-chem@noreply.github.com Cc: Luo, Gan gluo@albany.edu; Mention mention@noreply.github.com Subject: [geoschem/geos-chem] [BUG/ISSUE] Luo et al 2019 wetdep scheme has too much scavenging in the stratosphere (#211)

Describe the bug

The new Luo et al 2019 wet scavenging option in GEOS-Chem seems to have way too much scavenging in the stratosphere. I am not sure if this is a coding issue or a scientific algorithm issue.

To Reproduce

  1. Set up two geosfp_4x5_TransportTracers run directories (Ref & Dev).

  2. I used the GEOS-Chem dev/12.7.1 branch (but the problem is still apparent in 12.7.0).

  3. In the Ref run directory: a. Delete the passive species menu from the input.geos file (we only need the radionuclides). b. Compile GEOS-Chem from scratch with make -j4 build c. Run a 1-month simulation (Jan 2016)

  4. In the Dev run directory: a. Delete the passive species menu from the input.geos file (we only need the radionuclides). b. Compile GEOS-Chem from scratch with make -j4 build LUO_WETDEP=y c. Run a 1-month simulation (Jan 2016)

  5. Compare results (especially the WetLossLS diagnostic collection).

Expected behavior

I believe that we should not see as much scavenging in the stratosphere with the Luo et al 2019 wetdep scheme.

Plots Pb210

[pb210]https://user-images.githubusercontent.com/5880296/73697476-a1bc1a80-46ac-11ea-8dc2-ceaeae4fdbee.png

Be7

[be7]https://user-images.githubusercontent.com/5880296/73697494-b0a2cd00-46ac-11ea-8101-3234fbacdb60.png

Discussion

@ganluoasrchttps://github.com/ganluoasrc Do you know if this behavior is expected, or if this is indicative of a bug? I believe I was able to ingest all of the code changes from your original pull request properly, but there may still be a bug.

Also, could this be due to the fact that we are computing the condensed water content instead of using a constant value (such as in the default wetdep)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/geoschem/geos-chem/issues/211?email_source=notifications&email_token=AKDKUCYMXQYJ6BWUJSNT6H3RBCNAVA5CNFSM4KPNKTU2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IKXO3XA, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDKUC6IHZQDBDPWTQ4CR7DRBCNAVANCNFSM4KPNKTUQ.

ganluoasrc commented 4 years ago

The large difference between Luo Dev and default Ref in the stratosphere is caused by computing the condensed water content instead of using a constant value. Luo Dev overestimated wet scavenging in the stratosphere. After applying the updates in the GMDD 2020 paper, the simulation could be more reasonable.

Best

Gan


From: Bob Yantosca notifications@github.com Sent: Monday, February 3, 2020 5:45 PM To: geoschem/geos-chem geos-chem@noreply.github.com Cc: Luo, Gan gluo@albany.edu; Mention mention@noreply.github.com Subject: [geoschem/geos-chem] [BUG/ISSUE] Luo et al 2019 wetdep scheme has too much scavenging in the stratosphere (#211)

Describe the bug

The new Luo et al 2019 wet scavenging option in GEOS-Chem seems to have way too much scavenging in the stratosphere. I am not sure if this is a coding issue or a scientific algorithm issue.

To Reproduce

  1. Set up two geosfp_4x5_TransportTracers run directories (Ref & Dev).

  2. I used the GEOS-Chem dev/12.7.1 branch (but the problem is still apparent in 12.7.0).

  3. In the Ref run directory: a. Delete the passive species menu from the input.geos file (we only need the radionuclides). b. Compile GEOS-Chem from scratch with make -j4 build c. Run a 1-month simulation (Jan 2016)

  4. In the Dev run directory: a. Delete the passive species menu from the input.geos file (we only need the radionuclides). b. Compile GEOS-Chem from scratch with make -j4 build LUO_WETDEP=y c. Run a 1-month simulation (Jan 2016)

  5. Compare results (especially the WetLossLS diagnostic collection).

Expected behavior

I believe that we should not see as much scavenging in the stratosphere with the Luo et al 2019 wetdep scheme.

Plots Pb210

[pb210]https://user-images.githubusercontent.com/5880296/73697476-a1bc1a80-46ac-11ea-8dc2-ceaeae4fdbee.png

Be7

[be7]https://user-images.githubusercontent.com/5880296/73697494-b0a2cd00-46ac-11ea-8101-3234fbacdb60.png

Discussion

@ganluoasrchttps://github.com/ganluoasrc Do you know if this behavior is expected, or if this is indicative of a bug? I believe I was able to ingest all of the code changes from your original pull request properly, but there may still be a bug.

Also, could this be due to the fact that we are computing the condensed water content instead of using a constant value (such as in the default wetdep)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/geoschem/geos-chem/issues/211?email_source=notifications&email_token=AKDKUCYMXQYJ6BWUJSNT6H3RBCNAVA5CNFSM4KPNKTU2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IKXO3XA, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDKUC6IHZQDBDPWTQ4CR7DRBCNAVANCNFSM4KPNKTUQ.

yantosca commented 4 years ago

OK thanks much for your reply. I wanted to make sure that this wasn't a coding issue. I will leave this tagged as a "research" problem and note that the update in GMDD 2020 paper will likely resolve the issue.

ganluoasrc commented 4 years ago

Thanks, it sounds good to me.

Best

Gan


From: Bob Yantosca notifications@github.com Sent: Tuesday, February 4, 2020 9:39:03 AM To: geoschem/geos-chem geos-chem@noreply.github.com Cc: Luo, Gan gluo@albany.edu; Mention mention@noreply.github.com Subject: Re: [geoschem/geos-chem] [BUG/ISSUE] Luo et al 2019 wetdep scheme has too much scavenging in the stratosphere (#211)

OK thanks much for your reply. I wanted to make sure that this wasn't a coding issue. I will leave this tagged as a "research" problem and note that the update in GMDD 2020 paper will likely resolve the issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/geoschem/geos-chem/issues/211?email_source=notifications&email_token=AKDKUC6KVCJYWTOPNVQSDSDRBF4YPA5CNFSM4KPNKTU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKX3HKY#issuecomment-581940139, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDKUC3JJFLKIWEZO7IRURDRBF4YPANCNFSM4KPNKTUQ.

yantosca commented 4 years ago

Daniel Jacob wrote:

Bob and Gan, I have been following the discussion on github but the resolution does not seem right. There should be no scavenging in the stratosphere at all because there is no precipitation there (even if we allow for PSCs…the scavenging in the benchmark is above PSC altitude). It does not matter if scavenging is efficient in cold clouds or not. This cannot be a research question, it must be a bug. A related problem is the increase of concentrations in the Arctic troposphere using the Luo et al. scheme, as pointed out by Hongyu. This also does not make sense since the Luo et al. scheme should increase scavenging everywhere, unless it scavenges stuff from the stratosphere and then re-evaporates it in the troposphere. But in any case we need to get to the bottom of why the Luo et al. scheme scavenges aerosol from the stratosphere. Thanks! Daniel

yantosca commented 4 years ago

@ganluo wrote:

I think the large wet scavenging of Luo Dev case in the stratosphere may not be caused by bug in the code. Monthly means of zonal production rate of large-scale precipitation, water mixing ratio, and ice mixing ratio for January and July have been attached. As shown in these figures, production rate of large-scale precipitation and ice mixing ratio can be high at top troposphere and low stratosphere (300-100 hPa), while water mixing ratio can be very low. Based on eq 6 in Luo et al. (2019), wet scavenging could be very large there. As mentioned in previous discussion with Bob at Github, aerosols and Pb210 can also exist in ice due to freezing of supercooled water. So ICCW of cold cloud should include ice. MERRA2

yantosca commented 4 years ago

Daniel Jacob wrote:

Thanks Gan! I think you’re right, the problem may not be a bug in the code but precipitation formation in the polar winter stratosphere – here I’m looking at your plots above 100 hPa, which should be above PSC altitudes. It doesn’t seem right that precipitation should occur there but maybe I’m missing something. Let me ask Susan Strahan and the stratospheric WG and cc you and Hongyu. Daniel

yantosca commented 4 years ago

One quick fix would be to put a trap to not do convection above a certain pressure level. That is what we might end up implementing.

ganluoasrc commented 4 years ago

Bob,

I am afraid wet scavenging in the stratosphere is still there. Maybe we can block wet scavenging in the stratosphere temporarily. We still need the explanation why is there precipitation occurring in the low stratosphere as shown by MERRA2. I also suggest a quick fix of ICCW for cold cloud (T<237 K) which use ICCW=LWC+IWC+Pdt to instead ICCW=LWC+Pdt as that done in Luo et al. GMDD 2020.

Best

Gan


From: Bob Yantosca notifications@github.com Sent: Thursday, February 6, 2020 11:03 AM To: geoschem/geos-chem geos-chem@noreply.github.com Cc: Luo, Gan gluo@albany.edu; Mention mention@noreply.github.com Subject: Re: [geoschem/geos-chem] [DISCUSSION] Luo et al 2019 wetdep scheme has too much scavenging in the stratosphere (#211)

One quick fix would be to put a trap to not do convection above a certain level. That is what we might end up implementing.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/geoschem/geos-chem/issues/211?email_source=notifications&email_token=AKDKUC4XB3JQ33HAFU5NKCTRBQYD7A5CNFSM4KPNKTU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK7YDTA#issuecomment-582975948, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDKUC2DNZ5EN32YIWNSNM3RBQYD7ANCNFSM4KPNKTUQ.

yantosca commented 4 years ago

I am attaching comments from an email conversation for reference.

Susan Strahan (susan.e.strahan@nasa.gov) wrote:

It doesn’t make sense to us here at GSFC that there should be any precipitation or scavenging going on in the stratosphere. It seems the problem(s) can be in 1) the MERRA2 fields that the wetdep scheme uses, 2) the wetdep domain or parameterization, of 3) both. I’ve spoken with Mike Manyin and Luke Oman here to get some insight.

My understanding that as a process ‘precipitation’ (e.g., for rain and snow) is not the same thing as ‘sedimentation’ (for ice particles like PSCs) – so I don’t think what you’ve seeing in the plots is sedimentation. We are aware that MERRA2 has a dry stratosphere problem and they patch it by borrowing from lower levels in the column when water gets too low. So we can imagine a situation where MERRA2 is getting too dry in the stratosphere because it’s so cold (i.e., the polar stratospheric night) and is then bringing some water up to those high levels. Why would it bring enough to form a precipitating cloud? I don’t know if this is what’s happening but it’s an idea.

Another thought I have concerns the ways in which the new Luo wetdep is different. Were previous wetdep schemes limited to certain model levels so that they would never scavenge in the stratosphere? My GMI CTM go-to people are both on leave today so I can’t find out how this compares to our scheme. Mike Manyin has offered to do a short test run using the GMI chemistry in GEOS (or Replay to MERRA2) so we can compare with your results.

And one final thing. Mike was trying to look at one of the MERRA2 fields in the .png you sent (production rate of large-scale precipitation) but he could not figure out the name of the MERRA2 variable this comes from. Can you specify?

Hongyu Liu (hongyu.liu-1@nasa.gov) wrote:

Thanks Susan. The "production rate of large-scale precipitation" in Gan's plot is DQRLSAN (large scale rainwater source). Neither previous nor new schemes were limited to certain model vertical levels. Let's include Andrea in this discussion.

Andrea Molod (andrea.m.molod@nasa.gov) wrote:

what about the “....in dry air...” part – ie., DQRLSAN multiplied by... something?

@ganluoasrc wrote:

The unit for DQRLSAN is kg kg-1 s-1. I think it is the same as that in original MERRA2.

Daniel Jacob (djacob@fas.harvard.edu) wrote:

Thanks Susan and all, this is very helpful! We can certainly solve the problem, as Susan suggests, by restricting precipitation to the troposphere, particularly since (1) precipitation does not include PSC sedimentation, (2) stratospheric water in MERRA-2 is known to have unphysical behavior. GCST, let’s just do that and include this simple fix in version 12.7.1.

yantosca commented 4 years ago

After much discussion, it was decided to change the formula for condensed water content in wetscav_mod.F from:

            COND_WATER_CONTENT = MAX(1.e-30_fp,(QQ(L,I,J)*DT+
     &      State_Met%QL(I,J,L)*State_Met%AIRDEN(I,J,L)*1e-3_fp))

to

            ! Now use QL and QI in formula for COND_WATER_CONTENT (bmy, 2/7/20)
            COND_WATER_CONTENT = 
     &           ( QQ(L,I,J)                 * DT                    )
     &        +  ( ( State_Met%QL(I,J,L)     + State_Met%QI(I,J,L) )
     &           * ( State_Met%AIRDEN(I,J,L) * 1e-3_fp             ) )

            COND_WATER_CONTENT = MAX( 1e-30_fp, COND_WATER_CONTENT   )

We will perform TransportTracers benchmark simulations with both Luo wetdep on and off to compare w/r/t 12.7.0.

ganluoasrc commented 4 years ago

Thanks Bob. It looks good to me. One thing notable is COND_WATER_CONTENT is used twice in wet_dep_mod.F: one is used at top layer, while another one is used in the middle levels.

Best

Gan


From: Bob Yantosca notifications@github.com Sent: Monday, February 10, 2020 11:02 AM To: geoschem/geos-chem geos-chem@noreply.github.com Cc: Luo, Gan gluo@albany.edu; Mention mention@noreply.github.com Subject: Re: [geoschem/geos-chem] [DISCUSSION] Luo et al 2019 wetdep scheme has too much scavenging in the stratosphere (#211)

After much discussion, it was decided to change the formula for condensed water content in wetscav_mod.F from:

        COND_WATER_CONTENT = MAX(1.e-30_fp,(QQ(L,I,J)*DT+
 &      State_Met%QL(I,J,L)*State_Met%AIRDEN(I,J,L)*1e-3_fp))

to

        ! Now use QL and QI in formula for COND_WATER_CONTENT (bmy, 2/7/20)
        COND_WATER_CONTENT =
 &           ( QQ(L,I,J)                 * DT                    )
 &        +  ( ( State_Met%QL(I,J,L)     + State_Met%QI(I,J,L) )
 &           * ( State_Met%AIRDEN(I,J,L) * 1e-3_fp             ) )

        COND_WATER_CONTENT = MAX( 1e-30_fp, COND_WATER_CONTENT   )

We will perform TransportTracers benchmark simulations with both Luo wetdep on and off to compare w/r/t 12.7.0.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/geoschem/geos-chem/issues/211?email_source=notifications&email_token=AKDKUC5NDJCBRY2UW5BK27DRCF3BDA5CNFSM4KPNKTU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELJB7GA#issuecomment-584195992, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKDKUC4RVXDAJMFUM5NBFFLRCF3BDANCNFSM4KPNKTUQ.

yantosca commented 4 years ago

@ganluoasrc: Yes, I have updated the formula in both locations. We'll run the benchmarks and let you all know when they are done.

yantosca commented 4 years ago

@msulprizio re-ran the TransportTracers benchmark for 12.7.1 (with QI + QL added to the in-cloud condensed water content as shown in the above comments). I have just now plotted up the results, which are posted on our FTP site (follow this link for plots).

I have also created the budget tables (we now compute these in Python rather than in IDL). The tables are:

Run0: Standard Wetdep

Run1: Luo et al 2019 wetdep

I think there are still issues in the Luo et al 2019 wetdep scavenging. We might have to put a trap to restrict scavenging in the troposphere. Thoughts?

yantosca commented 4 years ago

We have done a 1-year run (without the long spinup ) with Luo wetdep. Plots and budgets can be found at this link.

yantosca commented 4 years ago

I also was able to do some budget analysis on the 12.7.1 (Run0-StdWetDep) and 12.7.2 (Run1-LuoWetDep) benchmarks. The results are printed below:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Budget diagnostics from Run0-StdWetDep (12.7.1)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

        [g]                           Strat             Trop       Strat+Trop
2016    WetDep_Pb210      :      -2.73511505  -87984.85079956  -87987.58731079
2016    Convection_Pb210  :      -0.06300259  -36792.50239563  -36792.56661987
2016    Mixing_Pb210      :      -4.04464388  -17310.24856567  -17314.29329681
2016    Transport_Pb210   :    -202.63494802     202.63499165       0.00002458
2016    Chemistry_Pb210   :     256.60935974  141848.98077393  142105.57617188
2016    EmisDryDep_Pb210  :      -0.00000000      -0.00000000      -0.00000000
TOTAL   Pb210             :      47.13165021     -35.98599529      11.12896897
---------------------------
GLOBAL Pb210:    22.27462389

        [g]                           Strat             Trop       Strat+Trop
2016    WetDep_Be7        :      -0.31756532    -478.27117610    -478.58867598
2016    Convection_Be7    :      -0.00623509    -111.72187775    -111.72811693
2016    Mixing_Be7        :      -2.73531957     -36.42370020     -39.15901977
2016    Transport_Be7     :    -114.01262605     114.01262605       0.00000307
2016    Chemistry_Be7     :    -922.58264923    -215.97389138   -1138.55647516
2016    EmisDryDep_Be7    :    1121.65590048     646.35583735    1768.01173782
TOTAL   Be7               :      82.00150522     -82.02218203      -0.02054694
---------------------------
GLOBAL Be7  :    -0.04122375

        [g]                           Strat             Trop       Strat+Trop
2016    WetDep_Be10       :      -2.04383183   -1913.16585732   -1915.20968914
2016    Convection_Be10   :      -0.03638792    -441.52605200    -441.56243992
2016    Mixing_Be10       :     -22.70609368    -145.86251682    -168.56861186
2016    Transport_Be10    :    -855.20574617     855.20565891       0.00000351
2016    Chemistry_Be10    :      -0.00126836      -0.00008881      -0.00135716
2016    EmisDryDep_Be10   :    1602.36554718     923.36546946    2525.73110390
TOTAL   Be10              :     722.37221923    -721.98338657       0.38900933
---------------------------
GLOBAL Be10 :     0.77784198

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 Budget diagnostics from Run1-LuoWetDep (12.7.2)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

        [g]                           Strat             Trop       Strat+Trop
2016    WetDep_Pb210      :       0.00000000 -112138.62249756 -112138.62249756
2016    Convection_Pb210  :      -0.00200701  -19986.39738464  -19986.40017700
2016    Mixing_Pb210      :      -0.87671328  -10025.45043182  -10026.32793045
2016    Transport_Pb210   :    -211.51624024     211.51621842      -0.00002809
2016    Chemistry_Pb210   :     269.64967346  141892.11712646  142161.75842285
2016    EmisDryDep_Pb210  :      -0.00000000      -0.00000000      -0.00000000
TOTAL   Pb210             :     114.50942588     -93.67393827      20.81557951
---------------------------
GLOBAL Pb210:    41.65106711

        [g]                           Strat             Trop       Strat+Trop
2016    WetDep_Be7        :       0.00000000    -757.58000994    -757.58000994
2016    Convection_Be7    :      -0.00150764     -66.41233957     -66.41384482
2016    Mixing_Be7        :      -2.11684320     -16.90222992     -19.01907483
2016    Transport_Be7     :    -171.95863312     171.95863312       0.00000132
2016    Chemistry_Be7     :    -838.19199371     -77.88135177    -916.07331276
2016    EmisDryDep_Be7    :    1121.65590048     646.35583735    1768.01173782
TOTAL   Be7               :     218.77384559    -200.92292145      17.85099358
---------------------------
GLOBAL Be7  :    35.70191773

        [g]                           Strat             Trop       Strat+Trop
2016    WetDep_Be10       :       0.00000000   -2029.51627636   -2029.51627636
2016    Convection_Be10   :      -0.00679410    -168.68715620    -168.69394076
2016    Mixing_Be10       :     -10.95641401     -44.72464000     -55.68105537
2016    Transport_Be10    :    -800.73992300     800.74001026       0.00000176
2016    Chemistry_Be10    :      -0.00087819      -0.00002052      -0.00089870
2016    EmisDryDep_Be10   :    1602.36554718     923.36546946    2525.73110390
TOTAL   Be10              :    1581.32307576   -1037.64522671     543.67786892
---------------------------
GLOBAL Be10 :  1087.35571798

As you can see, in the 12.7.1 run, Be7 and Be10 more or less balance, but there is a small excess of Pb210. In the 12.7.2 run, all of the tracers have large imbalances.

This might point to an initialization issue. I have another run queued to test this (but as of the time of posting it is still waiting in our queue due to heavy usage on our cluster). I'll post those results later.

yantosca commented 4 years ago

We have discovered that the results printed above were caused by an initialization issue. Rerunning with the same restart file as Run1-LuoWetDep reveals that the excessive scavenging in the stratosphere is eliminated. This new run is named Run2-LuoWetDep (which also has wetdep turned off in the stratosphere).

See the following plots and tables:

For more plots/tables, see the subfolders of: http://ftp.as.harvard.edu/gcgrid/geos-chem/1yr_benchmarks/GC_12/12.7.2/TransportTracers/Run2-LuoWetDep/Plots