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

Ufs hera update #192

Merged
merged 48 commits into from
Dec 12, 2022
Merged

Ufs hera update #192

merged 48 commits into from
Dec 12, 2022

Conversation

AlexanderRichert-NOAA
Copy link
Collaborator

This pull request contains the changes needed to build the UFS WM on Hera, including compiling static libraries with the same versions as hpc-stack. Most changes are related to enabling static libraries throughout the whole stack.

Copy link
Collaborator

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

I am concerned about some of the changes in this PR. They look like a lot of duct-tape solutions for underlying problems that should be fixed in other places. I am worried that we'll not be able to get this merged into the authoritative/upstream repositories, which is I think what we want. For the bundle packages (which we will never send upstream), we'll need to come up with a consistent solution, I am open for discussion.

But, in general, what forces us to use static libraries throughout? Can't we use dynamic netcdf libraries. Even stone-age cray systems nowadays support dynamic libraries just fine.

var/spack/repos/builtin/packages/esmf/package.py Outdated Show resolved Hide resolved
var/spack/repos/builtin/packages/esmf/package.py Outdated Show resolved Hide resolved
var/spack/repos/builtin/packages/esmf/package.py Outdated Show resolved Hide resolved
var/spack/repos/builtin/packages/netcdf-c/package.py Outdated Show resolved Hide resolved
var/spack/repos/builtin/packages/netcdf-fortran/package.py Outdated Show resolved Hide resolved
var/spack/repos/jcsda-emc/packages/mapl/package.py Outdated Show resolved Hide resolved
@AlexanderRichert-NOAA
Copy link
Collaborator Author

But, in general, what forces us to use static libraries throughout? Can't we use dynamic netcdf libraries. Even stone-age cray systems nowadays support dynamic libraries just fine.

The motivation for static libraries is mainly consistency with hpc-stack. Also, as far as I know, static libraries are still required for operations on WCOSS2.

@AlexanderRichert-NOAA
Copy link
Collaborator Author

I've confirmed with EMC that static libraries are required. I don't think it should be too difficult to make this happen, but it'll take some more elbow grease to figure out a smoother way to make some of the changes (namely linker flag-related package tweaks). Depending on what's involved in resolving the -lESMF and MAPL/pfio exe issues (which I think are my lingering two "hack-y" fixes outside of linker flags/enabling static builds), I may push for quick-and-dirty fixes in the short term to let UFS developers at least get running with spack stack, with the expectation that we revert those changes once permanent solutions are found.

@climbfuji
Copy link
Collaborator

I've confirmed with EMC that static libraries are required. I don't think it should be too difficult to make this happen, but it'll take some more elbow grease to figure out a smoother way to make some of the changes (namely linker flag-related package tweaks). Depending on what's involved in resolving the -lESMF and MAPL/pfio exe issues (which I think are my lingering two "hack-y" fixes outside of linker flags/enabling static builds), I may push for quick-and-dirty fixes in the short term to let UFS developers at least get running with spack stack, with the expectation that we revert those changes once permanent solutions are found.

Thanks, yes, that sounds good.

Copy link
Collaborator

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

I think that the entire, messy +shared ~shared logic can be simplified, but we can do this in a follow-up PR. There are a few things that need to be addressed before you update the submodule pointer in your spack-stack PR and we rerun the tests.

@AlexanderRichert-NOAA
Copy link
Collaborator Author

@climbfuji Let me know what you think re: parallelio and leaving it static-only for now to not break existing functionality (just created ufs-community/ufs-weather-model#1512). In any case I'll need help setting the spack-stack module. The goal is to not change any existing behavior (in terms of existing default "shared" libs etc.), so fingers crossed the CI tests shouldn't be affected...

Copy link
Collaborator

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

I am getting failures with this PR on my mac and on Cheyenne.

@climbfuji
Copy link
Collaborator

I saw you made updates after I started to test this PR, therefore the errors I've been seeing didn't make sense. Let me try to pull in your latest two bug fix commits and see what happens.

Copy link
Collaborator

@mathomp4 mathomp4 left a comment

Choose a reason for hiding this comment

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

I think this is good, though I am concerned we might have a lot of code in builtin that the mother spack repo will never take.

@climbfuji
Copy link
Collaborator

I think this is good, though I am concerned we might have a lot of code in builtin that the mother spack repo will never take.

That is my concern, too. But the burden will be on @AlexanderRichert-NOAA (sorry, Alex) to propose those changes to the authoritative repo. It is quite likely that they don't reject the changes altogether, but that they come up with alternative solutions, which we then have to bring back to our fork. But in general this should help to improve our build system.

@climbfuji climbfuji merged commit 377817d into JCSDA:jcsda_emc_spack_stack Dec 12, 2022
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