Add nwp physics option

[ekluzek]

We need to add a new physics option that for now I'm calling ctsm-nwp1_0 that's based on clm5_0 physics, but flags a few specific namelist items that are important for the NWP (Numerical Weather Prediction) configuration for CTSM.

I think the way to do this is to have it retain the model comparison features for clm series (so it would be assigned a value of 5.0), but also have specific namelist items check the exact string and be set accordingly.

In the long run with the python version we'll probably want a more general solution. But, we want a quick and dirty version that will work in the current environment that will allow a new physics setting.

@billsacks

[billsacks]

I was looking into how we use the numeric comparisons in CLMBuildNamelist, by searching for uses of as_long() (and then I did a quick search for other uses of phys or physv to see if I missed anything). It looks like, for the most part, this is just used to distinguish between clm4.0 and anything later (since clm4.0 uses a different code base). So, unless there's some other use of the numeric comparisons that I'm not aware of, it seems like this task will become much easier and cleaner if we first remove clm4.0 support.

Here are some exceptions, where we use the numeric comparisons in different ways. As I note below, I think all three of these exceptions are unnecessary:

(1)

  # These should NOT be set for CLM5.0 and beyond
  if ( $physv->as_long() > $physv->as_long("clm4_5") ) {
     foreach my $var ( "origflag", "h2osfcflag", "oldfflag" ) {
        my $val = $nl->get_value($var);
        if ( defined($val) ) {
           $log->fatal_error( "ERROR:: $var=$val is deprecated and can only be used with CLM4.5" );
        }
     }
  }

but I think we can just remove that one error-check to keep things simpler.

(2)

    my $var = "jmaxb1";
    if ( $physv->as_long() >= $physv->as_long("clm5_0") && &value_is_true( $nl_flags->{'use_luna'} ) ) {
       add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults, $nl, $var,
                     'use_luna'=>$nl_flags->{'use_luna'} );
    }

I would (somewhat naively) argue that this logic is wrong: it seems like this should just depend on use_luna without considering the phys version number. For example, if you want to run with mostly clm4_5 but turn on luna, my guess is that jmaxb1 should be added to the namelist, too. This feeling is supported by the following lines, which check for physv >= clm4_5, not clm5_0:

    my $val = $nl->get_value($var);
    if ( $physv->as_long() >= $physv->as_long("clm4_5") && ! &value_is_true( $nl_flags->{'use_luna'} ) ) {
       if ( defined($val) ) {
          $log->fatal_error("Cannot set $var when use_luna is NOT on" );
       }
    }

(3)

  if ( $physv->as_long() >= $physv->as_long("clm4_5") && $nl_flags->{'bgc_mode'} ne "sp" ) {
    # When FUN is on and it's clm5_0 get a default value
    if ( &value_is_true( $nl->get_value('use_fun') ) && $physv->as_long() >= $physv->as_long("clm5_0")) {
       add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults,
                   $nl, 'br_root', 'phys'=>$nl_flags->{'phys'},
                   'use_fun'=>$nl->get_value('use_fun'),
                   'use_cn'=>$nl_flags->{'use_cn'} );
    }

As with (2), I'd argue that this shouldn't be checking for physv >= clm5_0: it should just be checking if use_fun is on.

[billsacks]

@ekluzek - given my previous comment, my sense is that, if we first remove clm4.0 support (which I could plan to do soon for this purpose), we can remove the need for numeric comparisons. Can you let me know if you agree with this, or if I'm missing something?

So I'd propose the following plan of attack, where I would do (1) - (3) in the next few weeks, and you (possibly together with me) would do (4) - (5) in the next few months:

1. Remove clm4.0 support

2. Remove numeric comparison ability for now

3. Add nwp support, using exact string match

4. Convert to python

5. Add back in numeric comparison option, allowing this in the defaults xml file (Allow namelist defaults to apply for phys versions greater than or less than a given version #454 )

How does that sound to you?

[billsacks]

And to be clear: I'm thinking that, with my proposed plan, we would not need the "nwp1.0" option to "inherit" from "clm5_0".

[billsacks]

See #456 for discussion on what should be done with this phys option.

[ekluzek]

@billsacks I looked at the code some as well. And I think you are right, primarily the physics mode is used to distinguish out clm4_0. That's how it's actually used.

I looked a little bit into the exceptions that you list. The first group ( "origflag", "h2osfcflag", "oldfflag" ) is a way to deprecate options that should be heading towards removal.

"jmaxb1" is more complicated and probably needs more investigation. This check as it is, does go back at least until r200. It's likely it just needs to be tied to use_luna rather than clm5_0. But, we should figure that out for sure.

But, the sequence you give also makes sense to me.

[billsacks]

@ekluzek I plan to start tackling this soon. Regarding your last comment: who would be the appropriate person to weigh in on the jmaxb1 logic?

[ekluzek]

@billsacks @rosiealice and @wwieder would be two people to check with about Jmaxb1. It is local to LunaMod, so really is tied to use_luna=T.

[billsacks]

@rosiealice or @wwieder can one of you please confirm my feelings in point (2) in this comment

#451 (comment)

i.e., is it correct that the presence of jmaxb1 in the namelist should only be tied to whether use_luna is true – so that it's included even if running with clm4_5 physics if use_luna is set to true?

[rosiealice]

I think more generally that use-luna and clm4.5 shouldn't be mutually compatible. It's only used if Luna is on, yes, but I feel like there are loads of parameters in the parameter file that are only used, say, when flexcn is on by itself, so I'm unsure why this one has special treatment. In my sensitivity analysis paper I just finished the fact that this (and non of my other target parameters) was in the namelist caused me so many headaches I had to leave it out, which was scientifically pretty non-ideal...

…

On Thu, Jan 3, 2019, 7:42 PM Bill Sacks ***@***.*** wrote: @rosiealice <https://github.com/rosiealice> or @wwieder <https://github.com/wwieder> can one of you please confirm my feelings in point (2) in this comment #451 (comment) <#451 (comment)> i.e., is it correct that the presence of jmaxb1 in the namelist should only be tied to whether use_luna is true – so that it's included even if running with clm4_5 physics if use_luna is set to true? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#451 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQxCnwvEJXLKgoGTpXOHnqgufiO0Lks5u_k8ngaJpZM4ViQqS> .

[billsacks]

@rosiealice sorry, I'm having trouble interpreting your answer. I think the takeaway here is that I can change

    if ( $physv->as_long() >= $physv->as_long("clm5_0") && &value_is_true( $nl_flags->{'use_luna'} ) ) {
       add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults, $nl, $var,
                     'use_luna'=>$nl_flags->{'use_luna'} );
    }

