-
Notifications
You must be signed in to change notification settings - Fork 0
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
Mpi omp support #14
Mpi omp support #14
Conversation
while it works with the tests, a real application still triggered it. This reverts commit 150dc37.
…Fixed coding style.
This patch is not 'as big' as it appears to be - because of adding parameters to BuildConfig, they had to be added to a lot of files and examples. Additionally, I addressed coding style issues as suggested by Matthew recently (max 80 characters/line). Note that the MPI based compiler classes are not proper wrapper yet, they will be re-implemented in the next PR. |
Quick explanation: |
source/fab/tools/tool_box.py
Outdated
@@ -59,6 +61,9 @@ def get_tool(self, category: Category) -> Tool: | |||
return self._all_tools[category] | |||
|
|||
# No tool was specified for this category, get the default tool | |||
# from the ToolRepository: | |||
# from the ToolRepository, and at it, so we don't need to look |
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.
and at it
do you mean "and add it"?
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.
Indeed.
assert mpi_gfortran.name == "mpif90-gfortran" | ||
assert isinstance(mpi_gfortran, FortranCompiler) | ||
assert mpi_gfortran.category == Category.FORTRAN_COMPILER | ||
assert mpi_gfortran.mpi | ||
|
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 we need a test of get_version()
on the mpi compilers, to make sure we fixed the issue Jason found
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've parameterised all the valid compiler version tests to test both the compiler and mpi wrapper.
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.
In hindsight a stupid idea of me. The next PR (compiler wrapper) refactors the MPI* wrapper and creates their own file with their own tests, so I had to remove the parameterisation in the next PR again. The 'future' compiler wrapper do explicitly test that the wrapper and the wrapper compiler report the same version :(
# Notice that "-J/b" has been removed | ||
fc.run.assert_called_with(cwd=PosixPath('.'), | ||
additional_parameters=['-c', "-O3", | ||
'-J', '/module_out', | ||
'a.f90', '-o', 'a.o']) | ||
with pytest.warns(UserWarning, |
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'd prefer this to be a separate test, but it at least needs a comment. Currently you have to play spot-the-difference with the code above 😀
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.
Done ... I think.
@@ -164,9 +184,20 @@ def build_output(self) -> Path: | |||
''' | |||
return self.project_workspace / BUILD_OUTPUT | |||
|
|||
@property | |||
def mpi(self) -> bool: |
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.
Are these properties (BuildConfig.mpi
and BuildConfig.openmp
) used in you later tickets? Right now I can't see if they do anything. Couldn't I create a BuildConfig(mpi=False)
and still use it with mpi?
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.
Good catch. MPI was used in compile_c, but not compile_fortran (and as previously discussed, we don't raise an exception if you request MPI and a non-MPI compiler is already loaded, based on the idea that the user knows what they are doing). I am thinking more and more that we should raise an exception in this case :(
Openmp is used in both compile_c and ..._fortran
# the key being tool.suite != suite --> all tools with the right | ||
# suite use False as key, all other tools True. Since False < True | ||
# this results in all suite tools to be at the front of the list | ||
self[category] = sorted(self[category], |
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.
Does this assume add_tool
is never called after set_default_compiler_suite
? That might be fine, I can't tell
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 really. ATM I use this (in the NCI setup) to first pick our default suite (intel-classic), then add additional compilers (tau-wrapper around ifort) to the repository. This way the default will still remain the plain ifort (or mpi wrapper around ifort), while the tau ones (which are all of the same suite 'intel-classic') are available if a user wants to pick them, but they will not be picked by default.
Actually, now that I think about it, the order doesn't matter. Fab will first add the 'standard' compiler (e.g. ifort, mpif90-ifort), and whenever the default is changed, a stable-sort is called, so ifort/mpif90-ifort will be before any user added tool.
I hope I've addressed all issues. Ready for next review. |
Adds support for specifying MPI and OpenMP in the config file.