-
Notifications
You must be signed in to change notification settings - Fork 14
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
Various fixes for single-precision and switch to new FIELD_API #4
Conversation
string(FIND ${parent_path} "../" result_var) | ||
|
||
# If field_api is found but was not cloned by ecWAM, clone_field_api is set to FALSE | ||
string(COMPARE EQUAL ${result_var} "-1" clone_field_api) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we build ecWAM and run FetchContent
on FIELD_API, the cache variable field_api_FOUND
is set to TRUE. If we then run make clean
and re-configure the build without deleting the CMake cache, field_api_FOUND
will still be true but the FIELD_API builddir will be empty and the build will fail at compile-time when trying to use libfield_api
.
If on the other hand field_api_FOUND
is TRUE not because ecWAM cloned FIELD_API but because it is coming from a bundle or system installation, then the above mechanism ensures we don't run FetchContent
on FIELD_API.
FetchContent_Declare( | ||
field_api | ||
GIT_REPOSITORY [email protected]:ecmwf-ifs/field_api.git | ||
GIT_TAG naan-ecbuild |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be replaced by a tag once the new FIELD_API is open-sourced and PR #2 is approved. I will leave it as a draft-PR until then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as the CMake configuration is concerned I am happy with this.
The DEL1 change means a non-bit reproducible change. This probably invalidates existing hashes in tests.
package/bundle/bundle.yml
Outdated
- ecwam : | ||
dir : $PWD | ||
version : main | ||
require : fiat | ||
|
||
options : | ||
|
||
- single-precision : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- single-precision : | |
- with-single-precision : |
string(COMPARE EQUAL ${result_var} "-1" clone_field_api) | ||
endif() | ||
|
||
if( ${clone_field_api} ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if( ${clone_field_api} ) | |
if( clone_field_api ) |
85f8315
to
961d8d9
Compare
field_api | ||
GIT_REPOSITORY [email protected]:ecmwf-ifs/field_api.git | ||
GIT_TAG naan-ecbuild | ||
OVERRIDE_FIND_PACKAGE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This requires CMake version 3.24 i.e. cmake_minimum_required(VERSION 3.24)
. I guess this is fine, but I strongly recommend to adapt the CMake file. The error you get with 3.22 is extremely unclear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for pointing this out! FIELD_API itself requires CMake 3.25 for fixes to the cmake find_package(OpenACC)
, and given that this PR makes ecWAM hard reliant on FIELD_API, it makes sense to update the minimum CMake version in ecWAM to 3.25 too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the dependency on 3.25 is only due to the OpenACC fixes, I'd argue it would be better to simply add the following workaround and make that a less strict requirement:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OVERRIDE_FIND_PACKAGE
already needs CMake 3.24 as Lukas pointed out. When reconfiguring after a make clean
, OVERRIDE_FIND_PACKAGE
makes the FetchContent
mechanism a bit more robust. So the decision would be between 3.24 and 3.25. In that context, I think 3.25 isn't too restrictive. What are your thoughts on this @wdeconinck ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 3.24 is my current preference, using @reuterbal 's suggestion to adapt FIELD_API, as Leonardo currently uses cmake 3.24 as latest version. Both LUMI and our own HPC have 3.25 however.
9bfcd8a
to
ed50952
Compare
Hi @wdeconinck. Now that FIELD_API has been open-sourced, this is ready for review. I've removed the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FIELD API data structure changes look good to me and are consistent with the recent IFS update and the proposed release v0.2.1
(sync'd with Meteo-France recently). The cmake-fetch_content mechanism also looks sound to me, although wiser heads can probably judge this better. 😉
GTG from me, and very nicely done @awnawab 🎉 😄 👍 🙏
FetchContent_Declare( | ||
field_api | ||
GIT_REPOSITORY https://github.com/ecmwf-ifs/field_api.git | ||
GIT_TAG v0.2.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[no action] Eventually we might want a mechanism to define this in the top-level CMakeLists.txt, but not needed for this PR, I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This addressed all my previous concerns and recommendations.
Very nice work @awnawab . Thank you!
I have merged your other PR.
You can rebase and merge when you're ready.
5ebd063
to
313d1db
Compare
5efa295
to
6ee971c
Compare
6ee971c
to
86dd918
Compare
All green now :) You can merge when you're ready. |
This PR adds various fixes required to validate successfully in single-precision for Intel and nvhpc builds. Due to the need to run NEMO in double-precision even if ecWAM is single-precision, a mixed precision FIELD_API build was needed. Rather than adding this functionality to the old (private) FIELD_API on bitbucket, ecWAM has been switched over to the new FIELD_API which already supports mixed-precision builds. As this repo will soon be open sourced (see PR #1), I have made FIELD_API a hard dependency of ecWAM.