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

Mixed Mode Updates needed for FMS 2022.01 #66

Closed

Conversation

laurenchilutti
Copy link

FMS 2022.01 will enable mixed mode updates that are needed for the ufs-weather-model. This PR brings the work done by MInsuk Ji in the NOAA-EMC PR 79 (NOAA-EMC#79) and brings it to dev/gfdl branch which is needed for the GFDL models to work with FMS 2022.01.

I am also requesting a tag be created following this PR's merge for use with the GFDL models (the tag could be "2022.01" or something else if you prefer).

Copy link
Member

@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.

These changes were discussed at a recent MOM6 dev call, with the team at EMC presenting them. As written, these changes would require an immediate change to the version of FMS that people are using, with no possibility of doing any kind of comparison across the change where we mix old and new versions of FMS and MOM6. We have gone through something like this before, and there was widespread agreement that this would be unacceptably disruptive and error prone.

Instead we have an alternative solution that will not be disruptive for the broad community of MOM6 users. The entire config_src/infra/FMS2 directory should be duplicated into a new directory (the name that was floated was config_src/infra/FMS2_mp, for "mixed precision"). The contents of that new directory could then be modified to permit the use of the new version of FMS, and existing MOM6 users could migrate over to this new version in an orderly way as their other workloads and run production schedules permit.

@laurenchilutti
Copy link
Author

Thank you for that feedback. I will wait for the team at EMC to address your remarks on their PR (79).

@@ -276,15 +294,15 @@ end function send_data_infra_1d
logical function send_data_infra_2d(diag_field_id, field, is_in, ie_in, js_in, je_in, &
time, mask, rmask, weight, err_msg)
integer, intent(in) :: diag_field_id !< The diagnostic manager identifier for this field
real, dimension(:,:), intent(in) :: field !< A 2-d array of values being recorded
class(*),dimension(:,:), intent(in) :: field !< A 2-d array of values being recorded

Choose a reason for hiding this comment

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

Why is this needed? And if it is required, why is it not also needed in the caller of this routine?

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.

4 participants