-
Notifications
You must be signed in to change notification settings - Fork 702
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
{chem}[foss/2021a,intel/2021a] DIRAC v22.0 #15008
Conversation
Dear @boegel , thanks for your kind invitation to propose this tiny contribution to EasyBuild. Is there any way by which I can activate the automatic tests to be sure there are no bugs in these *eb files? Thank you in advance! |
@agustinaucar Thanks a lot for your contribution! If you push additional updates in this PR, we'll need to approve the running of the test suite again, but only for this first PR. Are you up for submitting a test report to show that these easyconfigs work for you? |
Hi @boegel , thank you! I was trying to submit a test report using eb --from-pr 15008 --upload-test-report --force --robot --github-user agustinaucar but it seems I'm doing something wrong. I obtain: $ eb --from-pr 15008 --upload-test-report --force --robot --github-user agustinaucar WARNING: Deprecated functionality, will no longer work in v5.0: Support for Lmod version < 7.0.0 is deprecated, found version 6.6; see http://easybuild.readthedocs.org/en/latest/Deprecated-functionality.html for more information == found valid index for /usr/local/easybuild/easyconfigs, so using it... |
Dear @boegel, Is there something else I can do regarding the inclusion of this new DIRAC version into EB? Thank you for your time and comments! |
Quick check, does eb --check-github complete successfully? It should since you submitted this PR with the --new-pr argument, but it's worth checking again. |
BTW, github had some problems a while ago, and you may have been hit by that. Can you (if check-github works) just redo the upload run? |
Dear @akesandgren, thanks for your very quick response!
Checking status of GitHub integration... Making sure we're online...OK
One or more checks FAILed, GitHub configuration not fully complete! Status of GitHub integration:
|
Ah, if upload-test-report fails you need to follow the instructions for "Installing a GitHub token" on the page it refers to. |
@akesandgren : I used the git strategy to send the PR (https://docs.easybuild.io/en/latest/Contributing.html?highlight=contribute#contributing-requests), not the |
Ah, using --new-pr (after setting up the github integration parts) is way easier if you think you'll be doing this more than once. |
But I'll submit a test report to start with. |
Thank you very much @akesandgren ! I'm trying following the way you suggested, but it seems that I now have some troubles with gist: ~$ eb --check-github WARNING: Deprecated functionality, will no longer work in v5.0: Support for Lmod version < 7.0.0 is deprecated, found version 6.6; see http://easybuild.readthedocs.org/en/latest/Deprecated-functionality.html for more information == 2022-03-21 09:30:32,131 build_log.py:265 INFO Checking status of GitHub integration... == 2022-03-21 09:30:32,131 build_log.py:265 INFO Making sure we're online... OK == 2022-03-21 09:30:32,234 build_log.py:265 INFO * GitHub user...
One or more checks FAILed, GitHub configuration not fully complete! == 2022-03-21 09:30:57,000 build_log.py:265 INFO Status of GitHub integration:
|
Test report by @akesandgren |
I do use
|
|
||
separate_build_dir = True | ||
|
||
configopts = ' -DCMAKE_Fortran_COMPILER=mpif90 ' |
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 should not be needed, with "usempi" true, FC = mpif90 (or mpiifort in the case of the intel toolchain)
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.
Hi @akesandgren. I just realized that when we set "usempi" to true and we use the intel toolchain, FC is set to be mpif90 (and we have mpicc and mpicxx for C and C++ compilers, respectively).
I mean, the mpiifort (and equivalents for c and cxx) are expected to be recognized automatically, but they are not. Is it probably due to a bug in the code?
Maybe the bug is in this file: https://gitlab.com/dirac/dirac/-/blob/master/cmake/extensions.py
All the cmake lines are here: https://gitlab.com/dirac/dirac/-/tree/master/cmake
Do you suggest to restore:
configopts = ' -DCMAKE_Fortran_COMPILER=mpiifort '
configopts += '-DCMAKE_C_COMPILER=mpiicc '
configopts += '-DCMAKE_CXX_COMPILER=mpiicpc '
in the intel's *eb file? If it is something simple (I am not a CMake expert), perhaps it is better to solve the bug directly in the code.
CC: @boegel
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.
Yeah, try doing that for the intel version and check if it does the right thing all the way through.
Not quite sure what that extensions.py code is used for...
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.
Tks Åke! It is ok now. PR at #15202
Test report by @agustinaucar |
Thank you @akesandgren for your patiente and for all your help! |
configopts += '-DENABLE_64BIT_INTEGERS=False ' | ||
configopts += '-DENABLE_EXATENSOR=off ' | ||
configopts += '-DENABLE_PCMSOLVER=off ' | ||
configopts += '-G"Unix Makefiles" ' |
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.
Not needed usually, and if the DIRAC CMake config wants to use something else by default we should probably allow it, and if necessary add any required buildsdependencies, like Ninja possibly.
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'm not sure about this. Usually, the DIRAC community employes the code without need of using the "PCMSolver" and/or the "EXATensor" modules. We also use the 32bit version compilation in most of the cases.
But there are particular situations where 64bits compilations are needed (and only for them it is reccommended to compile the code in this way), and there are also some research lines where EXATensor and/or PCMSolver are needed.
So, I left these 3 lines so that we can do other builds when needed.
Concerning the last line:
configopts += '-G"Unix Makefiles" '
,
I am not sure if we need or not to leave it.
Thank you @akesandgren !
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 is what you need, and only this for the foss based one.
# Must explicitly turn MKL off
configopts = '-DMKL_FLAG=off '
configopts += '-DMATH_LIBS="$LIBLAPACK" '
configopts += '-DENABLE_MPI=True '
configopts += '-DENABLE_EXATENSOR=off '
configopts += '-DENABLE_PCMSOLVER=off '
unless we want to explicitly enable openmp, in which case you will need
-DENABLE_OPENMP=True
and in that case one should also add 'openmp': True to the toolchainopts.
Test report by @agustinaucar |
configopts += '-DENABLE_64BIT_INTEGERS=False ' | ||
configopts += '-DENABLE_EXATENSOR=off ' | ||
configopts += '-DENABLE_PCMSOLVER=off ' | ||
configopts += '-G"Unix Makefiles" ' |
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 is what you need, and only this for the foss based one.
# Must explicitly turn MKL off
configopts = '-DMKL_FLAG=off '
configopts += '-DMATH_LIBS="$LIBLAPACK" '
configopts += '-DENABLE_MPI=True '
configopts += '-DENABLE_EXATENSOR=off '
configopts += '-DENABLE_PCMSOLVER=off '
unless we want to explicitly enable openmp, in which case you will need
-DENABLE_OPENMP=True
and in that case one should also add 'openmp': True to the toolchainopts.
OK tks. It is done. Now I'm testing again. |
Test report by @agustinaucar |
Only some DIRAC users need to compile the code employing OpenMP, so I think it is not needed for a "usual" compilation. My suggestion is that who needs it can build its own compilation. |
Test report by @akesandgren |
@boegelbot Please test @ generoso |
@akesandgren: Request for testing this PR well received on login1 PR test command '
Test results coming soon (I hope)... - notification for comment with ID 1076013919 processed Message to humans: this is just bookkeeping information for me, |
Test report by @boegelbot |
Hi @akesandgren and @boegel, thank you to both of you for all your help. Do you think DIRAC-22.0 could be available in the next EasyBuild release? |
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.
LGTM
Going in, thanks @agustinaucar! |
Since it is now merged it will be in the next release. |
Thank you very much Ake! Have a nice weekend.
El vie., 25 de marzo de 2022 16:37, Åke Sandgren ***@***.***>
escribió:
… Since it is now merged it will be in the next release.
—
Reply to this email directly, view it on GitHub
<#15008 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXZ6WT56JY77V6HVSNLUEHLVBXMUTANCNFSM5OUFHEOQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Test report by @agustinaucar |
These are 2 new proposed compilations of the newest release of the DIRAC code (http://www.diracprogram.org/).