E3sm: Bug in modal_aer_opt.F90

[kaizhangpnl]

In the MAM verification work, we (@jiansunpnnl @kaizhangpnl) find that in modal_aer_opt.F90 (https://github.com/E3SM-Project/E3SM/blob/master/components/cam/src/physics/cam/modal_aer_opt.F90), the marine organic aerosol (MOA) burden fields are initialized twice, but the MOA AOD properties are not initialized. This looks like a bug and needs to be fixed.

if ( defined MODAL_AERO_4MODE_MOM )

burdenmom(:ncol) = 0.0_r8

elif ( defined MODAL_AERO_9MODE )

burdenpoly(:ncol) = 0.0_r8
burdenprot(:ncol) = 0.0_r8
burdenlip(:ncol) = 0.0_r8

endif

ssavis(1:ncol) = 0.0_r8

aodabsbc(:ncol) = 0.0_r8
dustaod(:ncol) = 0.0_r8
so4aod(:ncol) = 0.0_r8
pomaod(:ncol) = 0.0_r8
soaaod(:ncol) = 0.0_r8
bcaod(:ncol) = 0.0_r8
seasaltaod(:ncol) = 0.0_r8

**#if ( defined MODAL_AERO_4MODE_MOM )
burdenmom(:ncol) = 0.0_r8

elif ( defined MODAL_AERO_9MODE )

burdenpoly(:ncol) = 0.0_r8
burdenprot(:ncol) = 0.0_r8
burdenlip(:ncol) = 0.0_r8

endif**

[susburrows]

Thanks for finding this; it does look like a bug. I will take a look in the next couple of days.

[yshi5]

I also noticed this recently. It will influence the calculation of momaod, polypod, protaod, and lipaod and the related output variables (e.g. AODMOM, ...). It seems this bug can be simply fixed by initializing the aod variables. I feel this part is more like diagnostic output and the model results should not be changed after the bug fixed.

[rljacob]

@susburrows did you ever get a chance to look at this?

[susburrows]

Not yet. Do we have a timeline for when the fix is needed? I guess it would be nice to have it fixed for v2, but I'm not sure if there's a reason for more urgency.

[rljacob]

No. I was just sending a reminder.

[ambrad]

We encountered this issue again, in issue #3956. Is the solution of simply initializing these arrays to 0 OK with everyone, like this?

#if ( defined MODAL_AERO_4MODE_MOM )
   momaod(:ncol) = 0._r8
#elif ( defined MODAL_AERO_9MODE )
   polyaod(:ncol) = 0._r8
   protaod(:ncol) = 0._r8
   lipaod(:ncol) = 0._r8
#endif

[singhbalwinder]

It looks like a valid fix but I am tagging @susburrows @kaizhangpnl @hwangacme and @polunma who know this code well. Thanks for catching this and I hope it doesn't change the answers. From a quick look at the code, it looks like it may change answers for compilers/machines where the compiler doesn't guarantees zero initialization of these arrays.

[ambrad]

@singhbalwinder: one important point is that these quantities are diagnostic. So it's not that big of an issue. The primary motivation to fix this is we're trying to get DEBUG=true builds to go through to reveal stuff that matters (hopefully), so we're cleaning up some little things like this that stop the run before it can be informative.

[hwangacme]

It looks like a valid fix to me, which should only affect the diagnostic variable AODMOM.

[susburrows]

@ambrad thanks for working on this (it's never quite risen to the top of my todo-list after all this time). The fix looks fine to me as well, if those diagnostic variables were not initialized to zero, that was a simple oversight on my part. I agree it's not that big of an issue since I'm not sure if anyone has actually been using this variable and it doesn't change the model state, but also agree it would be good to clean it up. Can you tag us again after a PR is issued, so we can review the change in context?

[kaizhangpnl]

Looks good to me.

[ambrad]

@susburrows see PR #3978.