albgrd and albgri history fields depend on decomposition, for urban points

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2013-08-31 07:26:34 -0600
Bugzilla Id: 1806
Bugzilla CC: muszala@ucar.edu, oleson@ucar.edu, rfisher@ucar.edu,

I believe that this problem only affects history fields, and doesn't actually affect the operation of the model. This is a restatement of the initial bug in bug 1310 (most of the comments in that bug report really relate to a different bug).

For urban points, albgrd and albgri depend on the decomposition - either the number of tasks or the number of threads per task.

I believe that what is going on is the following (copied from bug 1310; I haven't checked carefully whether the behavior has changed slightly from this):

(1) In UrbanMod.F90: UrbanAlbedo: A count is made of the number of urban
landunits with coszen > 0 (num_solar); note that this count is just of the
number of landunits that this processor is responsible for; thus, this is where
the # PE-dependence comes in, I think.

(2) Later in that subroutine, a bunch of calculations are done if num_solar > 0
-- i.e., if this PE is responsible for at least one urban landunit with coszen

0. Note that many of these calculations are done for all landunits, even ones
   for which coszen = 0. This introduces the possibility for different results
   depending on the decomposition.

(3) The particular difference that I am seeing is in albgrd & albgri. These are
initialized to 0 at the start of the subroutine, and so remain 0 on any PE for
which num_solar = 0. However, for PEs with num_solar > 0, landunits that have
coszen = 0 end up getting albgrd = albgri = 1. This is because the calculation
of albgrd & albgri depends on the values of the sref_* variables, which are
initialized to 1 (and stay at 1 for any landunit for which coszen = 0).

I have confirmed this by comparing the following from clm4_5_20: SMS_Lm1_P180x1.f19_g16.ICLM45BGC.yellowstone_intel vs SMS_Lm1_P360x1.f19_g16.ICLM45BGC.yellowstone_intel - both with ALBGRD, ALBGRI, ALBD and ALBI added to history output.

One thing I am confused about is whether this problem occurs from albgrd and albgri, but not for albd and albi - since the latter seem to just be copies of the former in UrbanMod.

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2016-06-13 14:23:02 -0600

Keith: is this a priority to fix for CLM5? It affects these two diagnostic fields.

[billsacks]

Keith Oleson < oleson@ucar.edu > - 2016-06-13 14:47:20 -0600

I don't think it's a priority. As I understand it, it just affects those history fields (which are off by default) and not the model operation (as in actual albedos that the urban model uses and/or bfb restarts).

[billsacks]

Bill Sacks < sacks@ucar.edu > - 2016-06-13 14:58:17 -0600

Sounds good - thanks. Yes, your understanding is correct.

[billsacks]

@olyson I propose to just remove these problematic fields. Do you object? If you want to keep them, would you have time to work on this issue at some point?

(If @olyson is okay with this plan, then I'll label this as "simple bfb".)

[olyson]

I don't object to just removing these fields, thanks.

[billsacks]

Actually, I think I see a way to fix this problem that could also be good for performance. And, looking back at the code, I'd really like to remove this num_solar > 0 conditional. See #747

Blocked by #747