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

fix typo in aerosol budget printout #676

Merged
merged 3 commits into from
Mar 15, 2023

Conversation

mahf708
Copy link
Contributor

@mahf708 mahf708 commented Feb 28, 2023

Fixing a typo in the aerosol budget table. Sinks should have units of Tg/yr (as the rest). Marking as draft as I don't know if you accept PRs. Feel free to cherry pick or fix as you see fit.

@mahf708 mahf708 marked this pull request as draft February 28, 2023 21:35
@chengzhuzhang
Copy link
Contributor

Nice catch! Thank you @mahf708. I will review once the PR is ready.

@chengzhuzhang chengzhuzhang self-requested a review February 28, 2023 21:59
@mahf708
Copy link
Contributor Author

mahf708 commented Mar 1, 2023

It was Susannah who caught it. These are very useful diagnostics for us, especially when running new simulations :) They are pretty good!

Btw, the model outputs these burdens: "BURDENBC", "BURDENDUST", "BURDENMOM", "BURDENSOA", "BURDENSO4", "BURDENPOM", "BURDENSEASALT" in kg/m2. So as an extra sanity check, I calculated the total burdens again in Tg

BURDEN* e3sm_diags "model"
BC (Tg) 0.199 0.197
DUST (Tg) 31.1 30.6
MOM (Tg) 0.077 0.0714
SOA (Tg) 2.928 2.877
SO4 (Tg) 1.822 1.778
POM (Tg) 1.004 0.9889
SEASALT (Tg) 5.375 4.996

with something like 4*np.pi*(6.37122e6)**2*1e-9*BURDEN<VAL>.weighted(WTS).mean(('lat','lon')).values[0]
where WTS=np.cos(np.deg2rad(ds.lat))/np.cos(np.deg2rad(ds.lat)).sum(). I assume the discrepancy might be tracked down to the column numerical integration (either yours or the model's is slightly more accurate)

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 1, 2023

Also, let's perhaps keep this open a little longer for now because I am (and we are) looking closely at these numbers and we may find additional quirks

@chengzhuzhang
Copy link
Contributor

chengzhuzhang commented Mar 1, 2023

Thanks for the sanity check @mahf708 It is concerning that derived global mean from 3D mass concentration data would deviate from the BURDENxx output so much. And more mysteriously, the relative difference changes with species. Other than difference in the column integration and global integral. Could it be that there is missing terms in these burden output? Also, I don't seem to find "BURDENBC", "BURDENDUST", "BURDENMOM", "BURDENSOA", "BURDENSO4", "BURDENPOM", "BURDENSEASALT" in standard output. Maybe some aerosol flags in the name-list prohibited the output

Here is how column integration and global integral is computed: https://github.com/E3SM-Project/e3sm_diags/blob/b9658b6c2bec080b0977d59a4f39d9a2be0a4670/auxiliary_tools/aerosol_budget.py

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 1, 2023

Oh, one might need these aerosol specific namelists to be activated (could be history_aerosol = .true.). Also, I wouldn't worry too much; I would assume these deviations are well within the numerical integration error or some other minor error... I will try to trace where the budget is (especially the numerical integration bit) calculated in the source code.

Yeah, I saw your integration. Also, I think this Mass_* output is new (I couldn't find them in v2 runs I've been looking at, but they could easily be computed as Mass_x = x_a1*x_c1 + ...). That's another potential area where a discrepancy may exist between Mass_* and BURDEN_*.

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 1, 2023

Here is how column integration and global integral is computed: https://github.com/E3SM-Project/e3sm_diags/blob/b9658b6c2bec080b0977d59a4f39d9a2be0a4670/auxiliary_tools/aerosol_budget.py

Besides the numerics, there is a hydrostatic assumption in here: mass_3d = mass*delta_p/9.8 #mass density * mass air kg/m2. Did you add back the height difference somewhere? The full equation is something like, $\rho \Delta H = - \Delta p / g$; mass_3d should be in units of kg/m3 and burden below it should be in kg/m2 (the column integration will take one length dimension away).

It would be helpful to verify what the model actually does to approximate BURDEN* natively, which I haven't been able to find yet. I will share more details of what I find later. Again though, I think these values are pretty good approximations and so there is nothing urgent to address :)

PS: I remember tracking column integration in other climate models and they were using a fancier-than-I-would-expect numerical integrators, so it is perhaps more involved...

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 7, 2023

I couldn't locate the column integration bit in the source code. However, what I recommend here is the following: Try using the BURDEN* terms if available and then fall back on the Mass_* terms. In Python using xarray, as I am pretty sure developers here are fully aware, one can do something like the following.

try:
    burden = ds.BURDENSO4
except AttributeError:  # or whatever the actual exception is
    burden3d = ds.Mass_so4
    # proceed to numerical integration, etc. to get burden

However, this will inevitably introduce discrepancies across runs and some case runners/evaluators may be confused. Thus, a note/warning describing the calculation methodology atop the table is potentially desirable. (Or a note saying something like, "these are approximate quick calculations to benefit developers, but more accurate calculations are possible")

Since this work was reviewed and approved by AWG members previously, I will let them weigh in. I will likely not be able to add more to this conversation since this work precedes my involvement and I will likely be relying on my own twist on diagnostics for my own work.

I thought I should report the 1) the usefulness of this (!!!) and 2) how the values compare with the model's internal column-integrated burdens.