to simply

    if ( &value_is_true( $nl_flags->{'use_luna'} ) ) {
       add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults, $nl, $var,
                     'use_luna'=>$nl_flags->{'use_luna'} );
    }

(Which I want to do to support the addition of an NWP physics option.)

But let me know if I'm misinterpreting your answer.

[rosiealice]

Umm. I'm not sure I can confirm or deny that as I don't speak whatever that language is you're using there, but: 1) jmaxb1 is only used when LUNA is TRUE. 2) LUNA is only ever true in CLM5. It can't be true in CLM4.5 3) LUNA is default TRUE in CLM5, but it can be switched off. Does that work? Le ven. 4 janv. 2019 à 00:01, Bill Sacks <notifications@github.com> a écrit :

…

@rosiealice <https://github.com/rosiealice> sorry, I'm having trouble interpreting your answer. I think the takeaway here is that I can change if ( $physv->as_long() >= $physv->as_long("clm5_0") && &value_is_true( $nl_flags->{'use_luna'} ) ) { add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults, $nl, $var, 'use_luna'=>$nl_flags->{'use_luna'} ); } to simply if ( &value_is_true( $nl_flags->{'use_luna'} ) ) { add_default($opts, $nl_flags->{'inputdata_rootdir'}, $definition, $defaults, $nl, $var, 'use_luna'=>$nl_flags->{'use_luna'} ); } (Which I want to do to support the addition of an NWP physics option.) But let me know if I'm misinterpreting your answer. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#451 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQ5C7bgRP121OgKWDqJaKDsNrFZ4Gks5u_ou3gaJpZM4ViQqS> .

-- ------------------------------------------------------------ Dr Rosie A. Fisher Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305, USA and Visitor @ C.E.R.F.A.C.S Centre Européen de Recherche et de Formation Avancée en Calcul Scientifique 42 Avenue Gaspard Coriolis 31057, Toulouse, France http://www.cgd.ucar.edu/staff/rfisher/

[billsacks]

Yes, good enough for me - thanks. (For the record: I'm going to go ahead with my proposed change.)

At some point I'd like to have more discussion about your point (2):

2. LUNA is only ever true in CLM5. It can't be true in CLM4.5

This statement doesn't work for me, because (in my mind) the physics option (clm4_5 vs. clm5_0) just sets a suite of default parameter values, which can then be overridden. So, in principle, one should be able to set up a CLM45 case, then change all of the individual namelist options that depend on the physics option to end up with a case that is identical to a CLM50 case.

So the relevant question for me is: What CLM4.5 option(s) is LUNA incompatible with?

This isn't a purely academic question: It's relevant, for example, as we introduce an NWP option that is something of a hybrid between CLM4.5 and CLM5.0: we'll need to determine if LUNA is compatible with this NWP physics option.

[rosiealice]

Ah, OK, fair enough, and a fine aspiration. I'm not sure what might or might not break in CLM4.5 with LUNA on... Le ven. 4 janv. 2019 à 00:31, Bill Sacks <notifications@github.com> a écrit :

…

Yes, good enough for me - thanks. (For the record: I'm going to go ahead with my proposed change.) At some point I'd like to have more discussion about your point (2): 1. LUNA is only ever true in CLM5. It can't be true in CLM4.5 This statement doesn't work for me, because (in my mind) the physics option (clm4_5 vs. clm5_0) just sets a suite of default parameter values, which can then be overridden. So, in principle, one should be able to set up a CLM45 case, then change all of the individual namelist options that depend on the physics option to end up with a case that is identical to a CLM50 case. So the relevant question for me is: What CLM4.5 option(s) is LUNA incompatible with? This isn't a purely academic question: It's relevant, for example, as we introduce an NWP option that is something of a hybrid between CLM4.5 and CLM5.0: we'll need to determine if LUNA is compatible with this NWP physics option. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#451 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMWsQ5GGBHg44aS_SSEz9p9-rSlGVzzbks5u_pLZgaJpZM4ViQqS> .

-- ------------------------------------------------------------ Dr Rosie A. Fisher Staff Scientist Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research 1850 Table Mesa Drive Boulder, Colorado, 80305, USA and Visitor @ C.E.R.F.A.C.S Centre Européen de Recherche et de Formation Avancée en Calcul Scientifique 42 Avenue Gaspard Coriolis 31057, Toulouse, France http://www.cgd.ucar.edu/staff/rfisher/