Update the simfactory entry for Expanse

Issue #2561 resolved
Gabriele Bozzola created an issue

I submitted a PR to the simfactory repo to fix a problem with Python and running rpar parameter files.

Comments (8)

  1. Roland Haas

    Can you add the link to the pull request? Since you are the maintainer of the entry, you should also be able just to push the updated entry. Do you have commit rights?

  2. Roland Haas

    I just invited your University of Arizona email to Simfactoy’s Bitbucket repo so that you can push. Having said that: the commit seems to indicate that “numpy” fails, so you are using numpy in your rpar files?

    The pull request also adds a line

    OPENBLAS_DIR = /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen2/gcc-10.2.0/openblas-0.3.10-3lzjcwjsyu3qmott7k3k52mtzljioax3/
    

    to the option list which seems to go beyond the stated goal of fixing some issue with Python, at least at first glance. Adding it (assuming that this is the correct path for the loaded module) is the correct thing to do, but ideally should be done in a separate commit (no stealth changes with subject lines “whiterabbit.exe” please).

  3. Gabriele Bozzola reporter

    Hi Roland, I didn’t act quickly enough and the invitation expired. Can you send another one?

    Having said that: the commit seems to indicate that “numpy” fails, so you are using numpy in your rpar files?

    Yes, that is correct.

    The pull request also adds a line

    OPENBLAS_DIR = /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen2/gcc-10.2.0/openblas-0.3.10-3lzjcwjsyu3qmott7k3k52mtzljioax3/
    

    to the option list which seems to go beyond the stated goal of fixing some issue with Python, at least at first glance. Adding it (assuming that this is the correct path for the loaded module) is the correct thing to do, but ideally should be done in a separate commit (no stealth changes with subject lines “whiterabbit.exe” please).

    NumPy is compiled against OpenBlas, which has to be loaded to correctly use the package. The line ensures that OpenBlas is consistent within the environment (ie, NumPy and Einstein Toolkit use the same OpenBlas, as it is provided by the module). I agree that this a little bit beyond the scope of the commit, also because there is no need for NumPy and Einstein Toolkit to use the same OpenBlas.

    In general, following the discussion in the mailing list (http://lists.einsteintoolkit.org/pipermail/users/2021-August/008179.html), it is likely that this entry for Expanse is not the best one. I am waiting to see if the admins do anything about their ucx/verbs stack.

  4. Log in to comment