Giter Club home page Giter Club logo

crest's Introduction

CREST

Latest Version DOI example workflow License: LGPL v3 Github Downloads All Releases

CREST (originally abbreviated from Conformer-Rotamer Ensemble Sampling Tool) is a program for the automated exploration of the low-energy molecular chemical space. It functions as an OMP scheduler for calculations with efficient force-field and semiempirical quantum mechanical methods such as xTB, and provides a variety of capabilities for creation and analysis of structure ensembles.

CREST

Documentation

The CREST documentation with installation instructions and application examples is hosted at:

Installation quick guide

For any installation make sure that you have correctly installed and sourced the xtb program before attempting any calculations with CREST. While xtb is technically not needed for the primary runtypes of CREST versions >3.0 thanks to an integration of tblite, some functionalities, like QCG, still require it!

There are multiple possible ways of installing CREST. For building the program from source we recommend the Intel ifort and icc compilers (the continuous release build uses the 2023.1.0 version of these compilers).

Detailed build instructions can be found at https://crest-lab.github.io/crest-docs/page/installation.

Precompiled binaries

To use the statically linked binaries (Intel compilers) that can be found at the release page, of this repository. The most recent program version is automatically build (meson/ifort) from the main branch and can be found at the continous release page. Simply unpack the binary and add it to your PATH variable.

unzip crest.zip

or

tar -xf crest-latest.tar.xz

The program should be directly executable.

Tested builds

Working and tested builds of CREST (mostly on Ubuntu 20.04 LTS):