xref: #625

@chengzhuzhang
Copy link
Contributor

chengzhuzhang commented Mar 7, 2023

@mahf708 Thanks for your valuable input! Here is how column integration is done. The alternative you suggested should be straightforward to implementation, but I still hope to understand if there are discrepancies between 2d BURDEN terms and derived from 3d Mass other than the vertical integration difference. It would be the best to use the same source terms when compare across models. Note that BURDEN terms are not available from earlier version of production runs...

@chengzhuzhang
Copy link
Contributor

chengzhuzhang commented Mar 7, 2023

@mahf708 I think at the last aersol working group call, with Mingxuan's new PR, you mentioned that your simulation have both BURDEN_ and Mass_* variables. Would you share your path for climatology data, and I can try do a comparison.

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 9, 2023

Here is how column integration is done

Hi Jill, yeah, I saw your integration. I noted a few items (see this comment for example: #676 (comment)) that could help explain the discrepancy. However, I haven't been able to find the column integration in the v3atm/e3sm (main model) source code. If you know where it is in the v3am/e3sm codebase, please let me know and I will have a look too. I am quite intrigued.

My runs are available on chrysalis:

public link: https://web.lcrc.anl.gov/public/e3sm/diagnostic_output/ac.ngmahfouz/E3SMv3_dev/F2010.PD.NGD_v3atm.0096484.chrysalis/

paths:

/lcrc/group/e3sm/ac.ngmahfouz/E3SMv3_dev/F2010.PI.NGD_v3atm.0096484.chrysalis/post/atm/180x360_aave/clim/
/lcrc/group/e3sm/ac.ngmahfouz/E3SMv3_dev/F2010.PD.NGD_v3atm.0096484.chrysalis/post/atm/180x360_aave/clim/

And will be available on compy in the next few days:

paths:

/compyfs/mahf708/E3SMv3_dev/F2010.PI.NGD_v3atm.0096484.chrysalis/post/atm/180x360_aave/clim/
/compyfs/mahf708/E3SMv3_dev/F2010.PD.NGD_v3atm.0096484.chrysalis/post/atm/180x360_aave/clim/

@mahf708 mahf708 marked this pull request as ready for review March 9, 2023 13:55
@tangq
Copy link

tangq commented Mar 9, 2023

@mahf708 , this column integration example is for total column ozone (TOZ), and aerosol's should be similar except the units conversion. Look at lines 1057-1062.

https://github.com/E3SM-Project/v3atm/blob/NGD_v3atm/components/eam/src/chemistry/mozart/mo_chm_diags.F90#L1063

@chengzhuzhang
Copy link
Contributor

chengzhuzhang commented Mar 15, 2023

Results show 2d BURDEN* output versus 3d MASS* using e3sm_diags using @mahf708's run: F2010.PD.NGD_v3atm.0096484.compy and ANN average.

e3sm_diags* BURDEN* MASS*
BC (Tg) 0.199 0.202
DUST (Tg) 31.144 31.663
MOM (Tg) 0.073 0.079
SEASALT (Tg) 5.082 5.467
POM (Tg) 0.999 1.015
SO4 (Tg) 1.818 1.864
SOA (Tg) 2.917 2.970

There does seem to be discrepancies between two methods. Consistent with Naser's results, using MASS* output always gives slightly higher numbers, and for some species the difference could be large, in this case again SEA SALT numbers deviates about 7%. It is expected that there will be difference due to that the BURDEN* case, use the model column integration routine, the burden is computed in e3sm_diags with MASS* output. It remains unclear if all components of each species are taken in account for both BURDEN and MASS output.

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 15, 2023

It remains unclear if all components of each species are taken in account for both BURDEN and MASS output.

If I remember correctly, I believe your results have everything and are consistent. I noticed a discrepancy between v2 and v3 because a mode was added to so4 in v3. Not sure if Susannah shared with you our internal document we used to compare the budgets, but I believe your results are pretty accurate and the discrepancies are just numerical integration and assumptions (hydrostatic, etc.)

Also, I gave a little presentation about the preliminary results in here: https://acme-climate.atlassian.net/wiki/spaces/ATMOS/pages/3693805802/2023-03-03+Aerosol+Working+Group+Meeting+notes. May give another update, but this is not main research interest, so I am not sure how much I will look into the details.

Note the results I reported above were from chrysalis --- the results differ slightly across machines, e.g., compare these two identical runs (except for machine):

Copy link
Contributor

@chengzhuzhang chengzhuzhang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution @mahf708 ! I have documented the difference between using BURDEN output and MASS using e3sm_diags functions. At this point, I'm not sure if it is reliable to switch between these two group of output based on availability. I will merge this PR and keep an eye out if the discrepancies can be explained.

@mahf708
Copy link
Contributor Author

mahf708 commented Mar 15, 2023

Thanks @chengzhuzhang 👍

I will also report again if I find more insight. I will keep an eye. These aerosol budget tables and model-vs-model blocks are super useful to us 😸

@chengzhuzhang chengzhuzhang merged commit 4a82b0e into E3SM-Project:main Mar 15, 2023
@chengzhuzhang
Copy link
Contributor

I was particularly interested in the sea salt difference... In any case, the PR is merged! Thanks again for all the input and your kind words.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants