Repository: ESMCI/cime

Issue:
B1850 compset can no longer be created off of cime master
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.



Discussion:
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.
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 <notifications@github.com>
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
> <https://github.com/ESMCI/cime/pull/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 <https://github.com/ESMCI/cime/pull/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
> <https://github.com/ESMCI/cime/issues/1532#issuecomment-301284678>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AHlxE8uC14CmdsbdNOQEvzbb_SAVGf9rks5r5lewgaJpZM4NaPRW>
> .
>

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.
@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.
I agree with Erik.

On Sun, May 14, 2017 at 6:53 PM Mariana Vertenstein <mvertens@ucar.edu>
wrote:

>
> On Sun, May 14, 2017 at 5:21 PM Erik Kluzek <notifications@github.com>
> 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
>> <https://github.com/ESMCI/cime/issues/1532#issuecomment-301347002>, or mute
>> the thread
>> <https://github.com/notifications/unsubscribe-auth/AHlxE7r-kSw8s6YoNQdxtYZgm9OZq71nks5r54xkgaJpZM4NaPRW>
>> .
>>
>

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.
I don't understand why, if this variable is used with clm and rtm, it's defined in xrof?
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.

Resolving patch:
diff --git a/scripts/lib/CIME/XML/grids.py b/scripts/lib/CIME/XML/grids.py
--- a/scripts/lib/CIME/XML/grids.py
+++ b/scripts/lib/CIME/XML/grids.py
@@ -405,6 +405,8 @@ def _get_gridmaps_v2(self, component_grids):
                 gridmap_nodes = self.get_nodes(nodename="gridmap",
                                                attributes={gridname:gridvalue, other_gridname:other_gridvalue})
                 for gridmap_node in gridmap_nodes:
+                    expect(len(gridmap_node.attrib) == 2,
+                           " Bad attribute count in gridmap node %s"%gridmap_node.attrib)
                     map_nodes = self.get_nodes(nodename="map",root=gridmap_node)
                     for map_node in map_nodes:
                         name = map_node.get("name")


Test patch: