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

release/public-v1: update and cleanup of build configurations #192

Conversation

climbfuji
Copy link
Collaborator

@climbfuji climbfuji commented Aug 27, 2020

Description

(1) Update modulefiles for hera.intel and jet.intel in accordance with NCEPLIBS-external/NCEPLIBS update. It was necessary to build our own netCDF libraries as part of NCEPLIBS-external, because using the default modules led to shared library issues with libsz in the ncep_post executable.

(2) Remove modulefiles, gnumake and cmake configurations for all platforms except level-1 (preconfigured). This is to avoid confusion, because the modulefiles for level 2/3 platforms by definition cannot contain libraries in shared spaces (libraries for the UFS MRW App are installed by the user in his/her own space).

Testing

Manual testing on pre-configured, configurable and limited testing platforms

  • ufs-weather-model compiles using build.sh and compile_cmake.sh on the following pre-configured platforms: hera.intel, cheyenne.intel, cheyenne.gnu, gaea.intel, jet.intel
  • ufs-weather-model compiles on tier-2 platforms (orion, stampede) using build.sh
  • ufs-weather-model compiles on macOS with clang+gfortran and gcc+gfortran using build.sh
  • ufs-weather-model compiles on Ubuntu 18 and RedHat 8 Amazon cloud instances using build.sh

Regression testing on cheyenne.intel, cheyenne.gnu, hera.intel

Regression tests against existing baselines:

Creating new baselines ufs-public-release-20200728:

  • for cheyenne.{intel,gnu}, I simply copied ufs-public-release-20200618 to ufs-public-release-20200728
  • on hera.intel: done

Final regression testing against new baselines:

Dependencies

@uturuncoglu
Copy link
Collaborator

@climbfuji @ligiabernardet this PR along with #191 #193 seems changing the build system. It seems NCEPLIBS_DIR is no longer used. If so, this will affect the CIME build that requires additional work and we need to discuss about it. Are we missing something in here? If you could clarify it that would be great.

@climbfuji
Copy link
Collaborator Author

@climbfuji @ligiabernardet this PR along with #191 #193 seems changing the build system. It seems NCEPLIBS_DIR is no longer used. If so, this will affect the CIME build that requires additional work and we need to discuss about it. Are we missing something in here? If you could clarify it that would be great.

NCEPLIBS_DIR is still to be used for the tier-2 and tier-3 platforms, just not for the tier-1 platforms.

@jedwards4b
Copy link

So this will break the build on tier-1 systems.

@climbfuji
Copy link
Collaborator Author

climbfuji commented Aug 28, 2020

So this will break the build on tier-1 systems.

No, why? It was decided to load the tier-1 modulefiles from ufs-weather-model instead of generating it from CIME. These modulefiles still set NCEPLIBS_DIR and should work out of the box. They (or, more precisely, the standalone ufs-weather-model build) don't rely on NCEPLIBS_DIR.

@uturuncoglu
Copy link
Collaborator

@climbfuji as I remember, we did not decide to add that capability or use it, we just discussed about its possibility. We did not even test it and we don't know it is working or not for this particular case. It also creates additional problem with other UFS applications such as HAFS. Currently, we are using same machine file for all UFS apps and the changes need to be test with all of them to be sure it is not breaking anything in other apps. So, that changes might require additional changes in the CIME side and it could have side effects. As I know, we need to keep the changes minimal in this release compared to v1.0. We already make couple of changes in the CIME interface.

@climbfuji
Copy link
Collaborator Author

@climbfuji as I remember, we did not decide to add that capability or use it, we just discussed about its possibility. We did not even test it and we don't know it is working or not for this particular case. It also creates additional problem with other UFS applications such as HAFS. Currently, we are using same machine file for all UFS apps and the changes need to be test with all of them to be sure it is not breaking anything in other apps. So, that changes might require additional changes in the CIME side and it could have side effects. As I know, we need to keep the changes minimal in this release compared to v1.0. We already make couple of changes in the CIME interface.

I have no preference on how CIME is using or generating the modulefiles. If you think it is easier to keep the MRW v1.0 way of generating them, then that is ok with me as long as they are updated and match the ones in ufs-weather-model for the tier-1 platforms. I will also update the doc/README_*.txt files in the release/public-v1 branch of NCEPLIBS-external so that they provide the correct information for all (tier 1, tier 2, tier 3) systems. The two files that need to change, as far as I am aware of, are doc/README_hera_intel.txt and doc/README_jet_intel.txt. I will tag you in the NCEPLIBS-external PR.

@uturuncoglu
Copy link
Collaborator

@climbfuji Thanks. Yes, I think it is better and easier to be close as much as possible to v1.0 structure to prevent any potential error. Anyway, we could discuss it in the call.

@climbfuji
Copy link
Collaborator Author

@junwang-noaa @DusanJovic-NOAA this PR and the fv3atm PR NOAA-EMC/fv3atm#163 are ready to merge.

Copy link
Collaborator Author

@climbfuji climbfuji left a comment

Choose a reason for hiding this comment

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

The release/public-v1 branch needs modulefiles only for pre-configured platforms for the release. These modulefiles have to match what is stored in the CIME machine config. The module files for the other machines (wcoss, ...) were outdated because not used and not tested. Cheyenne is kept, by the way (for intel and gnu).

netCDF is provided by the NCEPLIBS-external install as described in the PR above, to fix linker issues on the NOAA RDHPC platforms after the UPP (ncep_post) updates were made.

@@ -1,34 +0,0 @@
message("")
Copy link
Collaborator

@junwang-noaa junwang-noaa Aug 28, 2020

Choose a reason for hiding this comment

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

I am curious why wcoss platforms configuration files are removed, aren't they level-1 platforms?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No, they are not supported at all for UFS MRW v1.0 or v1.1: https://github.com/ufs-community/ufs/wiki/Supported-Platforms-and-Compilers

@DusanJovic-NOAA DusanJovic-NOAA merged commit 409c5a9 into ufs-community:release/public-v1 Aug 28, 2020
pjpegion pushed a commit to NOAA-PSL/ufs-weather-model.p7b that referenced this pull request Jul 20, 2021
* Fix to allow quilting with non-factors for layout (ufs-community#244)
* Remove the inline comments
epic-cicd-jenkins pushed a commit that referenced this pull request Apr 17, 2023
Mods to update real-time data on Jet and update pre-defined Alaska domains/GFDLgrid option for GSD 3-km CONUS domain
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.

5 participants