Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use FMS2 file_exists, remove domain args #1532

Merged
merged 2 commits into from
Oct 26, 2021

Conversation

marshallward
Copy link
Collaborator

This patch uses the FMS2 file_exists function when using the FMS2
infra. Previously, the FMS1 version of this function was being used.

This patch also removes the mpp_domain and no_domain arguments from
the direct file_exist calls, which were not used by any known MOM6
configurations. (Nor would we expect them to be, since explicit
references to FMS should not exist outside of the infra layer.)

Since FMS2 does not use these arguments, their removal also creates a
more meaningful interface between the two frameworks.

Motivation:

An issue with the FMS1 file_exists under the FMS2 infra was discovered
in the UFS model on Hera. It was only reproducible in submitted jobs,
and not for interactive jobs, and only with the GCC 9.2 compiler.
(Other GCC versions were not tested.)

One potential explanation is that it is related to the save attribute
of the domain pointer, d_ptr. In the case above, d_ptr pointed to
the MOM input domain for the failed cases. For the other working
cases, d_ptr pointed to a NULL() value and behavior was normal.

It is possible that d_ptr is inconsisently updated when FMS1 and FMS2
IO operations are used together, which should probably be considered
undefined behavior.

This patch uses the FMS2 `file_exists` function when using the FMS2
infra.  Previously, the FMS1 version of this function was being used.

This patch also removes the `mpp_domain` and `no_domain` arguments from
the direct `file_exist` calls, which were not used by any known MOM6
configurations.  (Nor would we expect them to be, since explicit
references to FMS should not exist outside of the infra layer.)

Since FMS2 does not use these arguments, their removal also creates a
more meaningful interface between the two frameworks.

Motivation:

An issue with the FMS1 `file_exists` under the FMS2 infra was discovered
in the UFS model on Hera.  It was only reproducible in submitted jobs,
and not for interactive jobs, and only with the GCC 9.2 compiler.
(Other GCC versions were not tested.)

One potential explanation is that it is related to the `save` attribute
of the domain pointer, `d_ptr`.  In the case above, `d_ptr` pointed to
the MOM input domain for the failed cases.  For the other working
cases, `d_ptr` pointed to a `NULL()` value and behavior was normal.

It is possible that `d_ptr` is inconsisently updated when FMS1 and FMS2
IO operations are used together, which should probably be considered
undefined behavior.
@codecov
Copy link

codecov bot commented Oct 22, 2021

Codecov Report

Merging #1532 (0df0467) into dev/gfdl (6dd1d14) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff            @@
##           dev/gfdl    #1532   +/-   ##
=========================================
  Coverage     29.10%   29.10%           
=========================================
  Files           239      239           
  Lines         71524    71524           
=========================================
  Hits          20818    20818           
  Misses        50706    50706           
Impacted Files Coverage Δ
config_src/infra/FMS1/MOM_io_infra.F90 20.59% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6dd1d14...0df0467. Read the comment docs.

Copy link
Collaborator

@Hallberg-NOAA Hallberg-NOAA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the direction of this change, but I would actually take this one step further. With the removal of the infrastructure-specific arguments from FMS_file_exists(), I do not see any reason why FMS_file_exists() and MOM_file_exists() should be separate routines under the same overloaded interface. They could easily be merged by making the MOM_domain_type an optional argument to the combined file_exists() routine.

The only potential snag that I see is that some compilers (PGI, I think) have difficulties handling renaming of a routine from a module use statement that has the same name original as a new interface (as is the case here with file_exists() in the FMS2 version).

@marshallward
Copy link
Collaborator Author

marshallward commented Oct 26, 2021

Let me think about your suggestion. My immediate preference is to keep using an interface, which is resolved at compile time, rather than a single function containing an if (present(domain)) block which is resolved at runtime (assuming that is what you have in mind).

There is also the issue that FMS1 will always go through the same file_exist function in fms_io - which maps well on to your suggestion - but FMS2 has its own file_exists which does not support a domain. When a domain is provided, we have to fall back to the old fms_io implementation.

I think this fallback to FMS1 is already a bit problematic, and perhaps we should look into how to do this for files with domains.

Copy link
Collaborator

@Hallberg-NOAA Hallberg-NOAA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am convinced that this limited change is the right step, at least for now. This PR has passed TC testing and pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/13918.

@Hallberg-NOAA Hallberg-NOAA merged commit 9d0a92b into mom-ocean:dev/gfdl Oct 26, 2021
@marshallward marshallward deleted the fms2_file_exist branch March 8, 2022 19:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants