Repository: ESMCI/cime

Issue:
more robust method of determining when rof2ocn_fmapname (and maybe others) can be set to idmap
Currently, the setting of `rof2ocn_fmapname` needs to be set to a non "idmap" value if the "flood_present" flag is on. The flood_present flag is actually set by the ocean component at run time - so this is a bit of a chicken and egg problem. The flood_present flag is used in `prep_ocn_mod.F90` and then expects a valid value of `rof2ocn_fmapname`. For a data ocean model - flood_present can always be assumed to be false and so `rof2ocn_fmapname` can be "idmap". However, this is not necessarily the case for a prognostic ocean. A more robust method needs to be determined in order to determine if setting `rof2ocn_fmapname` = "idmap" is problematic.

@billsacks provided the following: Ideally, we'd have some data-driven list of mapping pairs that are optional (i.e., needed in some configuration but not in others). 


Discussion:
This is also an issue for glc2ice_rmapname and glc2ocn_rmapname: These are also needed in some configurations but not in others. I personally feel it's too much to ask the cime scripts to have the necessary logic to determine when these are needed, since their need is based on some non-trivial logic in glc. So I'm fine with the checks of these mapnames being deferred to runtime, as is currently the case. But ideally the listing of these as optional (i.e., not to be checked in the scripts) should be done in an xml file, rather than the current hard-coded list (`ignore_idmaps`) in `src/drivers/mct/cime_config/buildnml`.

Edit 10-25-17: glc2ocn_rmapname is being split into glc2ocn_liq_rmapname and glc2ocn_ice_rmapname.
@mvertens and @jedwards4b I just noticed that config_grids.xml already has a required_gridmaps section, which appears to be checked in grids.py: `_get_gridmaps_v2` (although it generates a warning rather than aborting with an error there). A naive glance makes it look like the grid-checking code that @mvertens recently added to the drv buildnml is serving essentially the same purpose as this existing code in grids.py. If that's true:

- Should one of them be removed?

- It looks like there is at least the start of a data-driven mechanism for listing the required mapping files in place via the required_gridmaps xml entries... is that usable for the purposes of this issue?

@sacks - I agree with you. I was aware of this when I implemented my check
- but I only wanted to change one thing. I do think we can remove the check
in grids.py - but I think we need to think carefully if there is some check
that is missing from what I did. @jedwards4b - thoughts?

On Mon, Oct 2, 2017 at 12:41 PM, Bill Sacks <notifications@github.com>
wrote:

> @mvertens <https://github.com/mvertens> and @jedwards4b
> <https://github.com/jedwards4b> I just noticed that config_grids.xml
> already has a required_gridmaps section, which appears to be checked in
> grids.py: _get_gridmaps_v2 (although it generates a warning rather than
> aborting with an error there). A naive glance makes it look like the
> grid-checking code that @mvertens <https://github.com/mvertens> recently
> added to the drv buildnml is serving essentially the same purpose as this
> existing code in grids.py. If that's true:
>
>    -
>
>    Should one of them be removed?
>    -
>
>    It looks like there is at least the start of a data-driven mechanism
>    for listing the required mapping files in place via the required_gridmaps
>    xml entries... is that usable for the purposes of this issue?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/ESMCI/cime/issues/1908#issuecomment-333626516>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AHlxE_W0IceH-K4GoG8Tmb_wfgDeIyv3ks5soS5lgaJpZM4Pef8W>
> .
>

What is the rationale for having the check in the drv buildnml rather than in grids.py? I'm not arguing one way or the other, I just want to understand it, particularly if the plan is to remove the existing infrastructure for grid checking (e.g., the required_gridmaps section of xml) and build new infrastructure that serves a similar purpose.
So to the question of where does this code belong - is it independent of driver?  If so I think it belongs in grids.py, otherwise in the driver buildnml.    This is only a warning in grids.py because at the time I put this code in place there were many such cases and we didn't want to fail them.
I think that the check should be done in the driver buildnml since the user
can change mapping files at run time - and there could possibly be future
checks that might be done that might be more detailed than the ones
currently implemented.

On Tue, Oct 3, 2017 at 11:13 AM, jedwards4b <notifications@github.com>
wrote:

> So to the question of where does this code belong - is it independent of
> driver? If so I think it belongs in grids.py, otherwise in the driver
> buildnml. This is only a warning in grids.py because at the time I put this
> code in place there were many such cases and we didn't want to fail them.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/ESMCI/cime/issues/1908#issuecomment-333914293>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AHlxE-OaH6XhGK0sl9PsLLtnDvwhlZI_ks5somsygaJpZM4Pef8W>
> .
>

> I think that the check should be done in the driver buildnml since the user
> can change mapping files at run time - and there could possibly be future
> checks that might be done that might be more detailed than the ones
> currently implemented.

Okay, thanks.

Resolving patch:
diff --git a/scripts/lib/CIME/nmlgen.py b/scripts/lib/CIME/nmlgen.py
--- a/scripts/lib/CIME/nmlgen.py
+++ b/scripts/lib/CIME/nmlgen.py
@@ -572,7 +572,7 @@ def add_default(self, name, value=None, ignore_abs_path=None):
                         continue
                     file_path = character_literal_to_string(literal)
                     # NOTE - these are hard-coded here and a better way is to make these extensible
-                    if file_path == 'UNSET' or file_path == 'idmap':
+                    if file_path == 'UNSET' or file_path == 'idmap' or file_path == 'idmap_ignore':
                         continue
                     if file_path == 'null':
                         continue
@@ -623,7 +623,7 @@ def _write_input_files(self, data_list_path):
                         for literal in literals:
                             file_path = character_literal_to_string(literal)
                             # NOTE - these are hard-coded here and a better way is to make these extensible
-                            if file_path == 'UNSET' or file_path == 'idmap':
+                            if file_path == 'UNSET' or file_path == 'idmap' or file_path == 'idmap_ignore':
                                 continue
                             if input_pathname == 'abs':
                                 # No further mangling needed for absolute paths.


Test patch: