conda-forge / gromacs-feedstock Goto Github PK

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

I cannot find gromacs package in the linux-aarch64 machine, so I ask for building gromacs of linux-aarch64 version

Installed packages

conda list

Environment info

conda info

     active environment : base
    active env location : /root/anaconda3
            shell level : 1
       user config file : /root/.condarc
 populated config files : /root/.condarc
          conda version : 23.9.0
    conda-build version : 3.27.0
         python version : 3.10.8.final.0
       virtual packages : __archspec=1=aarch64
                          __glibc=2.28=0
                          __linux=4.19.90=0
                          __unix=0=0
       base environment : /root/anaconda3  (writable)
      conda av data dir : /root/anaconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-aarch64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/bioconda/linux-aarch64
                          https://conda.anaconda.org/bioconda/noarch
                          https://repo.anaconda.com/pkgs/main/linux-aarch64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-aarch64
                          https://repo.anaconda.com/pkgs/r/noarch
                          file:///root/anaconda3/conda-bld/linux-aarch64
                          file:///root/anaconda3/conda-bld/noarch
          package cache : /root/anaconda3/pkgs
                          /root/.conda/pkgs
       envs directories : /root/anaconda3/envs
                          /root/.conda/envs
               platform : linux-aarch64
             user-agent : conda/23.9.0 requests/2.31.0 CPython/3.10.8 Linux/4.19.90-17.ky10.aarch64 kylin/V10 glibc/2.28 aau/0.4.3 c/IEPGaVJGgm5PUFrBB-oP4A s/6uIsSvbtUP-JN3aJbHLbrA e/RfUmb4UDd-T-JcVsa8qSEQ
                UID:GID : 0:0
             netrc file : None
           offline mode : False

Comment:

So we have MPI build, we have cuda build but we don't have the cuda MPI build. I wonder why do we not have this combination? Is it like we tried to build it but failed or it is just no one bothered to do this? Thanks.

Comment:

Given that apply has been supplying intel chips for many years. Might be good to have gromacs arm build for osx? Thanks.

Additional comment:

No response

Comment:

I've just remembered that we should only have the main branch on this feedstock repository. @mabraham, and @xiki-tempula, can I delete your two branches, and we'll try those as PR's from remote repositories again?

Additional comment:

No response

Comment:

Some of my CI runs are crashing with this spooky error

                 :-) GROMACS - gmx mdrun, 2023.2-conda_forge (-:

Executable:   /Users/runner/micromamba/envs/interchange-examples-env/bin.AVX2_256/gmx
Data prefix:  /Users/runner/micromamba/envs/interchange-examples-env
Working dir:  /private/var/folders/3s/vfzpb5r51gs6y328rmlgzm7c0000gn/T/tmpxj1jcgnp
Command line:
  gmx mdrun -s out.tpr -e out.edr -ntomp 1


-------------------------------------------------------
Program:     gmx mdrun, version 2023.2-conda_forge
Source file: src/gromacs/hardware/printhardware.cpp (line 108)

Fatal error:
The gmx mdrun executable was compiled to use the rdtscp CPU instruction.
However, this is not supported by the current hardware and continuing would
lead to a crash. Please rebuild GROMACS with the GMX_USE_RDTSCP=OFF CMake
option.

For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
-------------------------------------------------------

As far as I can tell, RDTSCP is something that is found on older x86 hardware (or see "very old machines" below). I have not seen this in Linux and it doesn't crash on all macOS builds. I think GitHub may be using old hardware for some macOS runners, but this seems exceedingly difficult to verify. This has been happening for the past two weeks or so and I have never seen it before. Searching the web does not bring up much, otherwise I wouldn't open it here.

I can find a brief mention of it

RDTSCP usage and reporting
GROMACS now defaults always on x86 to use the RDTSCP machine instruction for lower latency timing. Very old machines might need to configure with GMX_USE_RDTSCP=off. Non-x86 platforms are unaffected, except that they will no longer report that RDTSCP is disabled (because that is self-evident).

https://manual.gromacs.org/documentation/2023/release-notes/2021/major/portability.html#rdtscp-usage-and-reporting

I have no idea if "lower latency timing" relates to performance in runs or something else in some other context, like debugging or some low-level operation. I'd be happy to submit a PR that toggles this flag, but I am clueless as to whether or not that's a good idea.

(@junghans how does the conda-forge votca handle this? Does it just use an arbitrary compiler and not run the check_compiler() function?)

VOTCA's CMake runs check_cxx_compiler_flag(), but we haven't seen any problems with gromacs yet.

Sorry. I was vague and inaccurate. Historically, GROMACS recommended that client software run gromacs_check_compiler(CXX) as in https://gitlab.com/gromacs/gromacs/-/blob/main/share/template/CMakeLists.txt.template, but this generally hasn't worked when gromacs was installed with conda (because the embedded toolchain paths are as seen during the isolated conda-build).

I'm assuming VOTCA doesn't use the gromacs_check_compiler(), then. Do you do anything else to ensure a compatible toolchain? Maybe it just tend to work fine with default conda build tools?

Originally posted by @eirrgang in #10 (comment)