QSNOEVAP history output incorrect

[olyson]

Brief summary of bug

QSNOEVAP history output is incorrect.

General bug information

CTSM version you are using: release-clm5.0.15

Does this bug cause significantly incorrect results in the model's science? Yes, if QSNOEVAP is used for analysis

Configurations affected: All

Details of bug

In WaterfluxType.F90, QSNOEVAP is defined as:

this%qflx_ev_snow_patch(begp:endp) = spval
call hist_addfld1d (fname='QSNOEVAP', units='mm/s',  &
     avgflag='A', long_name='evaporation from snow', &
     ptr_patch=this%qflx_tran_veg_patch, set_lake=0._r8, c2l_scale_type='urbanf')

but last line should be:

     ptr_patch=this%qflx_ev_snow_patch, set_lake=0._r8, c2l_scale_type='urbanf')

[ekluzek]

@olyson @dlawrenncar should this fix go into release-clm5.0 ASAP then?

[dlawrenncar]

Yes. Bring this to the release code ASAP. We should remove QSNOEVAP from existing CMIP6 runs. Dave

…

On Tue, Jan 22, 2019 at 3:02 PM Erik Kluzek ***@***.***> wrote: @olyson <https://github.com/olyson> @dlawrenncar <https://github.com/dlawrenncar> should this fix go into release-clm5.0 ASAP then? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#624 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUAcVK7dzwvlBvIC7pRv9MJATTLg8bxSks5vF4p8gaJpZM4aNmEc> .

[olyson]

QSNOEVAP is only requested for daily averages and we haven't asked for that output for CMIP6 runs thus far.
We do have QSNOEVAP output from our CLM_LAND_ONLY_RELEASE runs, which was just published unfortunately. I'm not sure we can delete these but I guess I can ask Gary?
I can delete my version of QSNOEVAP on:
/glade/p/cgd/tss/people/oleson/CLM_LAND_ONLY_RELEASE

[olyson]

Gary will delete QSNOEVAP from the published version of CLM_LAND_ONLY_RELEASE.
He will also delete QSNOEVAP data at:
/gpfs/fs1/collections/cdg/timeseries-cmip6

[ekluzek]

I have a branch with the fix for this. I've also done some looking for this same type of problem elsewhere where ptr_patch points to the same array. There are some legit examples of this, where there is an ice mask for it. And there are some where a different name is allowed for the same variable.

[ekluzek]

So fixed on release branch will be fixed on master when those changes come in.