Add CMake build for public release #27

kgerheiser · 2020-09-30T15:44:58Z

This is a draft PR for the CMake build for the public release. It builds, but I think some things (libraries, executables) need to be moved around to have the expected layout.

To build, have the necessary modules loaded and run:

mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=<prefix>
make

DESCRIPTION OF CHANGES:

Adds a CMake build usinig ExternalProject_Add

TESTS CONDUCTED:

Cheyenne: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful on Cheyenne with intel, both for the cmake build and the old build script (that will soon be deprecated). Path to tests: /glade/scratch/kavulich/UFS_CAM/testing/SRW_PR_27/expt_dirs/
Hera: Build and end-to-end tests successful (aside from expected failures). Path to tests: /scratch2/BMC/det/kavulich/workdir/SRW_PR_27/expt_dirs
Jet: Build test was successful. Machine is having disk errors that are preventing me from running the end-to-end tests.

kgerheiser · 2020-09-30T15:59:47Z

I also see that the regular build reads from a file to determine CCPP_SUITES. I hardcoded it into CMakeLists.txt. That could be added pretty easily.

mkavulich · 2020-10-07T08:18:59Z

I have successfully built the full SRW App on Cheyenne, Hera, and Jet for intel. I have run the SRW App end-to-end on a test case on Cheyenne. Currently debugging some library issues on Hera end-to-end tests; once that is complete I think this PR is ready for merge.

Note that this PR must be merged at the same time as regional_workflow PR#304.

jwolff-ncar · 2020-10-07T12:57:38Z

Is there documentation on how to build with this new system so we can update the Getting Started page and get users up and running quickly?

…

On Wed, Oct 7, 2020 at 2:19 AM Michael Kavulich ***@***.***> wrote: I have successfully built the full SRW App on Cheyenne, Hera, and Jet for intel. I have run the SRW App end-to-end on a test case on Cheyenne. Currently debugging some library issues on Hera end-to-end tests; once that is complete I think this PR is ready for merge. Note that this PR must be merged at the same time as regional_workflow PR#304 <https://github.com/NOAA-EMC/regional_workflow/pull/304>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFN5ZDG2QDAEUKRN3SVX2LLSJQQAFANCNFSM4R7IKSCQ> .

-- Jamie K. Wolff National Center for Atmospheric Research (NCAR) Research Applications Laboratory (RAL) Phone: 303.497.2812 Email: [email protected] *My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.*

mkavulich · 2020-10-07T15:02:36Z

@jwolff-ncar The plan is to have individual README files in the docs/ directory for each individual build platform, in the same way NCEPLIBS-external does. Right now we have:

README_cheyenne_intel.txt
README_hera_intel.txt
README_jet_intel.txt

jwolff-ncar · 2020-10-07T17:00:47Z

Got it. Thanks for the path.

…

On Wed, Oct 7, 2020 at 9:02 AM Michael Kavulich ***@***.***> wrote: @jwolff-ncar <https://github.com/jwolff-ncar> The plan is to have individual README files in the docs/ directory for each individual build platform, in the same way NCEPLIBS-external does. Right now we have: - README_cheyenne_intel.txt - README_hera_intel.txt - README_jet_intel.txt — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFN5ZDDX4SOMZDMDOHV3IZLSJR7J5ANCNFSM4R7IKSCQ> .

-- Jamie K. Wolff National Center for Atmospheric Research (NCAR) Research Applications Laboratory (RAL) Phone: 303.497.2812 Email: [email protected] *My working day may not be your working day. Please do not feel obliged to reply to this email outside of your normal working hours.*

JulieSchramm

Looks good.

mkavulich

Given the Jet file system problems I will not delay this PR any further, and call the Cheyenne and Hera testing sufficient. I'll merge this and https://github.com/NOAA-EMC/regional_workflow/pull/304 shortly, and then cherry-pick the appropriate commits to the appropriate release branches.

gsketefian · 2020-10-08T20:14:44Z

Externals.cfg

-branch = feature/regional_release_STRING
-#hash = e5419633
+repo_url = https://github.com/JeffBeck-NOAA/UFS_UTILS
+branch = feature/regional_release


So we're pointing to the HEAD of feature/regional_release, not a tag?

I agree that pointing to the head of this branch is dangerous given the active nature of that PR; I will go ahead and replace that with a hash.

Ok, thanks.

I thought we were supposed to be pointing to Jeff's tag: v2.0alphav01

I used this in my test on Monday
repo_url = https://github.com/JeffBeck-NOAA/UFS_UTILS
tag = v2.0alpha01

