Skip to content

[release/public-v2] fixes for cheyenne and addition of FV3_WoFS_v0 to build#305

Merged
mark-a-potts merged 1 commit into
ufs-community:release/public-v2from
NOAA-EPIC:bugfix/cheyenne
Jun 15, 2022
Merged

[release/public-v2] fixes for cheyenne and addition of FV3_WoFS_v0 to build#305
mark-a-potts merged 1 commit into
ufs-community:release/public-v2from
NOAA-EPIC:bugfix/cheyenne

Conversation

@mark-a-potts
Copy link
Copy Markdown
Contributor

Fixes modules for Cheyenne.

@mark-a-potts mark-a-potts added the run_ci Launches CI/CD pipeline via jenkins label Jun 13, 2022
@mark-a-potts mark-a-potts changed the title fixes for cheyenne [release/public-v2] fixes for cheyenne Jun 13, 2022
@mark-a-potts mark-a-potts removed the run_ci Launches CI/CD pipeline via jenkins label Jun 13, 2022
@mark-a-potts mark-a-potts marked this pull request as ready for review June 14, 2022 12:58
@christopherwharrop-noaa
Copy link
Copy Markdown
Collaborator

My initial test of this failed for Intel on Cheyenne:

CMake Error at /glade/u/apps/ch/opt/cmake/3.22.0/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
  Could not find a package configuration file provided by "w3emc" with any of
  the following names:

    w3emcConfig.cmake
    w3emc-config.cmake

  Add the installation prefix of "w3emc" to CMAKE_PREFIX_PATH or set
  "w3emc_DIR" to a directory containing one of the above files.  If "w3emc"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  /glade/work/epicufsrt/GMTB/tools/intel/2022.1/hpc-stack-v1.2.0_6eb6/intel-2022.1/mpt-2.25/nemsio/2.5.4/lib64/cmake/nemsio/nemsio-config.cmake:41 (find_dependency)
  CMakeLists.txt:56 (find_package)


-- Configuring incomplete, errors occurred!

I'm going to retry in a fresh login shell to rule out any funny business with previous things I was doing.

Copy link
Copy Markdown
Collaborator

@christopherwharrop-noaa christopherwharrop-noaa left a comment

Choose a reason for hiding this comment

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

My initial failed test was due to a corrupted environment from previous work in the same shell. A retest of Intel build worked fine, and the gnu build also worked.

I am curious why the GNU build for the release is using version 11.2 while develop is using 10.1. I would normally expect new versions to be used on develop first, before being applied to a release, but I'm assuming there is some good explanation for that, and I'm curious to know what it is.

@mark-a-potts mark-a-potts changed the title [release/public-v2] fixes for cheyenne [release/public-v2] fixes for cheyenne and addition of FV3_WoFS_v0 to build Jun 15, 2022
@mark-a-potts
Copy link
Copy Markdown
Contributor Author

I am curious why the GNU build for the release is using version 11.2 while develop is using 10.1. I would normally expect new versions to be used on develop first, before being applied to a release, but I'm assuming there is some good explanation for that, and I'm curious to know what it is.

The explanation is probably not as good as would be desired, but it came down to the fact that we had gotten module files updated for 11.2 before the modules were updated for 10.1, so I made the switch. While testing with 10.1 later, I also ran into some problems during the forecast, which I haven't had time to figure out. Fortunately, no problems with 11.2.

@mark-a-potts mark-a-potts merged commit 7b3d5a5 into ufs-community:release/public-v2 Jun 15, 2022
@mark-a-potts mark-a-potts deleted the bugfix/cheyenne branch June 17, 2022 12:41
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