Relocate derived bucket assignment to conventional location

[davegill]

TYPE: bug fix

KEYWORDS: bucket

SOURCE: Chang Hai Liu (NCAR/RAL), internal

DESCRIPTION OF CHANGES:

Problem:
This modification includes two types of changes dealing with the buckets used for longer-term
simulations. The purpose of these buckets is to allow for an accurate accumulation of small values
over seasonal or regional climate time scales. These capabilities are both driven by derived namelist
options. Once a user defines a bucket size > 0, then the option is automatically activated.

• The derived option for the precip bucket was not handled in a standard way.
• The radiation bucket was completely broken. The requested fields were not output.

Solution:

1. The bucket information for precipitation used to be buried in dyn_em/namelist_remappings_em.h,
   which is not conventional and certainly not easy to find. This assignment of this derived variable is
   moved into module_check_a_mundo.F, where it belongs.
2. More importantly, there was no assignment of the derived namelist variable for the radiation / flux /
   energy bucket. If a user turned on the radiation bucket bucket_J=1, no additional output was
   manufactured. With this modification, as with the precip bucket in check_a_mundo, there is now an
   assignment to the derived radiation / flux / energy bucket option.

LIST OF MODIFIED FILES:
modified: dyn_em/namelist_remappings_em.h
modified: share/module_check_a_mundo.F

TESTS CONDUCTED:

• A segfault occurs instantly in the old code when requesting the bucket_J option because the
  fields are never allocated.

 &physics
 bucket_J = 10000.

• The results are identical for the rain buckets (original code vs the new code). This is expected
  since the only change for the rain bucket is the location of the assignment of the derived namelist
  option (module_check_a_mundo.F vs namelist_remappings_em.h). This is a 12-h simulation of
  the Jan 2000 case.

 &physics
 bucket_mm = 1.0

• When comparing the code for the radiation flux buckets, we can see the impact of buckets on
  the original code (no buckets) and the new code (able to use buckets). The difference fields reflect
  the size of the bucket over two 6-h time periods. There are places with 0 difference (old vs new
  code), and places with +- 10000 W/m^2 and +-20000 W/m^2. For selected points, the differences
  between old code total ACLWDNB (left) and the new code bucketed ACLWDNB (middle), is
  identically the bucket size * the number of buckets at that grid point.

 &physics
 bucket_J = 10000.

• waiting for confirmation from Chang Hai

RELEASE NOTE: Logic was added to include the buckets for accumulated radiation fields (i_acswupt, i_acswuptc, i_acswdnt, i_acswdntc, i_acswupb, i_acswupbc, i_acswdnb, i_acswdnbc, i_aclwupt, i_aclwuptc, i_aclwdnt, i_aclwdntc, i_aclwupb, i_aclwupbc, i_aclwdnb, i_aclwdnbc) when the user selects bucket_J > 0. Previously, when the user selected the bucket_J >0, no additional fields were computed or output.

[davegill]

@weiwangncar @kkeene44
Wei and Kelly,
This is only doing two simple things:

1. make the bucket option consistent with how we do derived namelist options
2. fix the bucket option for radiation
   Would you please review

[weiwangncar]

I'm ok with the change.

[kkeene44]

@davegill @weiwangncar
I know these 3 variables have already been in the code, but is there any way that you can add the descriptions for bucketr_opt, bucketf_opt, and prec_acc_opt to the README.namelist file, while this is open? I think it may be easier if we start requesting that the README file be updated with all new variables, with the pull requests, instead of having to add so much at one time prior to releases.

[weiwangncar]

@kkeene44 All three are derived namelists that users do not get to set directly. Hence it is ok not to list them in the README file.

[kkeene44]

@weiwangncar
Oh, okay - that makes sense then!