Build System Compiler Linear Algebra Backend Build type Status Note
CMake 3.28.3 GNU (gcc 10.3.0) OpenBLAS (with OpenMP) dynamic
CMake 3.28.3 GNU (gcc 10.3.0) MKL shared (oneAPI 2023.1) dynamic
CMake 3.28.3 GNU (gcc 9.5.0) MKL shared (oneAPI 2023.1) dynamic
CMake 3.28.3 Intel (ifort/icc 2021.9.0) MKL static (oneAPI 2023.1) dynamic ⚠️ OpenMP problem (#285)
Meson 1.2.0 Intel (ifort/icc 2021.9.0) MKL static (oneAPI 2023.1) static continuous release build
Meson 1.2.0 Intel (ifort 2021.9.0/icx 2023.1.0) MKL static (oneAPI 2023.1) static

Generally, subprojects should be initialized for the default build options, which can be done by

git submodule init
git submodule update

For more information about builds including subprojects see here.

Some basic build instructions can be found in the following dropdown tabs:

CMake build

Building CREST with CMake works with the following chain of commands (in this example with gfortran/gcc compilers):

export FC=gfortran CC=gcc
cmake -B _build

and then to build the CREST binary

make -C _build

The CMake build typically requires access to shared libraries of LAPACK and OpenMP. They must be present in the library paths at compile and runtime.

meson build

For the setup an configuration of meson see also the meson setup page hosted at the xtb repository. The chain of commands to build CREST with meson is:

export FC=ifort CC=icc
meson setup _build --prefix=$PWD/_dist
meson install -C _build

The meson build of CREST is mainly focused on and tested with the Intel ifort/icc compilers. When using newer versions of Intel's oneAPI, replacing icc with icx should work. Please refrain from using ifx instead of ifort, however. When attempting to build with gfortran and gcc, add -Dla_backend=mkl to the meson setup command. Compatibility with the GNU compilers might be limited. We recommend the CMake build (see below) in this instance.

By default the meson build will create a statically linked binary.

Conda build

A conda-forge feedstock is maintained at https://github.com/conda-forge/crest-feedstock.

Installing CREST from the conda-forge channel can be achieved by adding conda-forge to your channels with:

conda config --add channels conda-forge
conda config --set channel_priority strict

Once the conda-forge channel has been enabled, CREST can be installed with conda:

conda install crest

The confa-forge distribution is based on a CMake/gfortran build.


Citations

  1. P. Pracht, F. Bohle, S. Grimme, Phys. Chem. Chem. Phys., 2020, 22, 7169-7192. DOI: 10.1039/C9CP06869D

  2. S. Grimme, J. Chem. Theory Comput., 2019, 155, 2847-2862. DOI: 10.1021/acs.jctc.9b00143

  3. P. Pracht, S. Grimme, Chem. Sci., 2021, 12, 6551-6568. DOI: 10.1039/d1sc00621e

  4. P. Pracht, C.A. Bauer, S. Grimme, J. Comput. Chem., 2017, 38, 2618-2631. DOI: 10.1002/jcc.24922

  5. S. Spicher, C. Plett, P. Pracht, A. Hansen, S. Grimme, J. Chem. Theory Comput., 2022, 18, 3174-3189. DOI: 10.1021/acs.jctc.2c00239

  6. P. Pracht, C. Bannwarth, J. Chem. Theory Comput., 2022, 18 (10), 6370-6385. DOI: 10.1021/acs.jctc.2c00578

  7. P. Pracht, S. Grimme, C. Bannwarth, F. Bohle, S. Ehlert, G. Feldmann, J. Gorges, M. Müller, T. Neudecker, C. Plett, S. Spicher, P. Steinbach, P. Wesołowski, F. Zeller, J. Chem. Phys., 2024, 160, 114110. DOI: 10.1063/5.0197592

BibTex entries

@article{Pracht2020,
  author ="Pracht, Philipp and Bohle, Fabian and Grimme, Stefan",
  title  ="Automated exploration of the low-energy chemical space with fast quantum chemical methods",
  journal  ="Phys. Chem. Chem. Phys.",
  year  ="2020",
  volume  ="22",
  issue  ="14",
  pages  ="7169-7192",
  doi  ="10.1039/C9CP06869D"
}

@article{Grimme2019,
  author = {Grimme, Stefan},
  title = {Exploration of Chemical Compound, Conformer, and Reaction Space with Meta-Dynamics Simulations Based on Tight-Binding Quantum Chemical Calculations},
  journal = {J. Chem. Theory Comput.},
  volume = {15},
  number = {5},
  pages = {2847-2862},
  year = {2019},
  doi = {10.1021/acs.jctc.9b00143}
}

@article{Pracht2021,
  author ="Pracht, Philipp and Grimme, Stefan",
  title  ="Calculation of absolute molecular entropies and heat capacities made simple",
  journal  ="Chem. Sci.",
  year  ="2021",
  volume  ="12",
  issue  ="19",
  pages  ="6551-6568",
  doi  ="10.1039/D1SC00621E",
  url  ="http://dx.doi.org/10.1039/D1SC00621E"
}

@article{Pracht2017,
  author = {Pracht, Philipp and Bauer, Christoph Alexander and Grimme, Stefan},
  title = {Automated and efficient quantum chemical determination and energetic ranking of molecular protonation sites},
  journal = {J. Comput. Chem.},
  volume = {38},
  number = {30},
  pages = {2618-2631},
  doi = {https://doi.org/10.1002/jcc.24922},
  url = {https://onlinelibrary.wiley.com/doi/abs/10.1002/jcc.24922},
  year = {2017}
}

@article{Spicher2022,
  author = {Spicher, Sebastian and Plett, Christoph and Pracht, Philipp and Hansen, Andreas and Grimme, Stefan},
  title = {Automated Molecular Cluster Growing for Explicit Solvation by Efficient Force Field and Tight Binding Methods},
  journal = {J. Chem. Theory Comput.},
  volume = {18},
  number = {5},
  pages = {3174-3189},
  year = {2022},
  doi = {10.1021/acs.jctc.2c00239}
}

@article{Pracht2022,
  author = {Pracht, Philipp and Bannwarth, Christoph},
  title = {Fast Screening of Minimum Energy Crossing Points with Semiempirical Tight-Binding Methods},
  journal = {J. Chem. Theory Comput.},
  volume = {18},
  number = {10},
  pages = {6370-6385},
  year = {2022},
  doi = {10.1021/acs.jctc.2c00578}
}

@article{Pracht2024,
  author = {Pracht, Philipp and Grimme, Stefan and Bannwarth, Christoph and Bohle, Fabian and Ehlert, Sebastian and Feldmann, Gereon and Gorges, Johannes and M\"uller, Marcel and Neudecker, Tim and Plett, Christoph and Spicher, Sebastian and Steinbach, Pit and Weso\{}lowski, Patryk A. and Zeller, Felix},
  title = "{CREST - A program for the exploration of low-energy molecular chemical space}",
  journal = {J. Chem. Phys.},
  volume = {160},
  number = {11},
  pages = {114110},
  year = {2024},
  month = {03},
  issn = {0021-9606},
  doi = {10.1063/5.0197592},
  url = {https://doi.org/10.1063/5.0197592}
}

License

CREST is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

CREST is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU Lesser General Public License for more details.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in CREST by you, as defined in the GNU Lesser General Public license, shall be licensed as above, without any additional terms or conditions

crest's People

Contributors

awvwgk avatar cbannwarth avatar cplett avatar gorges97 avatar jevandezande avatar kjelljorner avatar mtolston avatar musicinmybrain avatar pprcht avatar susilehtola avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

crest's Issues

WARNING! Change in topology detected!

Recently, I read a nice paper named "Efficient Calculation of Small Molecule Binding in Metal−Organic Frameworks and Porous Organic Cages" from JPCC. I want to repeat the result of CO2@MOF-5 . When I did it, I got a warning " WARNING! Change in topology detected!". I want to know that it is reasonable?
Here is my command line:
crest struc.xyz -cinp .xcontrol -nci -gff --noreftopo
.xcontrol:
$metadyn
atoms: 401-403
$end

Thanks in advance.

unique conformers relative energies print on the screen

In the previous version of crest-2.9, the relative energy of each “unique conformers” will be output on the screen at the end of calculation. Now, this output is cancelled, and instead a "crest.energies" file is output. This function is what I really want, but I still want this energy to be displayed on the screen directly sometimes. I hope you can make adjustments.

Two days ago I asked some unrelated questions under another post, I apologize for that. But I still want to ask:
what's the function of automatic bond length constraint (-cbonds) in crest-2.10?

Best wishes!

Problem with strucutures rejected due to topology mismatches

I am attempting to sort a trajectory for a metal cluster using cregen. Previously this caused no issues until I had to redownload the 2.11_dev version of crest (Version 2.11dev, Fri 15. Jan 12:42:14 CEST 2021). Now out of my 5000 configurations all but the reference structure is being rejected due to topology mismatches. Using 2.10.2 I get the expected result (67 unique clusters) a similar result to what I got with a previous version of crest 2.11_dev (Version 2.11dev, Mon 21. Sep 10:32:08 CEST 2020).

The reference structure and trajectory that I am using are attached.

xtb.txt
struc.txt

I am running the command as:
crest struc.txt -cregen xtb.txt -ewin 100

Crest uses capital letters for two-letter element symbols in xyz output

More of a suggestion than a real issue: CREST seems to output two-letter element symbols with two capital letters, e.g. "IR" for Iridium instead of "Ir". I'm not aware of a clear specification of the xyz format, but it might make sense to output such element symbols only with one capital character for the crest_*.xyz files.

Some programs will not correctly interpret the all-caps element symbols (e.g. Schrödinger's Maestro), and while others tolerate them, they always output only xyz files with single capital letter element symbols (Avogadro, molden, ChemAxon's molconvert, Turbomole's x2t/t2x).

I also noticed, that in xtb this seems to depend on the input - xtb mymol.xyz -o for example seems to preserve the original input with either two or single capital letter element symbols.

V2.11 - make install with cmake fails

I am currently trying to install crest on our HPC system and the cmake configure-build-install procedure fails in the install step. I used the Intel 2018.1 Parallel Studio and CMake 3.18.1.

Here is want I got:

$ export FC=ifort CC=icc
$ cmake -B _build_intel -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/beegfs/software/apps/crest-2.11/
$ make -C _build_intel
$ make -C _build_intel install 
make: Entering directory `/root/setup/ms/crest-2.11/_build_intel'
make[1]: Entering directory `/root/setup/ms/crest-2.11/_build_intel'
make[2]: Entering directory `/root/setup/ms/crest-2.11/_build_intel'
make[2]: Leaving directory `/root/setup/ms/crest-2.11/_build_intel'
[100%] Built target crest-exe
make[1]: Leaving directory `/root/setup/ms/crest-2.11/_build_intel'
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /mechthild/software/apps/crest-2.11/bin/crest
CMake Error at cmake_install.cmake:72 (file):
  file INSTALL cannot find
  "/root/setup/ms/crest-2.11/combi-scripts/crest_combi": No such file or
  directory.

Is it same to remove the crest_combi install instruction from the CMakeLists.txt file?

2.11dev SIGSEGV fault in Property Calculation

2.11dev crashes near the end of the following run on Ubuntu 20.04LTS:

crest CB8.xyz --alpb h2o -nci -mdlen 10 -prop hess -keepdir > CB8_crest_10_alpb_nci.out

with this error message:

alpb$ forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
crest              000000000274FA23  Unknown               Unknown  Unknown
crest              0000000002944190  Unknown               Unknown  Unknown
crest              00000000004F42CB  Unknown               Unknown  Unknown
crest              00000000005288C2  Unknown               Unknown  Unknown
crest              00000000005CA51C  Unknown               Unknown  Unknown
crest              00000000004045D2  Unknown               Unknown  Unknown
crest              0000000002945630  Unknown               Unknown  Unknown
crest              00000000004044B7  Unknown               Unknown  Unknown
^C
[1]-  Exit 174                crest CB8.xyz --alpb h2o -nci -mdlen 10 -prop hess -keepdir > CB8_crest_10_alpb_nci.out

These are the last lines in the .out file before the fault:

 number of unique conformers for further calc            2
 list of relative energies saved as "crest.energies"
 
******************************************************************************************
**                     P R O P E R T Y   C A L C U L A T I O N                          **
******************************************************************************************
 writing TMPCONF* Dirs from file "crest_conformers.xyz" ... done.
 ---------------------------------------
 Hessian calculations for all conformers
 ---------------------------------------
 Performing calculations for 2 structures ...
 1 2 
 done.

Clearly the lack of information about the offending subroutine/s is not particularly helpful. In case it helps pinpoint the problem, the 2 final property xtb calcs (PROP/TMPCONF1 and TMPCONF2) run to completion and thermochemical properties are printed OK in each xtb.out, and crest_property.xyz is written in PROP but the following files are NOT written in PROP subdirectory:
crest.energies
cregen.out.tmp
cre_members
crest_ensemble.xyz

I've used the same jobs with 2.11dev on 20 other occasions, but with smaller molecules, and they run to completion, as does the above run but with -gbsa instead of -alpb, so this feels like a new memory issue.
~/.bashrc contains the following, which I've been using successfully many times with 2.10.2/6.3.2

XTBHOME=/usr/bin/xtb-6.3.3/

# requirements: $XTBHOME is set to `xtb` root directory
# otherwise the script will find the location of itself here:
if [ -z "${XTBHOME}" ]; then
   XTBHOME="$(cd -P "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
fi

# set up path for xtb, using the xtb directory and the users home directory
XTBPATH=${XTBHOME}/share/xtb:${XTBHOME}:${HOME}

# to include the documentation we include our man pages in the users manpath
MANPATH=${MANPATH}:${XTBHOME}/share/man

# finally we have to make the binaries and scripts accessable
PATH=${PATH}:${XTBHOME}/bin
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${XTBHOME}/lib
PYTHONPATH=${PYTHONPATH}:${XTBHOME}/python
export PATH XTBPATH MANPATH LD_LIBRARY_PATH PYTHONPATH

# setup some xtb environment parameters
ulimit -s unlimited
export OMP_STACKSIZE=4G
export MKL_NUM_THREADS=12
#distribute the number of threads in the OMP section
export OMP_THREAD_LIMIT=12
export OMP_NUM_THREADS=${OMP_THREAD_LIMIT},1
# deactivate nested OMP constructs
export OMP_MAX_ACTIVE_LEVELS=1

I can reproduce this using a 2nd run with the same input coord file, and with another host/guest molecule of similar size. Wondering whether there's any reason OMP_STACKSIZE=4G should be increased with -alpb? (Ans: increasing to 8G didn't affect this problem)

Large molecules

Hi,

I am working with some systems with ~250 atoms and as long as I use GFNFF for the geometry minimisation/MD I am OK. I want to compare with GFN2 but the initial geometry optimisation fails. It works fine when I use XTB alone, so it seems likely to be an atom number limit problem in CREST. I tried recompiling after changing all instances of 'maxat' from 200 to 2000 but it still fails. Any help would be greatly appreciated.

XTB=6.4.0
CREST=2.11

Cheers,
Bruce

topologically unique structures failed for methoxide

As a test, I have tried to deprotonate the methanol struc.xyz.

  6
 
 O          0.7209414623       -0.0081920924        0.0247888678
 C         -0.7083872611       -0.0125326715        0.0015524466
 H         -1.1180698623       -0.7583863198        0.6878372156
 H         -1.0924517093       -0.2070593793       -1.0040823640
 H         -1.0409809091        0.9749250491        0.3215117741
 H          1.0229482795       -0.8547545860       -0.3256079401

by crest struc.xyz -deprotonate -chrg 0 -g h2o, which gives the weird output as

  5
  -7.64209103000000
 O          0.6898680523       -0.0704627773        0.1213876794
 C         -0.6434492443        0.1152795170       -0.1068125620
 H         -1.1020417729       -0.3085911564       -0.9797366788
 H         -1.0546068831        0.9824319222        0.3692963548
 H          1.0122998349       -0.8262711733       -0.3859718977

Further checking of the log files revied that there is a problem with the topologically unique structures detection.
The correct output is generated as the fourth structure in the deprotonate_3.xyz.
However, the log files say

 Initial 4 structures from file deprotonate_3.xyz have
 been reduced to 1 topologically unique structures.

where the 4 structures are topologically different and the correct output has been discarded.

The complete log file is attached.

       ==============================================
       |                                            |
       |                 C R E S T                  |
       |                                            |
       |  Conformer-Rotamer Ensemble Sampling Tool  |
       |          based on the GFN methods          |
       |             P.Pracht, S.Grimme             |
       |          Universitaet Bonn, MCTC           |
       ==============================================
       Version 2.11dev, Tue 13. Oct 10:57:46 CEST 2020
  Using the xTB program. Compatible with xTB version 6.3.3
 
   Cite work conducted with this code as

   P. Pracht, F. Bohle, S. Grimme, PCCP, 2020, 22, 7169-7192.

   and

   S. Grimme, JCTC, 2019, 15, 2847-2862.
 
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 Command line input:
 > crest struc.xyz -deprotonate -chrg 0 -g h2o

  -deprotonate : automated deprotonation script
  -chrg 0
  --gbsa h2o : implicit solvation
 =============================
  # threads =           1
 =============================
        __________________________________________
       |                                          |
       |      automated deprotonation script      |
       |__________________________________________|
  Universitaet Bonn, MCTC
  P.Pracht, Wed 28. Nov 13:11:52 CEST 2018
 
-----------------------
Multilevel Optimization
-----------------------
 -------------------------
 1. crude pre-optimization
 -------------------------
 Optimizing all 4 structures from file "deprotonate_0.xyz" ...
 1 2 3 4
 done.
 4 structures remain within    90.00 kcal/mol window
 
 ---------------------
 2. loose optimization
 ---------------------
 Optimizing all 4 structures from file "deprotonate_1.xyz" ...
 1 2 3 4
 done.
 4 structures remain within    60.00 kcal/mol window
 
 --------------------------------------------
 3. optimization with user-defined thresholds
 --------------------------------------------
 Optimizing all 4 structures from file "deprotonate_2.xyz" ...
 1 2 3 4
 done.
 4 structures remain within    30.00 kcal/mol window
 
 ===================================================
 Identifying topologically equivalent structures:
 Equivalent to 1. structure: 4 structure(s).
 Done.
 Appending file <deprotonated.xyz> with structures.
 
 Initial 4 structures from file deprotonate_3.xyz have
 been reduced to 1 topologically unique structures.
 
===================================================
============= ordered structure list ==============
===================================================
 written to file <deprotonated.xyz>
 
 structure    ΔE(kcal/mol)   Etot(Eh)
    1            0.00         -7.642091
 
 
 -----------------
 Wall Time Summary
 -----------------
    INPUT generation wall time :         0h : 0m : 0s
      multilevel OPT wall time :         0h : 0m : 1s
--------------------
Overall wall time  : 0h : 0m : 1s
 
 CREST terminated normally.

Crest 2.11 does not build with gfortran 11

Using CMake 3.19.7 and gfortran 11.1.1 on Fedora 34, the build fails in

[ 12%] Building Fortran object CMakeFiles/crest-exe.dir/src/zdata.f90.o
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:88:33:

   88 |          procedure deallocate => deallocate_zring  !deallocate (if allocated)
      |                                 1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:89:28:

   89 |          procedure print => print_zring !print to screen
      |                            1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:99:31:

   99 |          procedure allocate => allocate_zgrp
      |                               1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:100:33:

  100 |          procedure deallocate => deallocate_zgrp
      |                                 1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:101:29:

  101 |          procedure append => append_zgrp
      |                             1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:102:28:

  102 |          procedure prgrp => print_zgrp
      |                            1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:114:31:

  114 |          procedure allocate => allocate_zequal !allocate nat, ord(:) and grp(:)
      |                               1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:115:29:

  115 |          procedure member => is_x_member       !check if atom x is member of any group
      |                             1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:116:28:

  116 |          procedure prsum => prsummary_zequal   !print a summary of all the groups
      |                            1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:117:29:

  117 |          procedure geteng => zequal_geteng     !count number of groups with more than 1 member
      |                             1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:200:30:

  200 |         procedure allocate =>  allocate_zensemble
      |                              1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:201:32:

  201 |         procedure deallocate => deallocate_zensemble
      |                                1
Error: ‘::’ needed in PROCEDURE binding with explicit target at (1)
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:251:35:

  251 |        call self%zri(i)%deallocate()
      |                                   1
Error: ‘deallocate’ at (1) is not a member of the ‘zring’ structure
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:388:30:

  388 |        call self%zri(i)%print(ch)
      |                              1
Error: ‘print’ at (1) is not a member of the ‘zring’ structure
/home/susi/rpmbuild/BUILD/crest-2.11/src/zdata.f90:445:25:

  445 |       call self%allocate(1)
      |                         1
Error: ‘allocate’ at (1) is not a member of the ‘zgrp’ structure

[Q] How to calculate host+guest binding free energy and enthalpy changes from CREGEN output?

Greetings. I want to calculate the free energy & enthalpy changes for the binding of a series of 1+ small molecule guests, to a neutral macrocyclic host, in water. I've performed a set of calculations like the following for the host, guests and guest@host complexes:

 crest [email protected] -chrg 1 -g h2o -nci -mdlen 10 -prop hess -keepdir 

Below is the CREGEN output from one of these guest@host runs, from which I calculate the free energy and enthalpy at 298K for the final ensemble as follows:

G(guest@host) = reference state Etot -323.174960188900 Ha - ensemble free energy (-1.280 kcal/mol) / 627.5 kcal/mol/Ha = -323.17292 Ha

and

H(guest@host) = G(guest@host -323.17292 Ha) + 298.15K * ensemble entropy (4.292 cal/mol K) / 1000 cal/kcal / 627.5 kcal/mol/Ha = -323.17088 Ha

and then, from identical calculations for the free host and free guests
deltaG(guest@host)= G(guest@host) - G(host) - G(guest)

Are the above calcs correct? In particular, am I treating the sign of the ensemble free energy correctly?

CREGEN - CONFORMER SYMMETRY ANALYSIS
threads = 12

input file name : crest_property.xyz
output file name : crest_property.xyz.sorted
number of atoms : 174
number of points on xyz files : 47
RMSD threshold : 0.1250
Bconst threshold : 15.0000
population threshold : 0.0500
conformer energy window /kcal : 6.0000
fragment in coord : 2
number of reliable points : 47
reference state Etot : -323.174960188900
running RMSDs...
done.
number of doubles removed by rot/RMSD : 0
total number unique points considered further : 47
Erel/kcal Etot weight/tot conformer set degen origin
1 0.000 -323.17496 0.26606 0.26606 1 1
2 0.144 -323.17473 0.20885 0.20885 2 1
3 0.462 -323.17422 0.12199 0.12199 3 1
... 44 entries omitted for brevity
T /K : 298.15
E lowest : -323.17496
ensemble average energy (kcal) : 0.496
ensemble entropy (J/mol K, cal/mol K) : 17.960 4.292
ensemble free energy (kcal/mol) : -1.280
population of lowest in % : 26.606
number of unique conformers for further calc 44
list of relative energies saved as "crest.energies"
Normal termination.

Interest in a man page?

Would the authors be interested in maintaining a man page (crest.1), if I wrote the initial one based on the crest --help output and submitted a PR?


If so, do you have a preference for where it should be located in the source tree? It could perhaps go at the root of the repository, in a new doc directory, or in assets, depending on your philosophy.

Fixing and confining in CREST

Hi all,

Is it possible to use fixing or confining in CREST? If I put $fix or $wall in .xcontrol, the program (v2.11 with xtb-6.4.0, NCI job) won't run MTD Iteration 2 and stop. Please find the log file of CREST and SLURM attached.

crest.log
slurm-874099.log

Thanks,
Kewei

Installation Error with CMake

Hello,

I'm currently trying to install using CMake and Intel Compilers, and am encountering the following error when installing the binaries:

$ make -C _build_intel install
make: Entering directory `/home/lkavalsk/software/crest-2.11/src/_build_intel'
make: *** No rule to make target `install'.  Stop.
make: Leaving directory `/home/lkavalsk/software/crest-2.11/src/_build_intel'

The previous steps in the installation instructions did not produce any errors.

Not sure if this is relevant but I used conda to install xtb. Also, it is a CentOS system.

Any guidance would be much appreciated. Thanks in advance

Unusal error after version upgrade

Hello, thank you for developing and sharing fantastic code :)
I've enjoyed using CREST since the previous version, but after recent release and upgrade, I'm facing the unseen errors.
I'm trying with -nci for molecular fragments.
The command line input for this work is as follows.
crest mixture.xyz --nofeftopo -g Acetone -nci -T 8 > stdout.log

However after running it is terminated within a few seconds with following error message.
I think I didn't encounter such message in previous version, therefore I suspect it might be related to somewhat with version upgrade.
I would be greatly thankful if you could give any comment or advice to circumvent this issue.
Many thanks in advance.

Best regards,
Hyunwook

crest_error.zip

Command line input:

crest mixture.xyz --nofeftopo -g Acetone -nci -T 8

--gbsa Acetone : implicit solvation
-nci : Special NCI mode for non-covalently bound complexes or clusters.
-T 8 (CPUs/Threads selected)
Automatically generated ellipsoide potential for NCI mode:

$wall
potential=polynomial
ellipsoid: 21.53932170950744, 18.23314152477000, 17.26536115887853, all


xTB Geometry Optimization

Geometry successfully optimized.
WARNING! Change in topology detected!
The topology change was seen in the initial geometry optimization.
This could be an artifact of the chosen theory level (--gfn2).
You can check the optimization trajectory in the "xtbopt.log" file.
Try either of these options:

A) Pre-optimize your input seperately with xtb and use the optimized
   structure as input for CREST. (Only recommended if structure is intact)

B) Restart the same CREST call as before, but ignore the topology change
   by using the "--noreftopo" keyword. (May produce artifacts)

C) Fix the initial input geometry by introducing bond length constraints
   or by using a method with fixed topology (GFN-FF).

Additional adduct forms for crest

Is your feature request related to a problem? Please describe.
The current crest version (Version 2.8.1, Fri 20. Dec 13:44:46 CET 2019 ) only allows for protonized [M+H]+ and deprotonized adduct forms [M-H]-. While these are the most important adducts electrospray mass spectrometry (ESI-MS) they are only two out of 300 different possible ions that are routinely observed. In the past many of these other adducts were simply ignored or found less important. With the advent of accurate mass spectrometry, many experiments and software solutions now report all additional species.

Describe the solution you'd like
A crest version that allows for additional adduct ions selected in the command line or in the parameter file, or input file.

Describe alternatives you've considered
None.

If possible state how you can assist in providing data or code to to implement the feature
Can provide list of most common adducts, for ESI-MS based on thousands of spectra.

Additional context
Maybe starting with the most common ones in the list, that do not require additional complex coding would be good. Basically replacing {H} with {Na} or similar. That means, complicated species with multiple ions or water losses, could be ignored in the beginning, but those with [M+Na]+, [M+Li]+ or [M.Cl]- or [M+NH4]+ could be easily added. The list contains 300 adducts, I only added the top 30.

| #  | Adduct name  | Count | Percent  |   |
|----|--------------|-------|----------|---|
| 1  | [M+H]+       | 98521 | 62.55381 |   |
| 2  | [M+2H]2+     | 18025 | 11.44459 |   |
| 3  | [M+H-H2O]+   | 13822 | 8.77598  |   |
| 4  | [M-H]-       | 9847  | 6.25214  |   |
| 5  | [M+Na]+      | 8679  | 5.51055  |   |
| 6  | [M+H-NH3]+   | 1882  | 1.19494  |   |
| 7  | [M+NH4]+     | 1161  | 0.73715  |   |
| 8  | [M-H-H2O]-   | 545   | 0.34604  |   |
| 9  | [M-H+2Na]+   | 519   | 0.32953  |   |
| 10 | [M-H+H2O]-   | 386   | 0.24508  |   |
| 11 | [M+NH4-H2O]+ | 362   | 0.22984  |   |
| 12 | [M+H+H2O]+   | 306   | 0.19429  |   |
| 13 | [M+H+Na]2+   | 288   | 0.18286  |   |
| 14 | [M+H+K]2+    | 276   | 0.17524  |   |
| 15 | [M-2H]2-     | 220   | 0.13968  |   |
| 16 | [M+2Na]2+    | 217   | 0.13778  |   |
| 17 | [M+2H-NH3]2+ | 216   | 0.13714  |   |
| 18 | [M+K]+       | 215   | 0.13651  |   |
| 19 | [M+H-2H2O]+  | 186   | 0.11810  |   |
| 20 | [M+3H]3+     | 105   | 0.06667  |   |
| 21 | [M+2H-H2O]2+ | 102   | 0.06476  |   |
| 22 | [M]+.        | 93    | 0.05905  |   |
| 23 | [M+2Na-H]+   | 81    | 0.05143  |   |
| 24 | [M-H+2K]+    | 80    | 0.05079  |   |
| 25 | [M+H-CO]+    | 73    | 0.04635  |   |
| 26 | [M+H-CO2]+   | 68    | 0.04318  |   |
| 27 | [M+H-CH2O2]+ | 60    | 0.03810  |   |
| 28 | [M-H-NH3]-   | 59    | 0.03746  |   |
| 29 | [M.Cl]-      | 56    | 0.03556  |   |
| 30 | [M+Li]+      | 49    | 0.03111  |   |

V2.11 entropy mode from previous ensembles?

First off, congrats - 2.11 looks great! I'm very happy that zsort is no longer the default.

I have a large number of previous ensembles. 😄
(https://chemrxiv.org/articles/preprint/Understanding_Conformational_Entropy_in_Small_Molecules/12671027)

I'd like to calculate the new absolute entropies with v2.11. Can I use -forall on an old ensemble?

The preprint seems to suggest that one needs to start with a previous best minima and run a new ensemble?

I guess my question is for Sconf entropy purposes, how different are the CREST 2.10 and 2.11 entropy values? Do I need to re-start my ensembles for more accurate Sconf? (If you don't know, send me an e-mail. I can restart ~10,000 ensembles to compare.)

GFN-FF error (Initial geometry optimization failed)

Hi,

I'm getting the above error when trying to run a crest simulation on a complex of 16 THF molecules (geometry attached). The accompanying xtb.out file (also attached) shows that the GFN-FF topology setup failed (e.g. the qest values are ******). My initial thought was to try including the charges file from a single-point GFN2 calculation, but the result is the same.

What's interesting is that a geometry optimization directly using xtb works. I then tried adding --notopo to the crest input, and this works. I just wanted to check if this is the expected behavior, and whether this approach for handling this error is ok (e.g. will using notopo cause other problems in the results?).

thanks

thf16xyz.txt
xtb.out.txt

MTD convergence error

Hello, While setting initial parameters for MTD, I encounter MTD convergence issue in some systems.
It seems slight modification remedies this issue, but for some case, I constantly get this error message.
If there's any suggested solution to this problem, I'll be very happy to have it!
Many thanks in advance.

Best regards,
Hyunwook


Starting a trial MTD to test settings

Trial MTD 1 did not converge!
Reducing the time step to 4 fs and trying again...

Trial MTD 2 did not converge!
Reducing the time step to 3 fs and trying again...

Trial MTD 3 did not converge!
Reducing the time step to 2 fs and trying again...

Trial MTD 4 did not converge!
Reducing the time step to 1 fs and trying again...

Trial MTD 5 did not converge!
Time step can`t be reduced further!
Trying to turn SHAKE off...

Trial MTD 6 did not converge!
Automatic xtb restart failed 6 times!
Please try other settings by hand.

question.zip

Segmentation fault encountered while testing the installation

Thank you for sharing the cool program. From the documentation, I found that crest has a lot of useful functions, and I was eager to try. My xtb version is 6.4.0, crest version is 2.11, both the newest version, and I set the OMP_STACKSIZE=5G, ulimit is unlimited. But unfortunately, some weird error happened.
My operate is quite simple:
$ crest conf.xyz
The metadynamics processes went well, but once the program began to optimize geometric data, a segmentation fault occurred:

......(skipping the MTD output)
*Meta-MTD 6 finished*
 
-----------------------
Multilevel Optimization
-----------------------
 
 -------------------------
 1. crude pre-optimization
 -------------------------
 Optimizing all 686 structures from file "crest_rotamers_0.xyz" ...
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
crest              00000000024FA974  Unknown               Unknown  Unknown
crest              00000000026CAF50  Unknown               Unknown  Unknown
crest              00000000026BD6A5  Unknown               Unknown  Unknown
crest              0000000002552B7A  Unknown               Unknown  Unknown
crest              0000000000533D3A  Unknown               Unknown  Unknown
crest              0000000002634F43  Unknown               Unknown  Unknown
crest              00000000025EC080  Unknown               Unknown  Unknown
crest              00000000025EB305  Unknown               Unknown  Unknown
crest              0000000002635309  Unknown               Unknown  Unknown
crest              00000000026C7B8E  Unknown               Unknown  Unknown
crest              0000000002738599  Unknown               Unknown  Unknown

I searched on Google as well as Github for similar errors for hours but found nothing fruitful, thus I'm seeking your help, thank you so much.

reproducing published xtb --reactor ferrrocene decomposition example

I would like to reproduce the examples of ferrocene decomposition in https://pubs.acs.org/doi/10.1021/acs.jctc.9b00143 which used xtb's nanoreactor option. For the ferrocene example, tau_MTD was specified as 2ps. xtb's documentation say that the --reactor option is depreciated, and to use crest --nci.

crest start.xyz -nci -ewin 120 -temp 6000 -len 100 -tstep 2000 -shake 0 --verbose
This gives unreasonably fast output that then crashes in seconds with "forrtl: severe(24) [...]"

If I set -tstep to 200 or 20 fs, the initial MTDs do not finish, and CREST prompts me to manually try other values. If I set -tstep to 2fs, the crest algorithm is proceeding, but there is no conformers with extreme bond rearrangement like in the paper.

Can someone explain how to reproduce the ferrocene nanoreactor?

Crest 2.11 does not build due to missing file

Trying to build crest 2.11 for Fedora using meson I get the error

meson.build:44:0: ERROR: File combi-scripts/crest_combi does not exist.

This file does not appear to exist even in the git source tree

Feature Request: export mapping file for the Molecular prototropy screening

It might be desirable to know not only what is possible protomer, deprotomer, and tautomer but also their relationship to the original input molecule, given that topology checking is already in place.
I purpose that for each output molecule a mapping file could be created. Possible format could be

15
Element    input_index              output_index
O               1              14
O               2              13
N               3             12
C               4              11
C               5              10
C               6              9
C               7              8
C               8              7
C               9              6
C               10             5
C               11              4
H               -                3
H               12              2
H               13              1
H               14              -

where the atom index 3 hydrogen in the output is not present in the input molecule and the atom index 15 hydrogen in the input file is not present in the output molecule.

2.11dev -nci and xtb 6.3.3 report different wall ellipsoids

When using the -nci option in dev 2.11, I get different ellipsoidal wall potential extents in the crest output and in the xtb.out files in the MRSD and METADYN folders. Should I see the same wall ellipsoids?

As an aside, these are -alpb runs but the xtb.out SETUP block still refers to GBSA solvation

Here's what Crest reports:

Version 2.11dev, Mon 21. Sep 10:32:08 CEST 2020
Using the xTB program. Compatible with xTB version 6.3.3
  ...

 Command line input:
 > crest CB8.xyz --alpb h2o -nci -mdlen 10 -prop hess -keepdir

  --alpb h2o : implicit solvation
  -nci  : Special NCI mode for non-covalently bound complexes or clusters.
  -mdlen 10 (MD length in ps)
  Automatically generated ellipsoide potential for NCI mode:
> $wall
>   potential=polynomial
>   ellipsoid: 26.17098323398868, 25.47742318900227, 22.69385251208020, all

and here is the corresponding MRMSD/xtb.out from the same run:

    * xtb version 6.3.3 (5b13467) compiled by 'ehlert@majestix' on 2020-09-17
           -------------------------------------------------
          |                Calculation Setup                |
           -------------------------------------------------

          program call               : xtb coord --gfn2 --md --alpb h2o
          coordinate file            : coord
          omp threads                :                     8
          number of atoms            :                   144
          number of electrons        :                   496
          charge                     :                     0
          spin                       :                   0.0
          first test random number   :      0.23151118293332

   ID    Z sym.   atoms
    1    8 o      1, 9, 16, 23, 30, 37, 44, 51, 60, 65, 70, 75, 80, 85, 90, 96
    2    6 c      2, 4, 5, 7, 8, 11, 12, 14, 15, 18, 19, 21, 22, 25, 26, 28,
                  29, 32, 33, 35, 36, 39, 40, 42, 43, 46, 47, 49, 50, 53, 54,
                  56, 58, 59, 62, 64, 67, 69, 72, 74, 77, 79, 82, 84, 87, 89,
                  92, 94
    3    7 n      3, 6, 10, 13, 17, 20, 24, 27, 31, 34, 38, 41, 45, 48, 52,
                  55, 57, 61, 63, 66, 68, 71, 73, 76, 78, 81, 83, 86, 88, 91,
                  93, 95
    4    1 h      97-144
ellipsoidal wallpotenial with radii   13.8490892 Å   13.4820730 Å   12.0090707 Å
########################################################################
[WARNING] Please study the warnings concerning your input carefully
-1- set_rdsetbl: Set-blocks will become obsolete in xtb 6.0 and newer
########################################################################

           -------------------------------------------------
          |                 G F N 2 - x T B                 |
           -------------------------------------------------

        Reference                      10.1021/acs.jctc.8b01176
      * Hamiltonian:
        H0-scaling (s, p, d)           1.850000    2.230000    2.230000
        zeta-weighting                 0.500000
      * Dispersion:
        s8                             2.700000
        a1                             0.520000
        a2                             5.000000
        s9                             5.000000
      * Repulsion:
        kExp                           1.500000    1.000000
        rExp                           1.000000
      * Coulomb:
        alpha                          2.000000
        third order                    shell-resolved
        anisotropic                    true
        a3                             3.000000
        a5                             4.000000
        cn-shift                       1.200000
        cn-exp                         4.000000
        max-rad                        5.000000

      * Solvation model:               ALPB
        Solvent                        h2o
        Parameter file                 internal GFN2-xTB/ALPB
        Dielectric constant                8.0200E+01
        Reference state                gsolv [1 M gas/solution]
        Free energy shift                  4.1166E-04 Eh       2.5832E-01 kcal/mol
        Temperature                        3.0000E+02 K
        Density                            1.0000E+00 kg/L
        Solvent mass                       1.8000E+01 g/mol
        Interaction kernel             P16
        Born radius scaling (c1)           1.3972E+00
        Born radii integrator          GBOBC
        Born offset                        3.8318E-02 a0       7.2411E-02 AA
        H-bond correction              true
        Ion screening                  false
        Surface tension                    1.0000E-05 Eh       1.5569E+01 dyn/cm
        Grid points                               974 per atom

          ...................................................
          :                      SETUP                      :
          :.................................................:
          :  # basis functions                 432          :
          :  # atomic orbitals                 432          :
          :  # shells                          240          :
          :  # electrons                       496          :
          :  max. iterations                   250          :
          :  Hamiltonian                  GFN2-xTB          :
          :  restarted?                      false          :
          :  GBSA solvation                   true          :
          :  PC potential                    false          :
          :  electronic temp.          300.0000000     K    :
          :  accuracy                    1.0000000          :
          :  -> integral cutoff          0.2500000E+02      :
          :  -> integral neglect         0.1000000E-07      :
          :  -> SCF convergence          0.1000000E-05 Eh   :
          :  -> wf. convergence          0.1000000E-03 e    :
          :  Broyden damping             0.4000000          :
          ...................................................

CREST crashes when a large number of conformers are generated

I'm finding that CREST crashes wth some jobs that generate a large number of conformers. In particular, I have attached the .xyz file of a Fe-triphos organometallic compound. The last few lines of the log file are usually:

Starting Meta-MD  12 with the settings:
     MD time /ps        :   135.0
     dt /fs             :     2.0
     dumpstep(trj) /fs  :     100
     dumpstep(Vbias)/ps :     1.0
     Vbias prefactor(k) :  0.1410
     Vbias exponent(α)  :    0.28
*Meta-MD 13 finished*
*Meta-MD 11 finished*
*Meta-MD 14 finished*
*Meta-MD 7 finished*
*Meta-MD 5 finished*
*Meta-MD 8 finished*
*Meta-MD 12 finished*
*Meta-MD 1 finished*
*Meta-MD 10 finished*
*Meta-MD 2 finished*
*Meta-MD 9 finished*
*Meta-MD 3 finished*
*Meta-MD 6 finished*
*Meta-MD 4 finished*
 
-----------------------
Multilevel Optimization
-----------------------
 
 -------------------------
 1. crude pre-optimization
 -------------------------

The error message obtained is:

error while reading coord line

The version of CREST is 2.10.2, and XTB is 6.3.3. My job run-script is as follows:

export MKL_NUM_THREADS=28
export OMP_THREAD_LIMIT=28
export OMP_NUM_THREADS=${OMP_THREAD_LIMIT},1
export OMP_STACKSIZE=2G
ulimit -s unlimited

crest coords.xyz -gfnff > crest.log

The above calculation was run with gfnff, but this error typically also occurs with gfn1 and gfn2
coords.zip

crest with gfnff for intermolecular complexes has problem with charges

Describe the bug
Crest crashes when GFN-FF is used for intermolecular complexes together with specification of charge and/or multiplicity. I am using the pre-compiled version 2.10.1 together with the pre-compiled version 6.3.0 of xtb. Here are the files: xtb.zip

To Reproduce
Steps to reproduce the behaviour:

  1. XYZ with more than one molecule (see mol.xyz in the example).
  2. Run crest mol.xyz -chrg 0 -uhf 0 -gfnff -nci -mquick -opt loose and the job crashes.
  3. The outputs crest.out and xtb.out are provided in the ZIP file.
  4. Run crest mol.xyz -gfnff -nci -mquick -opt loose and everything runs fine (after purging the folder of files from the previous run).

Problems with energy threshold between conformers

I am trying to perform a conformer search on octane. The resulting energy differences between some conformers are very small (see below) and visual inspection shows that these conformers are the same. Using the -ethr option gives exactly the same result irrespective of the chosen value.
Here is the first part of the .energies file:
1 0.000
2 0.544
3 0.556
4 0.558
5 0.564
6 1.024
7 1.024
8 1.024
9 1.025

I am using crest version 2.10.2 and observed the same phenomenon also for other molecules.
Thanks,
Florian

About using ORCA for DFT calculations in Calculation of absolute molecular entropies and heat capacities made simple paper

I was reading the recent paper of "Calculation of absolute molecular entropies and heat capacities made simple" and the higher level DFT calculations are done using TURBOMOLE.
Given that TURBOMOLE is commercial software and might not be available to anyone. I wonder if it is possible to use support ORCA?
Since it also has the level of B97-3c and of course B3LYP-D3(BJ)/def2-TZVP with RIJCOSX support.

Wrong license in README

Quick heads up - In the README you refer to the GNU Lesser General Public License under the License section, but the LICENSE file is GPL (which of course is the correct license).

can I use the ALPB solvation mode in crest?

The analytical linearized Poisson-Boltzmann (ALPB) model is the default solvation model for xtb-6.3.3. I wonder how can I use ALPB in crest? if not, I guess some change may be needed in crest's code.
thanks.

[Proposed enhancement] Aligning structures in crest_conformers

Hello CREST team,

I was wondering if it might be possible for CREST to align the output structures in crest_conformers just before the end of the run. In my experience, the output structures are usually randomly oriented (presumably depending on which MTD run they originated from, and how they were optimized).

I cannot comment on all use cases, but especially for systems like peptides/proteins, having the conformers all aligned in some way (e.g. RMSD, like how VMD does it) might help users contrast features between conformers more easily. Sometimes two conformers are really similar except for a local region, but it is not obvious if the two conformers are oriented differently, unless the user manually aligns them.

I hope I'm making sense - thank you!

Marcus

Allow crest to use ALPB solvent model

Is your feature request related to a problem? Please describe.
Given that the ALPB solvent model is the default solvent model in xtb 6.3.3. It might be useful to update the crest such that it will use ALPB solvent model as well.

Describe the solution you'd like
Allow crest to use the -alpb flag or deprecate the -gbsa/-g flag and replace it with alpb.

Save MTD bias potentials for later runs

When running multiple crest ensemble calculations on the same molecule, each run essentially starts from zero, with no biasing in the metadynamics. Would it make sense to have the option to save the bias potentials added in a crest run to be reused in future runs?

SAS scaling and pKa calculations

I wonder if it will be possible (or is already) to scale solvent accessible surfaces (SAS) or van der Waals radii? Similar to this approach for calculation of pKa values:

Quantum Chemical Calculation of pKas of Environmentally Relevant
Functional Groups: Carboxylic Acids, Amines and Thiols in Aqueous Solution

https://pubs.acs.org/doi/10.1021/acs.jpca.8b01751

Will there be a pKa switch or external routine to calculate pKa values (similar to mopac pka switch)?

Having a reference value for protonation

It is nice that crest allows the user to protonate or deprotonate a molecular and give the energy for that. However, I think in most cases, it is more interesting to know whether the energy difference of adding a proton is larger or smaller than adding a proton to the water in gbsa water. I wonder if there is any reference value for a proton addition under gbsa water at gfn2 level?

restarting stopped crest job?

Hello,

I'm running crest on a large and rather flexible system, and although I'm close to finishing after 7 days the cluster automatically kills my job. Is there any way I can restart crest from where I left off? If I just rerun the script in the same working directory, will it delete all my old data?

Thanks,
Corin

searches are slower in 2.11 than in 2.10.2

Hello,

In every case I've examined, I'm getting longer computation times for crest 2.11 runs versus 2.10.2. I've simplified things by focusing on a small example for testing purposes, with initial geometry:

23

  O   -2.4826000    0.0073000    0.1112000
  O    2.4266000   -1.9214000    1.5577000
  O    0.4724000   -2.2815000    2.1394000
  N   -0.5988000   -0.9313000    0.0784000
  N   -1.2670000    2.2601000    1.2896000
  C    0.7790000   -1.1909000    0.0675000
  C   -0.7769000    1.5531000    0.0983000
  C   -1.2718000    0.1806000    0.0953000
  C    1.0879000   -2.0511000   -1.1809000
  C   -1.1674000    2.3432000   -1.1707000
  C    1.2311000   -1.8237000    1.2990000
  H    1.3752000   -0.2848000   -0.0509000
  H    0.3093000    1.6049000    0.1603000
  H   -1.1261000   -1.7060000    0.0663000
  H    0.8079000   -1.5128000   -2.0900000
  H    0.5372000   -2.9945000   -1.1577000
  H    2.1546000   -2.2753000   -1.2487000
  H   -0.8189000    1.8310000   -2.0703000
  H   -0.7083000    3.3341000   -1.1509000
  H   -2.2499000    2.4704000   -1.2356000
  H   -0.8858000    1.7848000    2.1104000
  H   -0.8626000    3.1991000    1.2712000
  H    3.0351000   -1.5952000    1.0111000

This takes around 9 min in 2.10.2 and 18 min in 2.11. I've noticed that more structures in each iteration, and sometimes more MTD iterations, etc. are used in 2.11. Here's some associated output:

2.10.2:
 515 structures remain within    12.00 kcal/mol window
 57 structures remain within     6.00 kcal/mol window
 510 structures remain within    12.00 kcal/mol window
 159 structures remain within     6.00 kcal/mol window
 199 structures remain within     6.00 kcal/mol window
 206 structures remain within     6.00 kcal/mol window
conformer energy window  /kcal :    6.00
 # in E window                206
 62 structures remain within    10.00 kcal/mol window
 212 structures remain within     6.00 kcal/mol window
 conformer energy window  /kcal :   6.0000
2.11:
 655 structures remain within    12.00 kcal/mol window
 31 structures remain within     6.00 kcal/mol window
 Increasing energy window to include more...
 157 structures remain within     9.00 kcal/mol window
 550 structures remain within    12.00 kcal/mol window
 42 structures remain within     6.00 kcal/mol window
 676 structures remain within    12.00 kcal/mol window
 186 structures remain within     6.00 kcal/mol window
 672 structures remain within    12.00 kcal/mol window
 166 structures remain within     6.00 kcal/mol window
 678 structures remain within    12.00 kcal/mol window
 163 structures remain within     6.00 kcal/mol window
 401 structures remain within     6.00 kcal/mol window
 411 structures remain within     6.00 kcal/mol window
conformer energy window  /kcal :    6.00
 # in E window                411
 28 structures remain within    10.00 kcal/mol window
 386 structures remain within     6.00 kcal/mol window
 conformer energy window  /kcal :   6.0000

Is it possible for me to use keywords to change the defaults so as to get times more similar to what 2.10.2 produces?

I noticed in the release notes for the development version of 2.11: "Defaults for ensemble sorting thresholds have been changed slightly (ethr = 0.05 kcal/mol, was 0.1 kcal/mol; bthr = 1%, was 15.0 MHz)". Accordingly, I tried ethr values of 0.1 and 0.11, and this seems to decrease the times somewhat, but both cases result eventually in "no convergence in svdcmp". I also tried using --v2i, and this finishes in 7 min, but produces only 4 conformers, compared to 45 for 2.10.2 and 80 for default 2.11.

thanks

CREST with GFNFF and comparing with GFN2-xTB level.

I'm dealing with conformers of radical species with long chain.
I believe conformer sampling is very important issue only fraction of conformers would be accessible in certain temperature.
If I run CREST with normal gfn2-xtb level, initial connectivity in geometry is not preserved especially for radical species (-uhf 1)
I used gfnff option to avoid this problem, but I'm questioning the reliability of FF level theory in terms of energy output.

Since the output of GFNFF conformer ensemble file is not directly comparable using -compare option due to energy difference, I additionally run -screen for GFNFF ensemble.
Subsequently, I tried comparing two ensembles: one from crest with gfn2-xtb and the other from gfnff.
However, I'm confused while interpreting the result I got in this step.
When two ensembles are compared energy seems similar but RMSD threshold with 0.125 Angs. results in only one pair as identical in geometry.

Please find attached ensemble files:
cal.xyz -> original molecule (which is a radical)
conf_gfnff.xyz -> ensemble from GFNFF
conf_xtb.xyz -> ensemble from xTB
rmsdmatch.dat , stdout.log -> output files

Question is:

  1. Do I need to increase RMSD threshold when comparing large molecule like in this case? (Numatom = 94) Should default 0.124 A should be used or should it be larger depending on molecular size?

  2. attached result seems to indicate that only 16 & 18 from each ensemble is identical with RMSD threshold 1.0 A. Is it correct interpretation? If so, doesn't it mean that GFNFF and xTB results are far different?

  3. Then, can I rely on the conformer energy distribution obtained from GFNFF or additional -screen process at lease in xTB level is necessary?

My question might not well written, I'll further clarify if there's any confusing point.
Many thanks in advance.

question.zip

Parallel version on specific .xyz file fails (please close)

Edit: it seems I have a problem with the set up of my parallel system. This issue is not one of the program.

Hi,

just wanted to let you know that crest -T 2 h2s2.xyz fails (2 can be also n >= 2 threads) where h2s2.xyz is

4

S          0.94338       -0.04130        0.02811
S          2.98706        0.12675        0.03472
H          0.61504        1.25881        0.07922
H          3.31540       -1.17336       -0.01639

The serial version succeeds to generate conformers.

Thanks for the program and bye!

File already opened in another unit

Hello,

I'm trying to run the example with the latest version of CREST (I just downloaded the repository and compiled it), but I get an error:


       ==============================================
       |                                            |
       |                 C R E S T                  |
       |                                            |
       |  Conformer-Rotamer Ensemble Sampling Tool  |
       |          based on the GFN methods          |
       |             P.Pracht, S.Grimme             |
       |          Universitaet Bonn, MCTC           |
       ==============================================
       Version 2.11, Mon 19. Apr 11:43:20 CEST 2021
  Using the xTB program. Compatible with xTB version 6.4.0

   Cite work conducted with this code as

   P. Pracht, F. Bohle, S. Grimme, PCCP, 2020, 22, 7169-7192.

   and  S. Grimme, JCTC, 2019, 15, 2847-2862.

   with help from:
   C.Bannwarth, F.Bohle, S.Ehlert, S.Grimme,
   P.Pracht, S. Spicher

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 Command line input:
 > /home/pierre/code/crest/build/crest test2.xyz -gfn2 -g h2o

  -gfn2 : Use of GFN2-xTB requested.
  --gbsa h2o : implicit solvation

 -------------------------
 xTB Geometry Optimization
 -------------------------
 Geometry successfully optimized.
At line 85 of file ../src/iomod.F90
Fortran runtime error: File already opened in another unit

Error termination. Backtrace:
#0  0x7f40cdbfed51 in ???
#1  0x7f40cdbff8a9 in ???
#2  0x7f40cdc0030f in ???
#3  0x7f40cde1f9f3 in ???
#4  0x7f40cde1fd9c in ???
#5  0x487138 in ???
#6  0x44201a in ???
#7  0x52b60e in ???
#8  0x40375c in ???
#9  0x7f40cd8b91a2 in ???
#10  0x40379d in ???
#11  0xffffffffffffffff in ???

I don't know if it is related to CREST or xtb :)

Note that I compiled with gcc (because it is with my own machine) under Linux (Fedora 30), with mkl.

Crest performance in Windows Subsystem for Linux/Ubuntu

I've been using crest in Ubuntu in the WSL in Windows 10 for almost a year without any issues. I THINK a recent Windows Update has significantly slowed it down in the last week or so. I think the Windows update is KB5003637.

I have a Fedora 33 box and a Windows 10 box, both running a Core i7-4770 or 4770s with 12 or 16 GB of ram with an SSD, and historically, the performance in WSL has been highly comparable between the two.

Has anyone else that runs crest/xtb within WSL observed this in the last couple weeks?

CREST on macOS

Hi,
I was wondering whether it will be possible to use CREST/xtb on Mac OS X?

Thank you

Crest use

Dear sirs,

I am trying to use Crest for my research in supramolecular cages and I cannot get it to work. The crest output file does not look as the one in the example. I tried many times to change the command line as I am not sure if it is correct. Unfortunately, the calculation stops after 7 seconds and the output file does not show any errors.
I would be very happy for any help on this.

Thanks in advance

Kind regards
Valentinos

conda-forge package?

The conda-forge package for xtb has been very useful (e.g., providing Mac binaries) - will there be a package for crest (or bundling crest with the xtb conda-forge channel)?

All caps element symbols in xyz files generated by CREST

Describe the bug
The xyz files generated by CREST (e.g. crest_best.xyz) have the element symbols in all caps. As a consequence, tools like Open Babel cannot correctly interpret these xyz files.

To Reproduce
Steps to reproduce the behaviour:

  1. Create inp.xyz.
  2. Run crest inp.xyz
  3. Open crest_best.xyz with a text editor.

Expected behaviour
Nickel should be written as Ni instead of NI

Inconsistent molecular structure before and after CREST

Hello, thank you for developing such a useful tool like gfn2-xtb and crest.
I'm using crest version 2.9 along with gfn2-xtb version 6.2.3.

While using crest for conformer search of a hydrocarbon chain, I've discovered that original molecular structure has not been preserved after crest job.
Following is an example.
"cal.xyz" is initial molecule before conformer search and "crest_best.xyz" is the output of crest job.
As can be found in the attached xyz file, weird CO2 molecule has been produced after crest.
Also following is my input command to run the job.

"crest cal.xyz -uhf 1 "
I want molecular structure (molecular connectivity) to be preserved but it seems to give false structure.
Probably the output structure might be thermodynamically more stable compared to input structure but this result defeats the purpose of conformer search.
Could anyone explain the reason or how I can circumvent this?
Many thanks in advance!

Crest_job.zip

[support] Parallelization and speedup options for medium-large systems

I'm currently working on a organometallic system (170 atoms, 7 heavy non-metals, 3 metals) at the GFN2-xTB level. The CREST runs even with squick take a long time, and I find myself running up against the 1-week limit on my compute cluster. I have two questions about speeding up computations:

  1. I've been trying to increase the memory and number of cores, and I noticed when going up to 30 cores and 30 GB/core (OMP_STACKSIZE="30000m", OMP_NUM_THREADS="30") that the output still shows Estimated runtime for a batch of 6 MTDs on 4 threads. Even if one MTD can only be run on one thread, shouldn't CREST be using at least 6 threads? Or is CREST using bundles of 7 threads for each MTD?
  2. I have had good experiences with GFN-FF with other systems in the past, both with speed and quality, but the geometries just don't look reasonable in this case - are there any recommended settings to explore?

Thanks very much!

-Marcus

Support for GFN0

It seems that for the devel version of crest the gfn0 is excluded from the help menu.

~/src/xtb-6.3.3/bin/crest -h

 
       ==============================================
       |                                            |
       |                 C R E S T                  |
       |                                            |
       |  Conformer-Rotamer Ensemble Sampling Tool  |
       |          based on the GFN methods          |
       |             P.Pracht, S.Grimme             |
       |          Universitaet Bonn, MCTC           |
       ==============================================
       Version 2.11dev, Tue 13. Oct 10:57:46 CEST 2020
  Using the xTB program. Compatible with xTB version 6.3.3
 
   Cite work conducted with this code as

   P. Pracht, F. Bohle, S. Grimme, PCCP, 2020, 22, 7169-7192.

   and

   S. Grimme, JCTC, 2019, 15, 2847-2862.
 
   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 Command line input:
 > /biggin/b120/grte2001/src/xtb-6.3.3/bin/crest -h

 
 usage        :
 crest [options]
 
 The FIRST argument CAN be a coordinate file in the
 TM (coord, Bohr) or Xmol (*.xyz, Ang.) format.
 If no such file is present as the first argument crest will
 automatically search for a file called "coord" in the TM format.

 General options:
     -v1                : use the MF-MD-GC workflow. (outdated)
     -v2                : use the MTD-GC workflow. (outdated)
     -v3 (or -v2i)      : use the iMTD-GC workflow. [default]
     -g <string>        : use GBSA implicit solvent
                          for solvent <string>
     -alpb <string>     : use GBSA implicit solvent
                          for solvent <string>
     -chrg <int>        : set the molecules´ charge
     -uhf <int>         : set <int>=Nα-Nβ electrons
     -nozs              : do not perform z-mat sorting,
                          default: z-matrix will be sorted
     -zs                : perform z-matrix sorting. [default]
     -opt <"lev">       : set opt. level for ALL GFN-xTB
                          optimizations.
                          <lev>=vloose,loose,normal,tight,vtight
                          [default: vtight]
     -gfn1              : use GFN1-xTB
     -gfn2              : use GFN2-xTB [default]
     -gff, -gfnff       : use GFN-FF (requires xtb 6.3 or newer)
     -gfn2//gfnff       : GFN2-xTB//GFN-FF composite mode)
     -xnam <"bin">      : specify name of the xtb binary
                          that should be used.
     -ewin <real>       : set energy window in kcal/mol,
                          [default: 6.0 kcal/mol]
     -rthr <real>       : set RMSD threshold in Ang,
                          [default: 0.125 Ang]
     -ethr <real>       : set E threshold in kcal/mol,
                          [default: 0.05 kcal/mol]
     -bthr <real>       : set Rot. const. threshold ,
                          [default: 0.01 (= 1%)]
     -pthr <real>       : Boltzmann population threshold
                          [default: 0.05 (= 5%)]
     -eqv               : activate NMR-equivalence printout
     -nmr               : activate NMR mode
                          (= [-eqv] + opt.level: vtight)
     -prsc              : create a scoord.* file for each conformer
     -niceprint         : progress bar printout for optimizations
     -dry               : perform a "dry run". Only prints the settings
                          that would be applied with the CMD input
                          and stops the run before any calculations
 
 
 Options for iMTD-GC workflow:
     -cross             : do the GC part [default]
     -nocross           : don´t do the GC part
     -shake <int>       : set SHAKE mode for MD
                          (0=off,1=H-only,2=all bonds) [default: 2]
     -tstep <int>       : set MD time step in fs
                          [default: 5 fs]
     -mdlen/-len <real> : set MD length (all MTDs) in ps
     -mddump <int>      : xyz dumpstep to Trajectory in fs
                          [default: 100 fs]
     -vbdump <real>     : set Vbias dump frequency in ps
                          [default: 1.0 ps]
     -tnmd <real>       : set temperature for additional normal MDs
                          [default: 400 K]
     -norotmd           : don´t do the regular MDs after the 
                          second multilevel optimization step
     -quick             : perform a search with reduced settings
                          for a crude ensemble.
     -squick            : perform a even further reduced search
     -mquick            : perform a search with maximum reduced settings
                          (do not reduce the settings more than that)
     -origin            : track the step of generation for
                          each conformer/rotamer. [default]
     -keepdir           : keep sub-directories of the conformer
                          generation step.
     -nci               : generate an ellipsoide potential around the
                          input structure and add it to the MTD simulation.
                          This can be used to find aggregates of NCI complexes.
     -pscal <real>      : scale the ellipsoide potential axes by factor <real>.
 
 
 Options for ZSORT standalone use:
     -zsort             : use only the zsort subroutine
                          to sort the z-matrix of the input
                          coord file.
 Options for MDOPT functionality usage:
     -mdopt <file>      : optimize along trajectory or
                          ensemble file in the XYZ format.
                          Each point on the file is optimized.
 Options for SCREEN functionality usage:
     -screen <file>     : optimize along ensemble file
                          in the XYZ format. A multilevel
                          optimization is performed with continiously
                          increasing thresholds. After each step
                          the ensemble file is sorted.
 Options for other automatized scripts:
     -protonate         : find a molecules protomes by using a
                          LMO π- or LP-center approach.
     -deprotonate       : find a molecules deprotomers.
     -tautomerize       : combine the protonation and deprotonation
                          to find prototropic tautomers.
     -trev              : do first the deprotonation and then the
                          protonation in the -tautomerize mode, i.e.,
                          reverse of the default procedure.
     -ewin <real>       : set energy window for scripts in kcal/mol,
                          [default: 30.0 kcal/mol]
     -iter <int>        : set number of protonation/deprotonation cycles
                          in the tautomerization script. [default: 2]
 Options for CREGEN standalone use:
     -cregen [file]     : use only the cregen subroutine
                          to sort a given ensemble file.
     -compare <f1> <f2> : compare two ensembles <f1> and <f2>.
                          Both ensembles must have the same
                          order of atoms of the molecule and
                          should contain rotamers.
     -maxcomp <int>     : Selcect the lowest <int> conformers
                          out of each ensemble to be compared
                          with "-compare". [default: 10]
 usage of the following options recommended
 only in combination with [-cregen] option:
     -temp <real>       : set temperature
                          default: 298.15 K
     -nowr              : don´t write new ensemble files
     -eqan              : perform equivalence analysis
     -noeqan            : do not perform equ. analysis
                          (default)
     -rot               : use only rot. constant for
                          checks (and no RMSD)
 
 
 Options for parallelization:
     -T <int>           : Set total number of CPUs(threads)
                          to be used. Parallel settings are then
                          determined automatically for each step.
                          If not set by "-T", this number is read
                          from the OMP_NUM_THREADS global variable.
 
 
 Adding additional constraints to the calculations:
     The user is able to include additional constraints to all
     xtb calculations that are conducted by CREST.
     To do this one has to create a file called ".constrains", which
     can contain the constraints in the same syntax as used by the xtb.
     Refer to the xtb documentation for more information.
     !! Constraints that are included via the .constrains file !!
     !! will be included in ALL calculations of the run.       !!
     !! Since this can overwrite settings created by CREST,    !!
     !! it should only be used very cautiously!                !!
 
 View literature references with [--cite]
 Also refer to:
 https://xtb-docs.readthedocs.io/en/latest/crest.html
 
   [-h] displayed. exit.

CREGEN conformer symmetry analysis missing from dev v2.11

I've just had a look at the dev version of 2.11 and xtb 6.3.3 (thanks!) to compare the new alpb solvation model with gbsa, using the following:

crest G1.xyz -chrg 1 -alpb h2o -mdlen 10 -nci -prop hess -keepdir > G1_crest_10_alpb_nci.out &

The corresponding run with 2.10.2 & 6.3.2 with -gbsa instead of -alpb has the CREGEN - CONFORMER SYMMETRY ANALYSIS output in the position shown below, but this is now missing.
Can we have it back please?

******************************************************************************************
**                     P R O P E R T Y   C A L C U L A T I O N                          **
******************************************************************************************
 writing TMPCONF* Dirs from file "crest_conformers.xyz" ... done.
 ---------------------------------------
 Hessian calculations for all conformers
 ---------------------------------------
 Performing calculations for 14 structures ...
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 
 done.
 running RMSDs...
 done.
  
<<<<<<<<<< CREGEN - CONFORMER SYMMETRY ANALYSIS missing from here
.
.
.
.

 -----------------
 Wall Time Summary
 -----------------
             test MD wall time :         0h : 0m :12s
                 MTD wall time :         0h :10m : 0s
      multilevel OPT wall time :         0h :37m :26s
      PROPERTY calc. wall time :         0h : 1m :10s
--------------------
Overall wall time  : 0h :50m :34s
 
 CREST terminated normally.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.