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

Updated support on Odin & Stampede to use NCEPLIBS public-v2 release #194

Merged

Conversation

ywangwof
Copy link
Contributor

@ywangwof ywangwof commented Oct 1, 2020

I just updated the module files on Odin and Stampede to use the newly built NCEPLIBS from NCEPLIBS repository from branch "public-v2".

@fossell
Copy link
Contributor

fossell commented Oct 1, 2020

@WenMeng-NOAA Given our recent discussion about UPP version, how do you want to handle the versions listed in the modulefiles in each release branch? In release/public-v2 we decided on v9.0.0. Do we want to make that change in the modulefiles as well?

@WenMeng-NOAA
Copy link
Collaborator

@fossell, I see Yunheng submitted the changes to both develop and release/public-v2. The modulefiles is used in GNC build. If cmake build is not used them, you may keep them (it would be easily merging the changes from release/public-v2 to develop).
But it is upto your decision. In the future, we might remove the version number from modulefiles name convention.

@fossell
Copy link
Contributor

fossell commented Oct 1, 2020

@ywangwof I assume that these changes are required because you are building UPP using the sorc/build_ncep_post.sh script on those platforms that uses the modulefiles, instead of building UPP using cmake. So you are not building within the SRW app, but you just want to make sure that your modulefiles point to the same NCEPLIBS that is used by SRW app and cmake build. Is that correct?

@fossell
Copy link
Contributor

fossell commented Oct 1, 2020

@fossell, I see Yunheng submitted the changes to both develop and release/public-v2. The modulefiles is used in GNC build. If cmake build is not used them, you may keep them (it would be easily merging the changes from release/public-v2 to develop).
But it is upto your decision. In the future, we might remove the version number from modulefiles name convention.

@WenMeng-NOAA Ok, it seems like @ywangwof is wanting to use the GNU build (build_ncep_post.sh) in this public-v2 branch. The modulefiles won't impact cmake build, so I have no problem with the mods. I just wonder if I should rename the odin and stampede files to v9 just to reflect that they are hard coded to point to specific SRW versions of NCEPLIBS. Agree that in future we could consider removing the version from the filenames to avoid confusion.

@ywangwof
Copy link
Contributor Author

ywangwof commented Oct 1, 2020

@ywangwof I assume that these changes are required because you are building UPP using the sorc/build_ncep_post.sh script on those platforms that uses the modulefiles, instead of building UPP using cmake. So you are not building within the SRW app, but you just want to make sure that your modulefiles point to the same NCEPLIBS that is used by SRW app and cmake build. Is that correct?

@fossell That is NOT right. I am building from the SRW app. My current version of the SRW app is dated on 2020-09-25 with hash #d8e9e31 and it is the latest one just checked out today. It is built using "src/build_all.sh" -> "src/build_post.sh" -> "EMC_post/compile" -> "EMC_post/sorc/build_ncep_post.sh". The "EMC_post" is dated on 2020-09-22 with hash #abb393e and it is checked out with "manage_externals/checkout_externals". It seems that I do not have the CMake configuration built in yet. Did I miss anything?

@fossell
Copy link
Contributor

fossell commented Oct 1, 2020

@ywangwof I assume that these changes are required because you are building UPP using the sorc/build_ncep_post.sh script on those platforms that uses the modulefiles, instead of building UPP using cmake. So you are not building within the SRW app, but you just want to make sure that your modulefiles point to the same NCEPLIBS that is used by SRW app and cmake build. Is that correct?

@fossell That is NOT right. I am building from the SRW app. My current version of the SRW app is dated on 2020-09-25 with hash #d8e9e31 and it is the latest one just checked out today. It is built using "src/build_all.sh" -> "src/build_post.sh" -> "EMC_post/compile" -> "EMC_post/sorc/build_ncep_post.sh". The "EMC_post" is dated on 2020-09-22 with hash #abb393e and it is checked out with "manage_externals/checkout_externals". It seems that I do not have the CMake configuration built in yet. Did I miss anything?

@ywangwof Ok, thanks for clarifying and I understand. I'm going to have to touch base with the SRW team about this. It seems that the version of the app you're using still leverages the compile build, and I was under the impression the app had moved to cmake for UPP already. But perhaps that's not the case. I'll get back to you with more info, but in the meantime I can merge these changes in this branch. And I will move content of this discussion to an issue I have open regarding updates to SRW for UPP if needed.

@fossell fossell merged commit 9d4eb19 into NOAA-EMC:release/public-v2 Oct 1, 2020
@fossell
Copy link
Contributor

fossell commented Oct 1, 2020

@ywangwof I confirmed that the SRW app has not yet merged the PR to make the transition to cmake. That will be forthcoming. But with that change there shouldn't be any impact for you, since you're already pointing SRW NCEPLIBS for your build. As long as those libraries/modules in that path in modulefiles are kept up to date with any changes from NCEPLIBS/release/public-v2, you shouldn't see any changes in UPP behavior when they make the build change If there are problems though, please us know!

EricJames-NOAA pushed a commit to EricJames-NOAA/UPP that referenced this pull request Dec 14, 2022
…ed for a hybrid GSI analysis (NOAA-EMC#194)

 add a variable HYBENSMEM_NMIN
 GSI will do hybrid analysis if $HYBENSMEM_NMIN or more ensembles are available
 This allow GSI to do hybrid analysis even we miss a few members of 80 GDAS ensembles.
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.

3 participants