I did not remember this Jamie, thanks for pointing it out. v2.0alpha01 is the same hash as the head of feature/regional_release so the results will be the same. I'll change the Externals.cfg to use that tag

…HEAD

…uild method....for now.

gsketefian · 2020-10-08T21:26:41Z

The backwards-compatibility changes look ok to me, but really best to do a build the old way to make sure it's ok. If you've done that, then that's fine!

gsketefian · 2020-10-08T21:33:10Z

@mkavulich I think this is related, but let me know if I'm just confused...
This morning, I got the latest version of this repo and tried to build HEAD of the develop branch of the ufs-weather-model with it. It encountered an error on the last line of build_forecast.sh:

cp ${model_top_dir}/ufs_weather_model ${model_top_dir}/tests/fv3.exe

Here, the executable is assumed to be "ufs_weather_model", but I had to change it to "ufs_model" for things to work. Also, in this and the sister PR into regional_workflow, the executable is assumed to be NEMS.x (I think), not ufs_weather_model or ufs_model. Any idea what's going on?

mkavulich · 2020-10-08T21:44:53Z

Yes @gsketefian I have run back-compatability tests, but only on Cheyenne (where I had committed locally) so I didn't catch that I had forgotten to push those changes here. I am running an extra test on Hera right now using the old build method just to make sure everything is in order.

I am confused about the error you are seeing...in the old way of building, build_forecast.sh calls the build.sh script in the ufs-weather-model, which at the end builds the NEMS.exe executable in ufs-weather-model/build and then copies it to ufs_weather_model/ufs_weather_model...I'm not sure why yours would be named ufs_model instead. I'm using the HEAD of ufs-weather-model:release/public-v2, which is what ufs-srweather-app:master should be pointing to

The new CMake build bypasses that build script entirely and just creates NEMS.exe, which is then copied to bin/fv3_gfs.x by the generate workflow script.

JulieSchramm · 2020-10-08T22:30:21Z

@michael Kavulich <[email protected]> You can incorporate the minor changes I made in PR #29 to Externals.cfg to use the tag of Jeff's fork, and the release/public-v1 branch of the workflow. Then we can close that PR when yours is merged.

…

On Thu, Oct 8, 2020 at 3:45 PM Michael Kavulich ***@***.***> wrote: Yes @gsketefian <https://github.com/gsketefian> I have run back-compatability tests, but only on Cheyenne (where I had committed locally) so I didn't catch that I had forgotten to push those changes here. I am running an extra test on Hera right now using the old build method just to make sure everything is in order. I am confused about the error you are seeing...in the old way of building, build_forecast.sh calls the build.sh script in the ufs-weather-model, which at the end builds the NEMS.exe executable in ufs-weather-model/build and then copies it to ufs_weather_model/ufs_weather_model...I'm not sure why yours would be named ufs_model instead. I'm using the HEAD of ufs-weather-model:release/public-v2, which is what ufs-srweather-app:master should be pointing to The new CMake build bypasses that build script entirely and just creates NEMS.exe, which is then copied to bin/fv3_gfs.x by the generate workflow script. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3WNUZLZNH43CDFUTBGMQLSJYXGJANCNFSM4R7IKSCQ> .

gsketefian · 2020-10-08T22:34:30Z

Yes @gsketefian I have run back-compatability tests, but only on Cheyenne (where I had committed locally) so I didn't catch that I had forgotten to push those changes here. I am running an extra test on Hera right now using the old build method just to make sure everything is in order.

I am confused about the error you are seeing...in the old way of building, build_forecast.sh calls the build.sh script in the ufs-weather-model, which at the end builds the NEMS.exe executable in ufs-weather-model/build and then copies it to ufs_weather_model/ufs_weather_model...I'm not sure why yours would be named ufs_model instead. I'm using the HEAD of ufs-weather-model:release/public-v2, which is what ufs-srweather-app:master should be pointing to

The new CMake build bypasses that build script entirely and just creates NEMS.exe, which is then copied to bin/fv3_gfs.x by the generate workflow script.

@mkavulich It must be because I was getting the HEAD of the develop branch of ufs-community/ufs-weather-model. It was for the DTC-PAS project. There, the executable ufs_weather_model is renamed to ufs_model, I suppose because it can include not only a weather model but also an ocean model, and in S2S applications, it's more like a climate model than a weather model. I guess you'll encounter this change when you start using the develop branch again.

