Package license: GPL-3.0-or-later AND LGPL-3.0-or-later AND BSD-3-Clause AND MIT
Summary: AmberTools is a set of programs for biomolecular simulation and analysis
AmberTools is a set of programs for biomolecular simulation and analysis.
They are designed to work well with each other, and with the "regular" Amber
suite of programs. You can perform many simulation tasks with AmberTools,
and you can do more extensive simulations with the combination of AmberTools
and Amber itself.
Once the conda-forge channel has been enabled, ambertools can be installed with conda:
conda install ambertools
or with mamba:
mamba install ambertools
It is possible to list all of the versions of ambertools available on your platform with conda:
conda search ambertools --channel conda-forge
or with mamba:
mamba search ambertools --channel conda-forge
Alternatively, mamba repoquery may provide more information:
# Search all versions available on your platform:
mamba repoquery search ambertools --channel conda-forge
# List packages depending on `ambertools`:
mamba repoquery whoneeds ambertools --channel conda-forge
# List dependencies of `ambertools`:
mamba repoquery depends ambertools --channel conda-forge
About conda-forge
conda-forge is a community-led conda channel of installable packages.
In order to provide high-quality builds, the process has been automated into the
conda-forge GitHub organization. The conda-forge organization contains one repository
for each of the installable packages. Such a repository is known as a feedstock.
A feedstock is made up of a conda recipe (the instructions on what and how to build
the package) and the necessary configurations for automatic building using freely
available continuous integration services. Thanks to the awesome service provided by
Azure, GitHub,
CircleCI, AppVeyor,
Drone, and TravisCI
it is possible to build and upload installable packages to the
conda-forgeanaconda.org
channel for Linux, Windows and OSX respectively.
To manage the continuous integration and simplify feedstock maintenance
conda-smithy has been developed.
Using the conda-forge.yml within this repository, it is possible to re-render all of
this feedstock's supporting files (e.g. the CI configuration files) with conda smithy rerender.
feedstock - the conda recipe (raw material), supporting scripts and CI configuration.
conda-smithy - the tool which helps orchestrate the feedstock.
Its primary use is in the construction of the CI .yml files
and simplify the management of many feedstocks.
conda-forge - the place where the feedstock and smithy live and work to
produce the finished article (built conda distributions)
Updating ambertools-feedstock
If you would like to improve the ambertools recipe or build a new
package version, please fork this repository and submit a PR. Upon submission,
your changes will be run on the appropriate platforms to give the reviewer an
opportunity to confirm that the changes result in a successful build. Once
merged, the recipe will be re-built and uploaded automatically to the
conda-forge channel, whereupon the built conda packages will be available for
everybody to install and use from the conda-forge channel.
Note that all branches in the conda-forge/ambertools-feedstock are
immediately built and any created packages are uploaded, so PRs should be based
on branches in forks and branches in the main repository should only be used to
build distinct package versions.
In order to produce a uniquely identifiable distribution:
If the version of a package is not being increased, please add or increase
the build/number.
If the version of a package is being increased, please remember to return
the build/number
back to 0.
Note that the PPC builds time out very often so it's tricky to get them uploaded. Many retries needed. If you don't see a particular package online, check the CI report for that version.
AmberTools 24 supports QM/MM calculation with the external packages dftbplus, xtb, deepmd-kit. All of them are available on the conda-forge. I am wondering if ambertools on conda-forge could support them, so users can easily install and use these features.
My concerns:
The deepmd-kit package requires tensorflow (and will require pytorch in the future version), which is too heavy for users. Alternatively, we may have both builds that enable and disable the features, like MPI.
The xtb package on conda-forge doesn't contain Fortran modules. I haven't made it work: conda-forge/xtb-feedstock#34
AmberTools installs and includes a packmol binary (an old one) which will overwrite the packmol binary installed from the actual packmol package. So you'll see something like the following:
(test-packmol) swails@Batman ~ $ conda list | grep -e ambertools -e packmol
# packages in environment at /scratch2/anaconda3/envs/test-packmol:
ambertools 20.15 pypi_0 pypi
packmol 20.2.2 h92ddd45_0 conda-forge
packmol-memgen 1.1.0rc0 pypi_0 pypi
(test-packmol) swails@Batman ~ $ packmol -v
################################################################################
PACKMOL - Packing optimization for the automated generation of
starting configurations for molecular dynamics simulations.
Included as part of Packmol Memgen
Version 18.169
################################################################################
Packmol must be run with: packmol < inputfile.inp
Userguide at: www.ime.unicamp.br/~martinez/packmol
Reading input file... (Control-C aborts)
^C
As you can see, conda thinks it installed packmol 20.2.2, but the ambertools package really silently overwrote it with its own copy.
Just like we're switching the ambertools package to depend on parmed (instead of vendoring), we should do the same to packmol, especially if this is going to be an indirect dependency (which it is likely to be given its relationship to openff).
Solution to issue cannot be found in the documentation.
I checked the documentation.
Issue
Existing AmberTools 23 binaries (or at least antechamber) crash on macOS 13 where they would fail on macOS 12. This was discovered when GitHub Actions recently bumped macos-latest from using 12 (x64) to 14 (M1) nudging some of us to 13 (the newest x86 runner). @IAlibay has found this is limited to the 23/13 combination; older macOS and older AmberTools don't crash like this. Unfortunately we (or at least my projects) must use 23 because sticking with x86 and Python 3.10 is not workable.
Run antechamber -i datafiles/CN.sdf -fi sdf -c bcc -at gaff2 -o test.mol2 -fo mol2
antechamber -i datafiles/CN.sdf -fi sdf -c bcc -at gaff[2](https://github.com/IAlibay/partial_charge_experiments/actions/runs/8846838752/job/24293490978#step:4:2) -o test.mol2 -fo mol2
shell: /bin/bash -l {0}
env:
MAMBA_ROOT_PREFIX: /Users/runner/micromamba
MAMBA_EXE: /Users/runner/micromamba-bin/micromamba
CONDARC: /Users/runner/work/_temp/setup-micromamba/.condarc
Welcome to antechamber 22.0: molecular input file processor.
Info: acdoctor mode is on: check and diagnose problems in the input file.
Info: The atom type is set to gaff2; the options available to the -at flag are
gaff, gaff2, amber, bcc, and sybyl.
-- Check Format for sdf File --
Status: pass
-- Check Unusual Elements --
Status: pass
-- Check Open Valences --
Warning: This molecule has no hydrogens nor halogens.
It is quite possible that there are unfilled valences.
-- Check Geometry --
for those bonded
for those not bonded
Status: pass
-- Check Weird Bonds --
Status: pass
-- Check Number of Units --
Status: pass
acdoctor mode has completed checking the input file.
Info: Total number of electrons: 0; net charge: 0
Running: /Users/runner/micromamba/envs/test_env/bin/sqm -O -i sqm.in -o sqm.out
/Users/runner/micromamba/envs/test_env/bin/wrapped_progs/antechamber: Fatal Error!
Cannot properly run "/Users/runner/micromamba/envs/test_env/bin/sqm -O -i sqm.in -o sqm.out".
Error: Process completed with exit code 1.
Note: This is specific to macOS. Linux platforms don't run into this issue, and Windows isn't among our needs here.
Wild idea, but how much of AmberTools depends on compiling FORTRAN code? For context, our OpenFF stack and Psi4 have conflicts that seem to relate to libgfortran, and I'm not sure if the parts of AmberTools we need (primarily antechamber) depend on it. This has me wondering how feasible a stripped-down build would be, one without compiled FORTRAN code, and only for macOS.
The release of AmberTools22 should be ready later this month (April, 2022). We have release candidates ready, but I'd like to find out what problems (if any) we will find in updating the current conda packages. Here is the updated URL
In the ideal world, one could substitute the new URL for the existing one in the meta.yaml file. I don't see any obvious problems in build.sh, but the code changes are pretty big, so something is likely to break....For sure, the three patch files invoked after downloading the source are unlikely to apply cleanly.
Unfortunately, I am not much of a conda or conda-forge person. I edited build.sh to skip the update_amber step, and tried conda build recipe. Pretty early on I encountered a version problem with cpptraj:
+ rm /Users/case/conda-bld/ambertools_1649863164081/work/AmberTools/src/cpptraj/src/xdrfile/version
rm: /Users/case/conda-bld/ambertools_1649863164081/work/AmberTools/src/cpptraj/src/xdrfile/version: No such file or directory
I could try to track this down, but it seems likely that someone (@jaimergp@simonbray ?) would be much more likely to know what to do here, and in whatever pops up next. But let me know how I can help, if needed.
Solution to issue cannot be found in the documentation.
I checked the documentation.
Issue
If I tried to install pytraj through the ambertools from conda-forge I will get the error
In [1]: import pytraj
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
Cell In[1], line 1
----> 1 import pytraj
File ~/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/__init__.py:24
22 from .utils import c_commands
23 from .utils import tools
---> 24 from .utils.misc import info
25 from .utils.cyutils import _fast_iterptr as iterframe_from_array
26 from .core.c_options import info as compiled_info
File ~/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/utils/misc.py:7
5 import os
6 from glob import glob
----> 7 from pytraj.core.c_options import set_world_silent
9 from .context import capture_stdout
11 try:
File ~/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/core/__init__.py:2
1 """"""
----> 2 from .topology_objects import Atom, Residue, Molecule
3 from .box import Box
4 from .elements import mass_atomic_number_dict, mass_element_dict
ImportError: dlopen(/Users/zwu/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/core/topology_objects.cpython-312-darwin.so, 0x0002): tried: '/Users/zwu/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/core/topology_objects.cpython-312-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/zwu/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/core/topology_objects.cpython-312-darwin.so' (no such file), '/Users/zwu/miniconda3/envs/ambertools/lib/python3.12/site-packages/pytraj/core/topology_objects.cpython-312-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64e' or 'arm64'))
This is how I set up the env conda create -n ambertools ambertools ipython
Due to incompatibilities between tk and xorg-*, osx packages can't build graphical interfaces such as xleap. We will keep an eye on this area and update accordingly.
Trying to update perses so it depends on ambertools instead of Omnia's ambermini results in an error due to clobbing:
ClobberError: This transaction has incompatible packages due to a shared path.
packages: conda-forge/osx-64::libiconv-1.15-h01d97ff_1005, conda-forge/osx-64::ambertools-19.11-py37h8d9041b_1
path: 'lib/libiconv.2.dylib'
The environment file used to trigger this behavior is listed here:
The CMake build system has a step after build where it bundles some libraries in $PREFIX for some reason (see these lines). This might be pulling too many files that are foreign to ambertools. This will need further investigation, I guess, since this step is not needed in Linux.
The current repo is a bit bloated with commits that my laptop struggles with the git history. I think it might be better if we only squash merge PRs in the future.
Unless I'm making a typo that I can't find, it seems amber tools is not properly listed on conda-forge. (Aside from directly searching, like below, I also can't install ambertools if list conda-forge as a channel in an environment YAML file.)
$ conda search ambertools --channel conda-forge
WARNING: The conda.compat module is deprecated and will be removed in a future release.
Loading channels: done
No match found for: ambertools. Search: *ambertools*
PackagesNotFoundError: The following packages are not available from current channels:
- ambertools
Current channels:
- https://conda.anaconda.org/conda-forge/osx-64
- https://conda.anaconda.org/conda-forge/noarch
- https://repo.anaconda.com/pkgs/main/osx-64
- https://repo.anaconda.com/pkgs/main/noarch
- https://repo.anaconda.com/pkgs/free/osx-64
- https://repo.anaconda.com/pkgs/free/noarch
- https://repo.anaconda.com/pkgs/r/osx-64
- https://repo.anaconda.com/pkgs/r/noarch
To search for alternate channels that may provide the conda package you're
looking for, navigate to
https://anaconda.org
and use the search bar at the top of the page.
These errors are seen (in old,old,old xleap code):
These are the errors from the osx-64 and osx-arm64
2023-10-06T01:41:17.8020210Z /Users/runner/miniforge3/conda-bld/ambertools_1696552439471/work/AmberTools/src/leap/src/Wc/WcActCB.c:316:5: error: incompatible function pointer types passing 'void (Widget, XtGrabKind)' (aka 'void (struct _WidgetRec *, XtGrabKind)') to parameter of type 'PFVWidInt' (aka 'void (*)(struct _WidgetRec *, int)') [-Wincompatible-function-pointer-types]
2023-10-06T01:41:17.8021260Z XtPopup, XtGrabNone );
2023-10-06T01:41:17.8022180Z ^~~~~~~
2023-10-06T01:41:17.8025180Z /Users/runner/miniforge3/conda-bld/ambertools_1696552439471/work/AmberTools/src/leap/src/Wc/WcActCB.c:323:5: error: incompatible function pointer types passing 'void (Widget, XtGrabKind)' (aka 'void (struct _WidgetRec *, XtGrabKind)') to parameter of type 'PFVWidInt' (aka 'void (*)(struct _WidgetRec *, int)') [-Wincompatible-function-pointer-types]
2023-10-06T01:41:17.8026070Z XtPopup, XtGrabExclusive );
2023-10-06T01:41:17.8026340Z ^~~~~~~
2023-10-06T01:41:17.8103750Z /Users/runner/miniforge3/conda-bld/ambertools_1696552439471/work/AmberTools/src/leap/src/Wc/WcActCB.c:916:23: error: incompatible function pointer types passing 'void (Widget, const char *, XtCallbackList)' (aka 'void (struct _WidgetRec *, const char *, struct _XtCallbackRec *)') to parameter of type 'AddOrRemoveProc' (aka 'void (*)(struct _WidgetRec *, char *, struct _XtCallbackRec *)') [-Wincompatible-function-pointer-types]
2023-10-06T01:41:17.8104400Z "WcAddCallbacks", XtAddCallbacks );
2023-10-06T01:41:17.8104690Z ^~~~~~~~~~~~~~
2023-10-06T01:41:17.8107390Z /Users/runner/miniforge3/conda-bld/ambertools_1696552439471/work/AmberTools/src/leap/src/Wc/WcActCB.c:926:26: error: incompatible function pointer types passing 'void (Widget, const char *, XtCallbackList)' (aka 'void (struct _WidgetRec *, const char *, struct _XtCallbackRec *)') to parameter of type 'AddOrRemoveProc' (aka 'void (*)(struct _WidgetRec *, char *, struct _XtCallbackRec *)') [-Wincompatible-function-pointer-types]
2023-10-06T01:41:17.8107970Z "WcRemoveCallbacks", XtRemoveCallbacks );
2023-10-06T01:41:17.8108230Z ^~~~~~~~~~~~~~~~~
I don't have access to OSX machines, but have installed clang-16 on my linux (Ubuntu) box, and will see if there is some simple fix. I don't think anyone understands what this code is doing.
Going forward, AmberTools has a significant number of function declataions without prototypes (cpptraj, etc.). These will need to be addressed soon.
Solution to issue cannot be found in the documentation.
I checked the documentation.
Issue
We've found that running pip check on packages which install ambertools downstream returns the following: ndfes 1.8 requires joblib, which is not installed..
It looks like there might be some missing joblib dependency in the conda-forge recipe?
I was interested in using some of the CUDA accelerated functionality of cpptraj to speed up some calculations, but it doesn't look like ambertools has any CUDA builds nor is there a separate cpptraj package that I could see similar to how parmed is split out.
Assuming I haven't missed anything (and apologies if I have!), would you be open to providing either a CUDA build of ambertools (assuming that would in turn provide CUDA enabled cpptraj) or alternatively splitting out a separate cpptraj package that itself has a CUDA build available if that is a path of less resistance?
Instead of bundling ParmEd with AmberTools, add the already existing package to the requirements, so downstream packages can use both if needed without clobbering issues (e.g. omnia-md/conda-recipes#1011 (comment)).
ParmEd as a dependency is hard pinned to 4.0.0 from #102, but only newer versions (4.2.2+) support Python 3.12. This is preventing the bot from attempting a migration. Here's a run and relevant bits of log are below.
Can we loosen this to parmed =4?
linux_64_numpy1.26python3.12.____cpython: Could not solve for environment specs
The following packages are incompatible
โโ parmed 4.0.0.* is installable with the potential options
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.10.* *_cp310, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.11.* *_cp311, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.8.* *_cp38, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.8 *_pypy38_pp73, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.9.* *_cp39, which can be installed;
โ โโ parmed 4.0.0 would require
โ โโ python_abi 3.9 *_pypy39_pp73, which can be installed;
โโ python 3.12.* *_cpython is not installable because there are no viable options
โโ python 3.12.0 would require
โ โโ python_abi 3.12.* *_cp312, which conflicts with any installable versions previously reported;
โโ python 3.12.0rc3 would require
โโ _python_rc, which does not exist (perhaps a missing channel).
osx_64_numpy1.26python3.12.____cpython: Could not solve for environment specs
The following packages are incompatible
โโ parmed 4.0.0.* is installable with the potential options
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.10.* *_cp310, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.11.* *_cp311, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.8 *_pypy38_pp73, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.8.* *_cp38, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.9.* *_cp39, which can be installed;
โ โโ parmed 4.0.0 would require
โ โโ python_abi 3.9 *_pypy39_pp73, which can be installed;
โโ python 3.12.* *_cpython is not installable because there are no viable options
โโ python 3.12.0 would require
โ โโ python_abi 3.12.* *_cp312, which conflicts with any installable versions previously reported;
โโ python 3.12.0rc3 would require
โโ _python_rc, which does not exist (perhaps a missing channel).
osx_arm64_numpy1.26python3.12.____cpython: Could not solve for environment specs
The following packages are incompatible
โโ parmed 4.0.0.* is installable with the potential options
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.10.* *_cp310, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.11.* *_cp311, which can be installed;
โ โโ parmed 4.0.0 would require
โ โ โโ python_abi 3.8.* *_cp38, which can be installed;
โ โโ parmed 4.0.0 would require
โ โโ python_abi 3.9.* *_cp39, which can be installed;
โโ python 3.12.* *_cpython is not installable because there are no viable options
โโ python 3.12.0 would require
โ โโ python_abi 3.12.* *_cp312, which conflicts with any installable versions previously reported;
โโ python 3.12.0rc3 would require
โโ _python_rc, which does not exist (perhaps a missing channel).
I noticed that this package is listed as version 19, without minor or bugfix releases.
The official AMBER conda distribution includes a minor version number because typically multiple patch versions are released during the lifecycle of AmberTools to either add new features or fix bugs. Since Amber ff19SB was just released, it seems very likely that there will be more releases during the lifecycle of AmberTools 19, so it may be good to include this minor version number---if at least for consistency!
This is just a reminder to set -DTRUST_SYSTEM_LIBS=TRUE when AT20 is released, which will include some of our patches and those will be triggered with that var.
Issue:
I'm not sure if this bug is reported here, although it is explicitly related to the conda ambertools package.
I have a project that depends on AmberTools and ever since I discovered the conda package I have used it. However, it wasn't until recently that I realized that the programs I use from AmberTools overload the CPU. I thought it was a specific program, but doing the relevant tests I realized that they are all (at least the ones I use: sander, mmpbsa_py_nmode, rism3d.snglpnt, and I'm not sure if the same thing happens to cpptraj).
The programs, even if they are executed in a single thread serially, end up consuming 1500% of that core, but in practice, it means that it occupies all the available cores. This doesn't happen with the compiled version of AmberTools, so it seems to be an issue with this build. I also tried several versions (21.1-21.12) and in all of them, I get the same result. I even downloaded the package that uses the conda recipe and compiled it on my PC and I get the same problem. I hope you can give me information about it.
Solution to issue cannot be found in the documentation.
I checked the documentation.
Issue
Debugging a recent issue at OpenFF seems to indicate that Antechamber from AT22 has a fatal problem parsing inputs on intel-based macbooks that upgrade to OSX 13.
This issue does not reproduce on
ARM-based macs on either OSX 12 or 13
The same Intel-based mac before it was upgraded from OSX 12 to 13
The same Intel-based mac using OSX 13 and downgraded to AmberTools 20 or 21
Unsuccessful outputs on Intel mac upgraded to OSX 13 and using AT22:
Terminal output
Welcome to antechamber 22.0: molecular input file processor.
Info: acdoctor mode is on: check and diagnose problems in the input file.
Info: The atom type is set to gaff; the options available to the -at flag are
gaff, gaff2, amber, bcc, and sybyl.
-- Check Format for sdf File --
Status: pass
-- Check Unusual Elements --
Status: pass
-- Check Open Valences --
Warning: This molecule has no hydrogens nor halogens.
It is quite possible that there are unfilled valences.
-- Check Geometry --
for those bonded
for those not bonded
Status: pass
-- Check Weird Bonds --
Status: pass
-- Check Number of Units --
Status: pass
acdoctor mode has completed checking the input file.
Info: Total number of electrons: 0; net charge: 0
Running: /Users/jeffreywagner/miniconda3/envs/offtk-0106/bin/sqm -O -i sqm.in -o sqm.out
/Users/jeffreywagner/miniconda3/envs/offtk-0106/bin/wrapped_progs/antechamber: Fatal Error!
Cannot properly run "/Users/jeffreywagner/miniconda3/envs/offtk-0106/bin/sqm -O -i sqm.in -o sqm.out".
sqm.in contents:
Run semi-empirical minimization
&qmmm
qm_theory='AM1', grms_tol=0.0005,
scfconv=1.d-10, ndiis_attempts=700, qmcharge=0,
/
Successful outputs on Intel mac upgraded to OSX 13 and using AT21 (downgraded AT):
Terminal output:
Welcome to antechamber 21.0: molecular input file processor.
acdoctor mode is on: check and diagnose problems in the input file.
The atom type is set to gaff; the options available to the -at flag are
gaff, gaff2, amber, bcc, and sybyl.
-- Check Format for sdf File --
Status: pass
-- Check Unusual Elements --
Status: pass
-- Check Open Valences --
Status: pass
-- Check Geometry --
for those bonded
for those not bonded
Status: pass
-- Check Weird Bonds --
Status: pass
-- Check Number of Units --
Status: pass
acdoctor mode has completed checking the input file.
Info: Total number of electrons: 80; net charge: 0
Running: /Users/jeffreywagner/miniconda3/envs/offtk-0106-at21/bin/sqm -O -i sqm.in -o sqm.out
Info: Total number of electrons: 80; net charge: 0
@dacase: Could you put a copy of the AmberTools20.tar.bz2 up at https://ambermd.org/downloads/ like you did for AmberTools19.tar.bz2? We can use the automated update mechanism to keep the package current with patch releases after that!
We'll then be able to update this line, as well as address #27.
Issue: The license for AmberTools is not correctly described.
The README says that the AmberTools license is GPL, but this is too simple. AmberTools is a collection of packages, some GPL, some key ones LGPL, others are BSD, some are public domain. The AmberTools distribution has a LICENSE file (in the AmberTools folder) which explains things carefully.
A key point is that anything that needs to be linked (including all the compiled python modules) are LGPL.
Solution to issue cannot be found in the documentation.
I checked the documentation.
Issue
We've run into issues installing ambertools in the same environment as our analysis package loos. The problems stem from incompatible versions of boost-cpp, which is very finicky about having an exact match in version -- at the conda-forge level, it always pins to a specific very new version. Since ambertools hasn't been re-rendered in a while, we can't make our package build to match yours.
I was wondering if you'd be willing to re-render the ambertools package so that it grabs a current boost-cpp, then we can do the same so the versions match. We're working on a more general solution, but this seems like an easy intermediate step to let our users get back to work.
Thanks,
Alan
PS I'm required to fill in the conda list and conda info fields, but they're irrelevant for this issue.
File "/usr/local/bin/MMPBSA.py", line 90, in <module>
app.read_input_file()
File "/usr/local/lib/python3.10/site-packages/MMPBSA_mods/main.py", line 762, in read_input_file
self.INPUT = self.input_file.Parse(infile)
File "/usr/local/lib/python3.10/site-packages/MMPBSA_mods/input_parser.py", line 443, in Parse
SetValue(var[1])
File "/usr/local/lib/python3.10/site-packages/MMPBSA_mods/input_parser.py", line 112, in SetValue
self.value = self.datatype(value)
ValueError: invalid literal for int() with base 10: ''
Fatal Error!
All files have been retained for your error investigation:
You should begin by examining the output files of the first failed calculation.
Consult the "Temporary Files" subsection of the MMPBSA.py chapter in the
manual for file naming conventions.
Are you (or someone else connected to this github page) still able and willing to work on this?
You could skip this RC if you wish...a second one should be ready in a week or so. Let me know what I can do to help out.
One change from AmberTools22 is that the NAB compiler is no longer a part of the package. This should be a simplification, and means that users no longer need to the compilers as well as the ambertools package itself.
Issue:
Not sure if this is the right place for this, but, when I run ambpdb from the conda build of AmberTools I get the following error:
ambpdb: error while loading shared libraries: /home/conda/feedstock_root/build_artifacts/ambertools_1571761492881/work/lib/libcpptraj.so: cannot open shared object file: No such file or directory
This is an idea that's been mentioned a few times - with some effort, AmberTools could be released in bits vs. a single monolith that causes conflicts with other packages in users' environments.
The package-clobbering Jaime refers to has been a significant problem for me in the past. There's also the practical reality that bringing in all of AmberTools is usually not necessary; people typically want to use only one or a few tools in the suite.
I'm happy to commit some effort to change the packaging here to be more modular, but I can't do it myself. We need somebody else to lead that effort, ideally somebody from the Amber community.
Hi, I wonder if you guys have any experience with regard to do a local build of the OSX-64 conda package?
I have been using build-locally.py script to build the package for linux-64 on a linux machine and it worked fine.
But if I tried to do the same thing on my MacOS laptop, I got the following error.
-- The C compiler identification is Clang 15.0.7
-- The CXX compiler identification is Clang 15.0.7
-- The Fortran compiler identification is GNU 12.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: $BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-clang
-- Check for working C compiler: $BUILD_PREFIX/bin/x86_64-apple-darwin13.4.0-clang - broken
CMake Error at /Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler
"/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/bin/x86_64-apple-darwin13.4.0-clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/work/build/CMakeFiles/CMakeTmp
Run Build Command(s):/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/bin/make -f Makefile cmTC_f9850/fast && /Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/bin/make -f CMakeFiles/cmTC_f9850.dir/build.make CMakeFiles/cmTC_f9850.dir/build
make[1]: Entering directory '/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/work/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_f9850.dir/testCCompiler.c.o
/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/bin/x86_64-apple-darwin13.4.0-clang -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -isystem /Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/include -fdebug-prefix-map=/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/work=/usr/local/src/conda/ambertools-23.3 -fdebug-prefix-map=/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p=/usr/local/src/conda-prefix -arch x86_64 -mmacosx-version-min=10.9 -MD -MT CMakeFiles/cmTC_f9850.dir/testCCompiler.c.o -MF CMakeFiles/cmTC_f9850.dir/testCCompiler.c.o.d -o CMakeFiles/cmTC_f9850.dir/testCCompiler.c.o -c /Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/work/build/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_f9850
/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/bin/cmake -E cmake_link_script CMakeFiles/cmTC_f9850.dir/link.txt --verbose=1
/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_build_env/bin/x86_64-apple-darwin13.4.0-clang -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -isystem /Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/include -fdebug-prefix-map=/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/work=/usr/local/src/conda/ambertools-23.3 -fdebug-prefix-map=/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p=/usr/local/src/conda-prefix -arch x86_64 -mmacosx-version-min=10.9 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs -Wl,-rpath,/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib -L/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_p/lib CMakeFiles/cmTC_f9850.dir/testCCompiler.c.o -o cmTC_f9850
ld: library not found for -lSystem
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [CMakeFiles/cmTC_f9850.dir/build.make:100: cmTC_f9850] Error 1
make[1]: Leaving directory '/Users/zwu/src/amber-feedstock/miniforge3/conda-bld/ambertools_1698769639923/work/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:127: cmTC_f9850/fast] Error 2
I never really got into the ambertools conda package. Checking it out, realized that the packmol package included in AmberTools is being patched out, and replaced with the conda-forge version. I am not sure I am happy with that decision as:
-The conda-forge package of packmol is not maintained by Leandro, who is the main packmol developer. This has as a consequence that the package there is quite outdated.
-I fork packmol myself, and play with functionalities, which are sometimes added before they are included within the code in packmol but are used for packmol-memgen. Right now, the xygauss surface, which I added about 3-4 years ago, but was added about a year ago to the main packmol branch, should not be available in the packmol that is being installed.
Also, it would be nice to make a "last AmberTools 23" update for the conda-forge package. That should btw fix the error when calling packmol-memgen -h, so you could uncomment that in the tests.
Ambertools 23 had a behavior change openmm/openmmforcefields#281 from ambertools 22 that is causing some issues downstream. If we had an ambertools 22 build for python 3.11 (osx-arm arch would be nice as well) then we could keep using ambertools 22 when python 3.10 drops out of NEP.
I am creating this issue to track problems that arise when trying to make a ambertools 22 build for python 3.11. We did try an python 3.11 build for ambertools 22 here #111 but decided to just add a python 3.11 build for ambertools 23.
Just as an FYI: release candidates for AmberTools24 will be coming soon (late March, 2024). My general recommendation is that people here wait for the second or third candidate (early April: I'll post release notices here) for any initial problems to settle down. We are hoping for a final release by the end of April, with a conda-forge package available either then or shortly thereafter.
I want to thank again all of the folks who have been working on this over the years. Please don't hesitate to contact me with problems -- I've made other conda packages, but am no expert at it. On the other hand, I can often help with code content or compatibility issues that may arise.
Thanks for maintaining a conda-forge build of AmberTools!
Has there been an effort to build osx builds of this feedstock? If not, I wonder if @hainm has some thoughts on how we might be able to get that to work.
Issue: Installing the latest package has conda list reporting version 17.0 and source pypi. I think I recall this being a consequence of the internal bundling of miniconda, but it would help with debugging if we could get the package version reported correctly.
(I know Jaime just headed out for a two week vacation -- I'm doing the same for the next week, just wanted to jot this down somewhere)