Build ambertools 24

[mikemhenry]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Starting this one over to take in the changes made to the feedstock (so all the stuff that has been merged in and using the changes in #141

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[mikemhenry]

Forgot to remove the csh yum dep, getting a sha missmatch on other builds:

Downloading source to cache: AmberTools24_rc5_e4232d79e1.tar.bz2
Downloading https://ambermd.org/downloads/AmberTools24_rc5.tar.bz2
Success
Traceback (most recent call last):
  File "/Users/runner/miniforge3/bin/conda-build", line 11, in <module>
    sys.exit(execute())
             ^^^^^^^^^
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/cli/main_build.py", line 622, in execute
    api.build(
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/api.py", line 211, in build
    return build_tree(
           ^^^^^^^^^^^
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/build.py", line 3656, in build_tree
    packages_from_this = build(
                         ^^^^^^
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/build.py", line 2448, in build
    try_download(m, no_download_source=False, raise_error=True)
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/render.py", line 761, in try_download
    source.provide(metadata)
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/source.py", line 1041, in provide
    unpack(
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/source.py", line 173, in unpack
    src_path, unhashed_fn = download_to_cache(
                            ^^^^^^^^^^^^^^^^^^
  File "/Users/runner/miniforge3/lib/python3.12/site-packages/conda_build/source.py", line 129, in download_to_cache
    raise RuntimeError(
RuntimeError: SHA256 mismatch for AmberTools24_rc5.tar.bz2: obtained '52fb4fb3370a89b7ce738a2dc3e513c2fc1943fde4b4381846d9e75cc48d840f' != expected 'e4232d79e1eb69f679db75c2e6ac2906'

But when I download the tarball, I do get e4232d79e1eb69f679db75c2e6ac2906 and the hash that conda-forge reports isn't a valid hash since it is too long...

[mikemhenry]

@conda-forge-admin, please rerender

[dacase]

I'm not sure exactly how you obtained the sha in your recipe. When I run sha256sum on the tar file, I get this:

52fb4fb3370a89b7ce738a2dc3e513c2fc1943fde4b4381846d9e75cc48d840f

This matches the sha that conda forge reports above. And my results don't match your objection that the above sha256 hash is "too long".

[mikemhenry]

Sorry for the noise -- I was computing the md5sum by mistake locally 🫠

[xiki-tempula]

I think it is better to focus the effort on ambertools24, as we kind of want to use Gromacs 2025 which need CUDA>=12.

[mikemhenry]

@xiki-tempula Is CUDA support in ambertools important? Right now non-cuda builds for linux are working and the issue with the OSX builds is weird but should be able to be fixed.

[xiki-tempula]

Yes, CUDA support in AmberTools is quite important for us. We use this repository as a template to provision Amber by pointing the ambertools tar in meta.yaml to a local tar file that includes both Amber and AmberTools. We then build the AmberTools conda package with MPI and CUDA support and host it in our private conda channel. This setup allows our users to easily install the package and run pmemd.MPI.CUDA.

We truly appreciate your efforts in maintaining this repository and would be grateful for any support in ensuring CUDA compatibility.

[mikemhenry]

Okay! CUDA 11.8 is building okay, but newer versions of CUDA have this issue:

CMake Error at cmake/CudaConfig.cmake:75 (message):
  Error: Untested CUDA version.  AMBER currently requires CUDA version >= 7.5
  and < 12.5.

I can try to patch this out (like it was done in #148 ) to get CUDA 12.6 builds, but if you are okay with 11.8 builds then I might just not build for newer versions of CUDA since upstream doesn't support it.

[xiki-tempula]

That’s unfortunate that CUDA 12 isn’t supported yet, but it’s not a dealbreaker for us—GROMACS 2025 can wait. Our main priority right now is getting the osx-arm64 build fixed, as the issue (#143) has been quite frustrating for Mac users.

Additionally, we’re very interested in the new GAFF2 charge model, as it’s something we’ve been wanting to explore for a long time.

We really appreciate your efforts in maintaining these builds—thanks for your help!

[mikemhenry]

I am going to try and address that issue in this PR, thank you for reminding me of it! I can add that import test to make sure things are working

[xiki-tempula]

Thank you for looking into this! I had spent quite a bit of time trying to fix that issue but eventually gave up, as building the package locally seemed to resolve it. However, we can no longer do that due to the C++ compiler not found issue you've seen in the OSX-arm64 pipeline. I really appreciate your efforts in addressing this!

[dacase]

I'm pretty sure CUDA 12.6 will work, but I will ping Andy Goetz and others to confirm. I too have been building conda packages with CUDA 11.8 since that has been easier. I'll either experiment with 12.6 (or perhaps wait to see what happens with the conda-forge build.)

@mikemhenry Update: the QUICK people report good results up to and including CUDA 12.6.3. No one has yet tested CUDA 12.8. So I would recommend 12.6 if you have a need to go higher than 11.8 for some reason.

[mikemhenry]

@dacase Thank you! If you can confirm that CUDA 12.6 "works" I can then try and patch it so that it can build.

The osx_arm64 builds are failing now because I need to update a patch (or see if I can remove it as it might not be needed anymore)

I want to wait to push a fix for them until the 11.8 cuda builds finish to see if any changes need to be made to those.

[mikemhenry]

Okay we will see if the OSX packages build!

[mikemhenry]

Okay the osx-arm64 builds "build" but I do see warnings like this in the build log:

clang++ -ftree-vectorize -fPIC -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -fmessage-length=0 -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/ambertools-24.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -pthread -D_FORTIFY_SOURCE=2 -isystem $PREFIX/include -mmacosx-version-min=11.0 -mmacosx-version-min=11.0 -bundle -undefined dynamic_lookup -Wl,-rpath,@loader_path/../../../../.. -ftree-vectorize -fPIC -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -fmessage-length=0 -isystem $PREFIX/include -fdebug-prefix-map=$SRC_DIR=/usr/local/src/conda/ambertools-24.0 -fdebug-prefix-map=$PREFIX=/usr/local/src/conda-prefix -pthread -D_FORTIFY_SOURCE=2 -isystem $PREFIX/include -mmacosx-version-min=11.0 -mmacosx-version-min=11.0 $SRC_DIR/build_host_tools/build/AmberTools/src/pytraj/CMakeFiles/python-build/temp.macosx-11.0-arm64-cpython-310/pytraj/topology/topology.o -L$SRC_DIR/build_host_tools/build/AmberTools/src/cpptraj/src -lcpptraj -o $SRC_DIR/build_host_tools/build/AmberTools/src/pytraj/CMakeFiles/python-build/lib.macosx-11.0-arm64-cpython-310/pytraj/topology/topology.cpython-310-darwin.so -O0 -ggdb
ld: warning: ignoring file /Users/runner/miniforge3/conda-bld/ambertools_1739310605975/work/build_host_tools/build/AmberTools/src/cpptraj/src/libcpptraj.dylib, building for macOS-x86_64 but attempting to link with file built for macOS-arm64

So I get why it won't link a file built for macOS-x86_64 to a file built for macOS-arm64 -- the confusing part is the file in question:

/Users/runner/miniforge3/conda-bld/ambertools_1739310605975/work/build_host_tools/build/AmberTools/src/cpptraj/src/libcpptraj.dylib

Is in the build_host_tools folder, which is where I build the host tools that are needed to compile

if [[ "${build_platform}" != "${target_platform}" ]]; then
    # Build host tools first
    mkdir -p ${BUILD_PREFIX}/amber_host_tools
    mkdir -p build_host_tools
    cd build_host_tools
    CC=${CC_FOR_BUILD}
    CXX=${CXX_FOR_BUILD}
    cmake ${CMAKE_ARGS} ${SRC_DIR} ${CMAKE_FLAGS} \
        -DBUILD_HOST_TOOLS=TRUE \
        -DCOMPILER=MANUAL \
        -DCMAKE_INSTALL_PREFIX="${BUILD_PREFIX}/amber_host_tools"
    make
    make install

    CMAKE_FLAGS+=" -DUSE_HOST_TOOLS=TRUE"
    CMAKE_FLAGS+=" -DHOST_TOOLS_DIR=${BUILD_PREFIX}/amber_host_tools"
fi

I am going to dig in and see why it is trying to link a tool built -- looking at the build logs I don't see libcpptraj.dylib during that phase of the build

EDIT:

One thing I just noticed is that I didn't have a cd ../ to get out of the amber_host_tools dir, so while I make a new folder to build the actual package, it is nested inside that build dir and it could be confusing some of the tools

[mikemhenry]

Okay same problem, but I think the issue is with the FORTRAN compiler, I think I only am handling the C and CXX compilers correctly for the cross compilation

[mikemhenry]

Once I get the arch issues sorted out on #159, I will port the changes needed to this PR

[mikemhenry]

Going to start this one over -- easier than rebasing off the current main