…ach repository (#304) ## DESCRIPTION OF CHANGES: The new top-level cmake build for the SRW App ([SRW App PR#27](ufs-community/ufs-srweather-app#27)) results in some executables having different names. This PR makes modifications that 1. Allow the workflow to run successfully with the new cmake build and its different executable names, and 2. Allow back-compatibility with the old build system to allow for a gradual transition to new build system This PR also explicitly disallows running the workflow without CCPP, which we decided against supporting several months ago. I don't think the capability even works so this shouldn't effect anyone at this time. ## TESTS CONDUCTED: - **Cheyenne**: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful on Cheyenne with intel, both for the cmake build and the old build script (that will soon be deprecated). - **Hera**: Build and end-to-end tests successful (aside from expected failures). Also built with old build script successfully. - **Jet**: Build test was successful. ## ISSUE: It was not the primary aim of this PR, but it does partially resolve #196

- Adds a CMake build using ExternalProject_Add. - Makes modifications to build_all.sh and install_all.sh for back-compatibility with old build system. The old build system will remain in, but is now deprecated, and will be removed in the coming weeks. To build, have the necessary modules loaded and run: ``` mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX=<prefix> make ``` The docs/ directory contains README files with instructions for specific platforms/compilers - **Cheyenne**: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful on Cheyenne with intel, both for the cmake build and the old build script (that will soon be deprecated). Path to tests: /glade/scratch/kavulich/UFS_CAM/testing/SRW_PR_27/expt_dirs/ - **Hera**: Build and end-to-end tests successful (aside from expected failures). Path to tests: /scratch2/BMC/det/kavulich/workdir/SRW_PR_27/expt_dirs - **Jet**: Build test was successful. Resolves #7, partially resolves #5 Co-authored-by: kgerheiser <[email protected]>; Michael Kavulich, Jr <[email protected]>

## DESCRIPTION OF CHANGES: This is a subset of the changes that were added to develop with PR #27. This commit adds cmake capabilities, but does not maintain back-compatibility with the older build system. To build, have the necessary modules loaded and run: ``` mkdir build cd build cmake .. -DCMAKE_INSTALL_PREFIX=<prefix> make ``` The docs/ directory contains README files with instructions for specific platforms/compilers ## TESTS CONDUCTED: - **Cheyenne**: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful on Cheyenne with intel - **Hera**: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful Co-authored-by: kgerheiser <[email protected]>; Michael Kavulich, Jr <[email protected]>

…ach repository (#315) Modifications to run workflow with unmodified executable names from each repository (#304) ## DESCRIPTION OF CHANGES: The new top-level cmake build for the SRW App ([SRW App PR#27](ufs-community/ufs-srweather-app#27)) results in some executables having different names. This PR makes modifications that 1. Allow the workflow to run successfully with the new cmake build and its different executable names, and 2. Allow back-compatibility with the old build system to allow for a gradual transition to new build system This PR also explicitly disallows running the workflow without CCPP, which we decided against supporting several months ago. I don't think the capability even works so this shouldn't effect anyone at this time . ## TESTS CONDUCTED: - **Cheyenne**: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful on Cheyenne with intel, both for the cmake build and the old build script (that will soon be deprecated). - **Hera**: Build and end-to-end tests successful (aside from expected failures). Also built with old build script successfully. - **Jet**: Build test was successful. ## ISSUE: It was not the primary aim of this PR, but it does partially resolve #196

* Updates for inline post. * Loading upp module. Not building EMC Post * Removing EMC_post from externals * Fix AWS build environment settings Change platform from aws.intel to aws. Change Intel MPI module to use the module that supports EFA. * Add workflow env script for AWS * Fixes for HWT configs. * Put this file back to original * Actually put the file back to the original! * Load rocoto with wflow env. Co-authored-by: Christopher Harrop <[email protected]>

…ach repository (ufs-community#304) ## DESCRIPTION OF CHANGES: The new top-level cmake build for the SRW App ([SRW App PR#27](ufs-community#27)) results in some executables having different names. This PR makes modifications that 1. Allow the workflow to run successfully with the new cmake build and its different executable names, and 2. Allow back-compatibility with the old build system to allow for a gradual transition to new build system This PR also explicitly disallows running the workflow without CCPP, which we decided against supporting several months ago. I don't think the capability even works so this shouldn't effect anyone at this time. ## TESTS CONDUCTED: - **Cheyenne**: Build and end-to-end test ("DOT_OR_USCORE" test case) was successful on Cheyenne with intel, both for the cmake build and the old build script (that will soon be deprecated). - **Hera**: Build and end-to-end tests successful (aside from expected failures). Also built with old build script successfully. - **Jet**: Build test was successful. ## ISSUE: It was not the primary aim of this PR, but it does partially resolve ufs-community#196

…id for sea ice dynamics (was #1390) (#1381) * update ice_in and submodules * cesm_ponds is deprecated so remove from ice_in * fix hafs-wav configurations * turn ice coupling off for all hafs+wav tests * turn current coupling off for hafs-atm-wav test * add a cdeps test using c-grid for CICE6 (ufs-community#27)

kgerheiser added 3 commits September 28, 2020 09:37

Update CMake

528e0a1

Enable building post and UFS_UTILS

35fbe10

Merge master into feature/cmake

9216858

kgerheiser and others added 5 commits September 30, 2020 13:00

Make EMC_post lowercase in CMakeLists

515e067

Add Hera build instructions

a9716b4

Fix git clone location for hera, add Cheyenne build instructions

a545ace

Install weather model executable to bin

626866b

Add Jet build instructions

43f6785

mkavulich mentioned this pull request Oct 7, 2020

Modifications to run workflow with unmodified executable names from each repository ufs-community/regional_workflow#304

Merged

Updates to Hera README that fixes runtime library issues; thanks Dom!

a4c1541

mkavulich marked this pull request as ready for review October 8, 2020 08:02

mkavulich requested review from gsketefian, JeffBeck-NOAA, JulieSchramm and mkavulich as code owners October 8, 2020 08:02

JulieSchramm approved these changes Oct 8, 2020

View reviewed changes

mkavulich approved these changes Oct 8, 2020

View reviewed changes

gsketefian reviewed Oct 8, 2020

View reviewed changes

mkavulich linked an issue Oct 8, 2020 that may be closed by this pull request

Use cmake build for EMC_post #7

Closed

4 tasks

mkavulich added 3 commits October 8, 2020 14:21

Update Externals.cfg to point to hash on Jeff's fork rather than the …

f5b32a5

…HEAD

Changes to old build scripts to maintain back-compatiblity with old b…

9bbd378

…uild method....for now.

Had incorrect executable name for post

8e0efc3

Use tag for Jeff's UFS_UTILS rather than static hash

b81403d

mkavulich merged commit eee801a into ufs-community:master Oct 9, 2020

mkavulich mentioned this pull request Oct 9, 2020

Add cmake build to release branch #30

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add CMake build for public release #27

Add CMake build for public release #27

kgerheiser commented Sep 30, 2020 •

edited by mkavulich

Loading

kgerheiser commented Sep 30, 2020

mkavulich commented Oct 7, 2020

jwolff-ncar commented Oct 7, 2020 via email

mkavulich commented Oct 7, 2020

jwolff-ncar commented Oct 7, 2020 via email

JulieSchramm left a comment

mkavulich left a comment

gsketefian Oct 8, 2020

mkavulich Oct 8, 2020

gsketefian Oct 8, 2020

jwolff-ncar Oct 8, 2020

jwolff-ncar Oct 8, 2020

mkavulich Oct 8, 2020

gsketefian commented Oct 8, 2020

gsketefian commented Oct 8, 2020

mkavulich commented Oct 8, 2020

JulieSchramm commented Oct 8, 2020 via email

gsketefian commented Oct 8, 2020

Add CMake build for public release #27

Add CMake build for public release #27

Conversation

kgerheiser commented Sep 30, 2020 • edited by mkavulich Loading

DESCRIPTION OF CHANGES:

TESTS CONDUCTED:

kgerheiser commented Sep 30, 2020

mkavulich commented Oct 7, 2020

jwolff-ncar commented Oct 7, 2020 via email

mkavulich commented Oct 7, 2020

jwolff-ncar commented Oct 7, 2020 via email

JulieSchramm left a comment

Choose a reason for hiding this comment

mkavulich left a comment

Choose a reason for hiding this comment

gsketefian Oct 8, 2020

Choose a reason for hiding this comment

mkavulich Oct 8, 2020

Choose a reason for hiding this comment

gsketefian Oct 8, 2020

Choose a reason for hiding this comment

jwolff-ncar Oct 8, 2020

Choose a reason for hiding this comment

jwolff-ncar Oct 8, 2020

Choose a reason for hiding this comment

mkavulich Oct 8, 2020

Choose a reason for hiding this comment

gsketefian commented Oct 8, 2020

gsketefian commented Oct 8, 2020

mkavulich commented Oct 8, 2020

JulieSchramm commented Oct 8, 2020 via email

gsketefian commented Oct 8, 2020

kgerheiser commented Sep 30, 2020 •

edited by mkavulich

Loading