B1850 compset can no longer be created off of cime master

[mvertens]

The PR with hash lbbbfc2
Merge pull request #1517 from jedwards4b/set_value_valid
is causing B1850 compsets to not work out of the box

The output is as follows:
Compset longname is 1850_CAM60_CLM50%BGC_CICE_POP2%ECO_MOSART_CISM2%NOEVOLVE_WW3_BGC%BDRD
Compset specification file is /glade/p/work/mvertens/cesm2_0_alpha06j.datamodels/cime/../cime_config/config_compsets.xml
Pes specification file is None
ERROR: No variable XROF_FLOOD_MODE found in case

This needs to be fixed as soon as possible since all PRs since then can no longer be used in the next cesm tag.

[billsacks]

I feel some responsibility for this, because I'm the one who pushed for getting this error-check put in place. Given the time crunch, I'd be reluctantly okay with backing out #1517 for now so that this error-check isn't done - as long as we plan to put it back in again soon when the cesm2 rush is done.

Although if we think that this is likely to be the only - or one of the only - offending xml variables, then it could be just as easy to fix this problem, I guess. My point is just that I'm not completely tied to the need to have the fix in #1517 right now if it's causing more trouble than it's worth.

[mvertens]

Lets back it off for now and add it back into the CESM milestones - but not as CRITICAL. that way we can decide if its the only offending variable and see if we can get it into the release.

…

On Sat, May 13, 2017 at 7:24 PM, Bill Sacks ***@***.***> wrote: I feel some responsibility for this, because I'm the one who pushed for getting this error-check put in place. Given the time crunch, I'd be reluctantly okay with backing out #1517 <#1517> for now so that this error-check isn't done - as long as we plan to put it back in again soon when the cesm2 rush is done. Although if we think that this is likely to be the only - or one of the only - offending xml variables, then it could be just as easy to fix this problem, I guess. My point is just that I'm not completely tied to the need to have the fix in #1517 <#1517> right now if it's causing more trouble than it's worth. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1532 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxE8uC14CmdsbdNOQEvzbb_SAVGf9rks5r5lewgaJpZM4NaPRW> .

[jedwards4b]

It's good to find and fix these now. Should there be an XROF_FLOOD_MODE variable? Probably not? I would rather fix this than back out the PR, I don't think it will take much. First thing Monday.

[ekluzek]

@jedwards4b I don't think that XROF_FLOOD_MODE should exist. FLOOD_MODE is an experimental configuration for CLM and an active ROF component (currently only RTM, but eventually MOSART). It routes an additional field through the coupler. I suppose having XROF_FLOOD_MODE could help to test this configuration. But, since it's a sideline mode right now I don't think you need it in the dead components. It should be easier to delete this rather than add it in and make sure it's working right.

[mvertens]

I agree with Erik. On Sun, May 14, 2017 at 6:53 PM Mariana Vertenstein <[email protected]> wrote:

…

On Sun, May 14, 2017 at 5:21 PM Erik Kluzek ***@***.***> wrote: > @jedwards4b <https://github.com/jedwards4b> I don't think that > XROF_FLOOD_MODE should exist. FLOOD_MODE is an experimental configuration > for CLM and an active ROF component (currently only RTM, but eventually > MOSART). It routes an additional field through the coupler. I suppose > having XROF_FLOOD_MODE could help to test this configuration. But, since > it's a sideline mode right now I don't think you need it in the dead > components. It should be easier to delete this rather than add it in and > make sure it's working right. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#1532 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AHlxE7r-kSw8s6YoNQdxtYZgm9OZq71nks5r54xkgaJpZM4NaPRW> > . >

[jedwards4b]

XROF_FLOOD_MODE is set in the config_grids.xml file in a line that looks like:

    <gridmap lnd_grid="1.9x2.5" rof_grid="r05" ocn_grid="gx1v7" >             
      <map name="XROF_FLOOD_MODE">ACTIVE</map>                                
    </gridmap>                                                                

I see two issues with this - first is this really where we should set this variable or should it be in the xrof config_component.xml file? Second - there are three grid attributes defined here, but if you look at the logic in grids.py it's only doing binary compares so if any two grids match we get a match. So in this case the lnd grid doesn't match but since rof and ocn do the variable is defined.

[jedwards4b]

I don't understand why, if this variable is used with clm and rtm, it's defined in xrof?

[jedwards4b]

I see these are also defined in xrof config_component.xml - I think that they should just be removed from the config_grids.xml file. I've also added a check in grids.py to make sure that the gridmap field in config_grids.xml has exactly two attributes. PR on the way.