grimme-lab / enso Goto Github PK

View Code? Open in Web Editor NEW

10.0 4.0 8.0 143 KB

energetic sorting of conformer rotamer ensembles

Home Page: https://xtb-docs.readthedocs.io/en/latest/enso_doc/enso.html

License: GNU Lesser General Public License v3.0

Python 99.61% Shell 0.39%

quantum-chemistry computational-chemistry nmr-spectroscopy

enso's Introduction

ENSO program

This is the official repository of the ENSO program developed by the Grimme group in Bonn. Program for refining conformer-rotamer-ensembles (CRE), generated by CREST, at DFT level.

All resources (ENSO, ANMR, NMRPLOT) can be found at the latest release page. ANMR is currently only distributed as statically compiled binary!

Installing

Make sure that python3 is available on your machine. xTB and CREST have to be available and at least one QM-package (TURBOMOLE version >= 7.2 or ORCA version >= 4) has to be installed on your setup.

Documentation

Documentation is provided at read-the-docs.

Citation

Currently cite:

S. Grimme, C. Bannwarth, S. Dohm, A. Hansen, J. Pisarek, P. Pracht, J. Seibert, F. Neese Angew. Chem. Int. Ed., 2017, 56, 14763-14769. DOI: 10.1002/anie.201708266

License

ENSO 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.

ENSO 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.

nmrplot.py 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.

nmrplot.py 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.

ANMR is distributed the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.

Bugs

please report all bugs with an example of in- and output and open an issue.

enso's People

Contributors

Stargazers

Watchers

Forkers

awvwgk qize fabothch sibo souzatjt icamps pk-organics computational-chemistry-research

enso's Issues

ridft issue?

I just installed enso with DEMO version of turbomole.

It turns out to have issue below:

Traceback (most recent call last):
File "../enso.py", line 12232, in
main(argv=None)
File "../enso.py", line 12139, in main
) = enso_startup(cwd,argv)
File "../enso.py", line 9288, in enso_startup
error_logical = input_object.processQMpaths(args, error_logical)
File "../enso.py", line 8368, in processQMpaths
print(' TURBOMOLE: {}'.format(os.path.dirname(tmpath)))
File "/home/jzhang/anaconda3/envs/enso/lib/python3.7/posixpath.py", line 156, in dirname
p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType

I checked the code around enso.py line 8368:

        if needtm:
            tmpath = shutil.which('ridft')
            print(type(tmpath),tmpath)
            print('    TURBOMOLE:    {}'.format(os.path.dirname(tmpath)))

Is it because the system can not find ridft? I can not find anywhere that I can install it. Is it because of the demo version?

Thanks very much for your help!

extraction of coupling

Hi, anybody wrote a script to extract properly the coupling constant for ANMR???
Otherwise I can do it?

CHeers

xtb as driver for parallel ORCA

Hello enso team,

I am trying to use enso and ORCA to refine a crest ensemble at the DFT level (part 1, 2, 3). Unfortunately the procedure fails in part 1, where for each calculation, I get an ORCA error:

--------------------------------------------------------------------------
There are not enough slots available in the system to satisfy the 16 slots
that were requested by the application:
  /gpfs/loomis/apps/avx/software/ORCA/4.2.1-OpenMPI-2.1.2/orca_gtoint_mpi

Either request fewer slots for your application, or make more slots available
for use.
--------------------------------------------------------------------------

ORCA finished by error termination in GTOInt
Calling Command: mpirun -np 16  /gpfs/loomis/apps/avx/software/ORCA/4.2.1-OpenMPI-2.1.2/orca_gtoint_mpi inp.int.tmp inp 
[file orca_tools/qcmsg.cpp, line 458]: 
  .... aborting the run

[file orca_tools/qcmsg.cpp, line 458]: 
  .... aborting the run

