add BLAS test #268
add BLAS test #268
Conversation
|
Sorry for the late checking @smoors . I tried running these tests today but I am getting empty job script files when I try to run. Now I am trying to figure out why. |
|
|
||
| BLAS_MODULES = { | ||
| '2023a': { | ||
| 'FlexiBLAS': 'FlexiBLAS/3.3.1-GCC-12.3.0', |
There was a problem hiding this comment.
What we could do is use the find_modules to search for FlexiBLAS, and then based on the toolchain, for each FlexiBLAS that is found, we can find the compatible BLIS modules (i.e. the one that is built with the same toolchain). Based on that, you can then create a parameter space of FlexiBLAS + BLIS modules that should be loaded.
|
@satishskamath can you try again to see if your issue is fixed with the latest update? |
|
@smoors I'm not sure how you got this to work for EESSI - it shouldn't. I'm getting: And this is totally expected if you 'just' compile something on top of EESSI. The reason is that we don't set Everything in EESSI is With that, in the staging dir, I do: Tada, it now finds Now, I don't know how to properly implement this in a generalized test (it's clear that this is our first compiled test - we're hitting all kinds of stuff). Should we start defining programming environments, that then load this? Should we make some clever code that loads this module if EESSI is being used? If so, how do we determine the correct version: your FlexiBLAS is at GCC level, you need knowledge on the toolchain hierarchy to know which Honestly, I'm not sure how to resolve this, we need to think about it... I guess one option would be to just pass the right arguments for |
|
On the upside, on our local module stack, this works out of the box: That first one ( |
Sorry for the confusion, it does run. The earlier error happened because I ran from a ReFrame from the 2024 stack and we have a hierarchical setup here. |
|
Discussed in the test suite meeting. We could probably define the mapping from toolchain to buildenv module in a map that is defined as part of
|
|
@casparvl my bad, you're absolutely right. i did initially test the EESSI stack with the it's unfortunate because that means we cannot avoid a mapping between the BLAS modules and
that's a good suggestion, something along these lines should work, i'll have to think about this some more.. another solution would be to use EasyBuild as a library to get the toolchain mappings, i.e. via |
|
Just to mention, in EESSI/software-layer-scripts#42 I do something to determine supported toolchains in the Another option is to have Final option is to make your own |
|
Discussed in meeting, we'll go for EasyBuild as a library. Advantage is that users can even upgrade EasyBuild in place to make it aware of newer toolchains, and we can print an informative message if the toolchain is too new to be known to the currently installed EB version. If, in the future, we find that it's inconvenient to have EB as dependency, we can always decide to remove it later and just hard-code the hierarchy in |
|
implemented by first getting the buildenv modules available in the system, and then calculating the toolchain hierarchy for each of them. |
this adds the BLAS test included in the BLIS sources, using a modified/simplified Makefile so it works with FlexiBLAS.
supported BLAS libs: OpenBLAS, BLIS, AOCL-BLAS, imkl
ready for testing and review.
notes:
executables are compiled in every run-only test job, no separate compile-only test jobs:
the downside is that the executables have to be built for every test case, while with a compile-only test job this has to be done only once for each architecture. i'm fine with adding a compile-only job if you prefer.
no programming environments (environs) are used:
for BLIS and AOCL-BLAS, no loop-specific
BLIS_**_NTenvironment variables are set, only the genericOMP_NUM_THREADS.update 2025-07-05:
split_module()(would be nice if EasyBuild enforced this).8_corescale to accomodate nodes with high cpu counts.