Open billsacks opened 6 years ago
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.
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).
Bill Sacks < sacks@ucar.edu > - 2016-06-13 14:58:17 -0600
Sounds good - thanks. Yes, your understanding is correct.
@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".)
I don't object to just removing these fields, thanks.
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
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
(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 numsolar > 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.