I was able to get the same error simply by running one instance of xtb as a driver for ORCA:
xtb coord --opt crude --orca
even though I allocated the correct number of processors to xtb. As I have encountered this error when setting up ORCA to be run in parallel, I suspect that this error is related to how xtb is calling and passing MPI paths to ORCA, or to how I am specifying paths in the submit script.

I've attached the enso output file (enso.out), slurm submit script (slurm_enso.sh) from the enso run. Also attached are the xtb coordinate input file (coord) and ORCA input (inp) for a test case using xtb as an ORCA driver.

Thank you!

Marcus

slurm_enso.sh.txt
enso.out.txt
inp.txt
coord.txt

ANMR issue when encountering more than > 999 conformers

I've been following the usage in the documentation example for calculating NMR shifts and couplings, using crest, censo and anmr. That seems to work very well, but I recently encountered an error with anmr:

The error found in error.anmr is:

ERROR file not found, read error!

Looking at the last output of anmr.out, I find that it is writing the tmpanmr.* files:

reading J/sigma data for conformer 1022
[...]
file:^L^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@nmrprop.dat

This is the first conformer with a number above 999 that was selected by censo. I can confirm that the file at CONF1022/NMR/nmrprop.dat exists and it seems to look fine. The previous conformers up until ..., 956, 958, 959 all seem to work as well.

Could it be that anmr cannot handle conformers with four digit numbers?

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Hi all,

I run enso successfully using the example of cis-4-hexen-1-ol. However, i have the netxt error message when I run ANMR:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
anmr 00000000016BD8E4 Unknown Unknown Unknown
anmr 000000000186A290 Unknown Unknown Unknown
anmr 0000000000408263 Unknown Unknown Unknown
anmr 000000000040205E Unknown Unknown Unknown
anmr 000000000186AE60 Unknown Unknown Unknown
anmr 0000000000401F47 Unknown Unknown Unknown

I checked that all the needed files are in the folder. Also, I tested to run previous versions and different workstations, but I always had the same error. Should I set the memory in order to increase the default ? If that the problem, how can i do that?

Thank you in advance

Gabriel
Post-doctoral fellow at LNBio/CNPEM
Campinas, SP, Brazil

Orca Version with 3 digits

Apparently, enso.py does not accept an Orca Version with 3 digits.

Problem:
In .ensorc: ORCA version: 4.2.1

gives:

Traceback (most recent call last):
  File "/home/seibert/bin/enso.py", line 6053, in read_program_paths
    if float(line.split()[2]) < 4.1:
ValueError: could not convert string to float: '4.2.1'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/seibert/bin/enso.py", line 11126, in <module>
    ) = enso_startup(cwd)
  File "/home/seibert/bin/enso.py", line 7722, in enso_startup
    ) = ensorcsettings.read_program_paths(ensorc)
  File "/home/seibert/bin/enso.py", line 6060, in read_program_paths
    if args.prog == "orca" or args.prog4 == "orca":
NameError: name 'args' is not defined

ENSO can't find ORCA

I'm on python 3.8
It looks like I have set up my ~/.ensorc correctly:

.ENSORC

ORCA: /home/henrique/bin/orca
ORCA version: 4.2.1
GFN-xTB: /home/henrique/bin/xtb/bin
CREST: /home/henrique/bin/crest/crest

$ENDPROGRAMS

This is the directory where my orca binary lives but ENSO is not finding ORCA (and looks like it is still looking for Turbomole):

 henrique  ~  teste_nmt  enso  python3 enso.py --checkinput
enso.py:3174: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if args.basisS != "def2-TZVP" and args.funcS is not 'pbeh-3c':
enso.py:3417: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if returncode is not 0:
enso.py:3503: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if returncode is not 0:
enso.py:3643: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if returncode is not 0:
enso.py:4670: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if returncode is not 0:

     __________________________________________________
    |                                                  |
    |                                                  |
    |                       ENSO -                     |
    |          energetic sorting of CREST CRE          |
    |          for automated NMR calculations          |
    |             University of Bonn, MCTC             |
    |                    July 2018                     |
    |                   version 2.0.1                  |
    |  F. Bohle, K. Schmitz, J. Pisarek and S. Grimme  |
    |                                                  |
    |__________________________________________________|
    
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.


.ensorc is taken from: /home/henrique/teste_nmt/enso/.ensorc
Reading information from .ensorc.
Reading information from flags.dat.

ERROR: Can not convert resonance frequency: 'None' into float! Options are ['MHz number of your experimental spectrometer setup'].

WARNING: Can not convert resonance frequency! Flag -mf has to be set while executing the anmr program.
Using conformers from file /home/henrique/teste_nmt/enso/crest_conformers.xyz.

-----------------------------------------------------------
 PARAMETERS
-----------------------------------------------------------

number of atoms in system:                                     19
number of conformers:                                          119
charge:                                                        0
unpaired:                                                      0
solvent:                                                       chcl3
program for part1 and part2:                                   tm
program for part3:                                             tm
program for part4:                                             tm
using ANCOPT implemented in xTB for the optimization:          on
program for RRHO in part2 and part3:                           xtb
GFN version for RRHO and/or GBSA_Gsolv in part2 and 3:         gfn2
temperature:                                                   298.15
part1:                                                         on
part2:                                                         on
part3:                                                         on
part4:                                                         on
only boltzmann population:                                     off
calculate backup conformers:                                   off
functional for part1 and part2:                                pbeh-3c
functional for part3:                                          pw6b95
basis set for part3:                                           def2-TZVPP
calculate couplings:                                           on
functional for coupling calculation:                           pbe0
basis set for coupling calculation:                            def2-TZVP
calculate shieldings:                                          on
functional for shielding calculation:                          pbe0
basis set for shielding calculation:                           def2-TZVP
threshold for part1:                                           6.0
threshold for part2:                                           2.0
solvent model for part1 and part2:                             dcosmors
solvent model for Gsolv contribution of part2:                 sm
solvent model for part3:                                       dcosmors
solvent model for part4:                                       dcosmors
cautious checking for error and failed calculations:           on
checking the DFT-ensemble using CREST:                         off
maxthreads:                                                    1
omp:                                                           1
calculating spectra for:                                       1H
reference for 1H:                                              TMS
resonance frequency:                                           None
END of parameters


-----------------------------------------------------------
 PATHS of employed QM programs
-----------------------------------------------------------

The following program paths are used:
    xTB:          /home/henrique/bin/xtb/bin
    CREST:        /home/henrique/bin/crest/crest
Traceback (most recent call last):
  File "enso.py", line 12231, in <module>
    main(argv=None)
  File "enso.py", line 12138, in main
    ) = enso_startup(cwd,argv)
  File "enso.py", line 9287, in enso_startup
    error_logical = input_object.processQMpaths(args, error_logical)
  File "enso.py", line 8367, in processQMpaths
    print('    TURBOMOLE:    {}'.format(os.path.dirname(tmpath)))
  File "/usr/lib64/python3.8/posixpath.py", line 152, in dirname
    p = os.fspath(p)
TypeError: expected str, bytes or os.PathLike object, not NoneType

ENSO 2.0.2 and slurm

Could it be that ENSO 2.0.2 doesn't properly terminate?
It seems the program runs fine from the command line on our cluster, and it also executes fine on a node when executed via slurm (checked after login), but after 'finishing' my slurm script is somehow unable to copy the results back to my home folder. It seems this is because enso does not properly terminate after the calculations are done. I don't have the same problem on our cluster when using ENSO 1.2.7, but all versions since version 2.0 and higher seem to have the same issue.

ERROR: in the optimization of CONF1/tpss

ANMR read from anmr_nucinfo written by crest_2.10

The information on chemical and magnetical equivalency is not processed correctly.
This seems to be the case because of a different output of the file anmr_nucinfo in crest_2.10.

Current work around until fixed: process crest_rotamers.xyz with cregen and an older crest version and use the anmr_nucinfo file from the older version.