grimme-lab / xtb4stda Goto Github PK

sTDA-xTB Hamiltonian for ground state

License: GNU Lesser General Public License v3.0

Makefile 2.31% Ruby 0.28% Fortran 96.32% Meson 1.10%

tight-binding excited-states computational-chemistry

xtb4stda's Introduction

sTDA-xTB for ground state calculations

This project provides xtb4stda, a program to calculate the ground state with sTDA-xTB to be used in further stda calculations.

Installation

Statically linked binaries can be found at the projects release page. To build from source this project uses a make based build system and requires a version of Intel Parallel Studio 17 or newer to be compiled (also requires ruby for some hacky scripts). To trigger the build run in the root directory

make

You will find a statically linked executable in exe/xtb4stda. To make xtb4stda accessible export

export XTB4STDAHOME=$PWD
export PATH=$PATH:XTB4STDAHOME/exe

For parallel usage set the threads for OMP and the MKL linear algebra backend by

export OMP_NUM_THREADS=<ncores> MKL_NUM_THREADS=<ncores>

For larger systems please adjust the stack size accordingly, otherwise stack overflows will occur. Use something along the lines of this:

ulimit -s unlimited
export OMP_STACKSIZE=4G

To make adjustments to the build system check the directory MAKE/.

Alternatives

If you are not a fan of make, you can use meson as alternative, but it requires a fairly new version like 0.49 or newer for a decent Fortran support. For the default backend ninja version 1.5 or newer has to be provided.

To perform a build run (with GCC, run export FC=ifort for Intel builds)

meson setup build_gcc
ninja -C build_gcc

This also allows to install the program locally by running

[sudo] ninja -C build_gcc install

Which will default to an installation in /usr/local and should automatically include xtb4stda in your systems PATH variable. The environment variable to set is than usually only

export XTB4STDAHOME=/usr/local/share/xtb4stda

Usage

The xtb4stda binary will read the geometry from its first command line argument and the input is assumed to be either a Turbomole coordinate data group or a xyz-file. The extension of the file is not used to distinguish files.

xtb4stda coord > gs.stda-xtb.out

After the run you will find a wfn.xtb file in the directory which can be used with the stda program.

Citations

S. Grimme and C. Bannwarth, J. Chem. Phys., 2016, 145, 054103. DOI: 10.1063/1.4959605

License

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

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

Bugs

A bug is a demonstratable problem caused by the code in this repository. Good bug reports are extremely valuable for us - thank you!

Before opening a bug report:

Check if the issue has already been reported.
Check if it still is an issue or has already been fixed? Try to reproduce it with the latest version from the master branch.
Isolate the problem and create a reduced test case.

A good bug report should not leave others needing to chase you up for more information. So please try to be as detailed as possible in your report, answer at least these questions:

Which version of xtb4stda are you using? The current version is always a subject to change, so be more specific.
What is your environment (your laptop, the cluster of the university)?
What steps will reproduce the issue? We have to reproduce the issue, so we need all the input files.
What would be the expected outcome?
What did you see instead?

All these details will help people to fix any potential bugs.

Known Issues

For large systems with more than 33000 basis functions an integer overflow in the linear algebra backend will occur. To amend this issue the integer precision range must be increased from 32 bits to 64 bits by recompiling the program. Adjust the make build by changing -lmkl_intel_lp64 to -lmkl_intel_il64 in MAKE/Makerules or when using the meson backend by adding -Dinterface=64 in the configuration step. Note that this option is currently only supported with the MKL backend.

xtb4stda's People

Contributors

Stargazers

Watchers

Forkers

mdewergi cbannwarth savasci pierre-24 shomikverma zymergen-jvandezande shoubhikraj digitalmoleculardesign alanliska

xtb4stda's Issues

Crash on multiple machines

xtb4stda crashes on our workstation (Ryzen 9 3950X running Ubuntu 18) and on our clusters (Intel Xeon E5462 or AMD Opteron 6172 running CentOS 5.5 and 6.5). However, xtb4stda works on my personal machine (Intel i7 9900 running Debian 10). The "standard" xtb works on all machines.

The bug occurs while executing "xtb4stda coord.xyz". Any valid .xyz file will cause a crash (ex. propane). The program crashes with the following error:

forrtl: severe (8): internal consistency check failure, file for_intrp_fmt.c, line 2745
Image              PC                Routine            Line        Source             
xtb4stda           00000000014B29CC  Unknown               Unknown  Unknown
xtb4stda           0000000001450B11  Unknown               Unknown  Unknown
xtb4stda           000000000144FAB0  Unknown               Unknown  Unknown
xtb4stda           000000000043D862  Unknown               Unknown  Unknown
xtb4stda           0000000000408A89  Unknown               Unknown  Unknown
xtb4stda           000000000040205E  Unknown               Unknown  Unknown
xtb4stda           00000000015F3720  Unknown               Unknown  Unknown
xtb4stda           0000000000401F47  Unknown               Unknown  Unknown

I recompiled the program on the workstation in debug mode. The same error occurs, but the error message is a bit more descriptive:

forrtl: severe (408): fort: (2): Subscript #1 of the array TIMESTP has value 98 which is greater than the upper bound of 94

Image              PC                Routine            Line        Source             
xtb4stda           00000000015C0A7F  Unknown               Unknown  Unknown
xtb4stda           00000000004A5B6C  rdelparam_                165  readparam.f
xtb4stda           0000000000407F10  MAIN__                    342  main.f
xtb4stda           0000000000400DD2  Unknown               Unknown  Unknown
xtb4stda           00000000017BACA9  Unknown               Unknown  Unknown
xtb4stda           0000000000400CAA  Unknown               Unknown  Unknown

I hope this is useful to you!

Vibronic spectral calculation by sTDA-xTB?

Hello,
Thank you for developing this great package.

I'd like to request a feature to compute vibronic spectra by sTDA-xTB for fast prediction of absorption spectral shape.

As implemented in Gaussian, vertical gradient model is desirable to compute fast. Vertical hessian or adiabatic hessian is another option, but may be computationally-expensive.

Calculation suddenly stops during sTD-DFT procedure, "matrix power impossible"

I am trying to run sTD-DFT-xTB on oligomers and certain ones are crashing. They seem to all stop right after the sTD-DFT procedure begins as it is setting up A+B and A-B matrices. I get the error message "matrix power impossible". I attached my input xyz file and the stda output file. Any advice would be much appreciated.

351_414_010101.txt
351_414_010101.xyz.txt

Implement new solvents/solvation models that have been implemented in xTB

Is your feature request related to a problem? Please describe.
It seems to me that the xtb4stda development has almost stopped, even though the original xTB program has received multiple crucial new features such as ALPB solvent models, and many new solvents. This is problem for xTB-sTDA calculations, because those new features cannot be used.

It is also not clear whether xtb4stda can use other solvent models or other solvents and where the parameters could be found. The manual of stda does not mention solvation.

Describe the solution you'd like
xtb4stda should implement new solvents, if not, we should be given some sort of guide on how to find and input parameters for new solvents. It should also implement ALPB model if possible.

Describe alternatives you've considered
I am not sure if we can just bypass the xtb4stda and run xTB directly, because both programs calculate the ground state, the only feature of xtb4stda seems to be that it writes the output in a format that can be read by the stda program directly. If we can interface xTB with stda, then we can use the new solvent models. The manual is not clear on this.

Additional context
I am also unsure if stda actually takes into account the solvent model that was used in the ground state. From what I understand about PCM-like models, there is an additional calculation step during the excitation energy calculation that considers the non-equilibrium effects of the solvent. The stda manual does not mention anything about this.

Will xtb4stda still support new elements?

Is your feature request related to a problem? Please describe.
Is this project still being updated?

Describe the solution you'd like
I wish xtb4stda could include lanthanides.

add MACOS option for makefile

stda recently added macos option for makefiles, so I was wondering if xtb4stda could also be similarly updated. I attempted to edit the makerules and makeconfig files but was unsuccessful - would really appreciate this feature!

For now, I've circumvented by exporting a molden file in xtb to use in stda. the manual states that the $\alpha, \beta, a_x$ parameters are set automatically - was wondering how they are set so I can replicate this while using a molden file.

Use the "new" (?) xcontrol

Describe the bug
I can imagine some of the reason that lead to the separation of xtb and xtb4stda, but it seems that the later still use the "old" input file format (and thus rely to command lines options for charge, solvent ...), while xtb allow to provide the additional informations in the input file ($chrg, $gbsa), which I find way more easier (for example, to automatically convert from output of other program, then running xtb4stda without having to know what the charge is).

Again, I guess that the reason this is not done yet (among other things like "not enough time") is that xcontrol provides a lot more options that only what is required here (which seems like a tuned single point), but that would definitely ease the life of the end user.

You could even imagine making the xcontrol part an external library shared between the two projects.

To Reproduce

Running xtb4stda on a file with $chrg 1 in it does not gives an error, but the charge is not considered (and thus the molecule is considered open-shell).

Expected behaviour
Charge (and other information) are considered.

Additional context
None.

Interface between sTDA and xTB

With the update to XTB v6, the previous interface to sTDA seemingly broke (i.e., it didn't save the same temporary files).

Is there a new way to run STDA from an XTB calculation? Are you supposed to dump a molden file?

MKL error with a large number of atoms

Describe the bug
While running xtb4stda on a large number of atoms, I encountered an error:

Intel MKL ERROR: Parameter 11 was incorrect on entry to DSYGVD.
diag error

To Reproduce

I'm working on a freshly compiled version of xtb4stda, but it was already the case on a older (?) version compiled and provided by @mdewergi.

I cannot disclose the system on which this error happened (especially since it is not mine), so I reproduced it by incrementally adding methane molecule. I didn't use solvent.

xtb4stda is ok with 1170 methane molecules (5850 atoms):

 --------------------------------------------
          xTB calculation for sTDA...
 --------------------------------------------
 
 reading parameter file 
 /home/pbeaujea/bin/.xtb-all//share/xtb4stda/.param_stda2.xtb
 
      method parameters     
 k(s)        :  1.6000
 k(p)        :  2.1800
 k(d)        :  1.9500
 k(f)        :  2.0000
 k(R-V)      :  2.2750
 k(R-R)      :  1.7650
 Tscal       :  0.2580
 Gscal       :  1.0000
 fpol        :  1.0000
 Zcnf        :  0.3430
 Zqf         :  0.0000
 kcn         :  2.7000
 Ryd Hsplit  :  0.7000
 lshift(virt):  3.1000
 lshift(OS)  :  0.2000
 wllscaling  :  2.6000
 
 mowrcut     : 3.000
 
  Z AO/shell   Hii/eV     exponent
  1     Sun Feb 14 09:53:25 CET 2016    EN: 2.327 GAM: 0.473  GM3: 0.0000
     1s    -14.339618    1.220000
     2sp    -3.348946    0.600000
  6     Sun Feb 14 09:53:25 CET 2016    EN: 2.731 GAM: 0.422  GM3: 0.0000
     2s    -22.009312    1.565095
     2p    -13.020408    1.596905
     3sp    -3.914040    0.824500
 
 Nbf   :        32760
 T(el) :     0.0
 calculating S/T integrals ...
 cpu time for ints    315.314927000000     
 Nao   :        32760
 making H0...
 making H1...
 cpu time for H       98.6259709999995     
 solving ...
 cpu time for diag    57505.5604380000     
 
 gap (eV)           :  14.022
 Koopmans IP (eV)   :  20.172
 Eel (Eh)           : -7653.348973

          eigenvalues
 #    :        4668       4669       4670       4671       4672       4673       4674       4675
 occ. :        2.000      2.000      2.000      2.000      2.000      2.000      2.000      2.000
 eps  :       -20.180    -20.180    -20.179    -20.179    -20.179    -20.178    -20.177    -20.177
 #    :        4676       4677       4678       4679       4680       4681       4682       4683
 occ. :        2.000      2.000      2.000      2.000      2.000      0.000      0.000      0.000
 eps  :       -20.177    -20.176    -20.176    -20.175    -20.174     -6.151     -6.091     -6.090
 #    :        4684       4685       4686       4687       4688       4689       4690       4691
 occ. :        0.000      0.000      0.000      0.000      0.000      0.000      0.000      0.000
 eps  :        -6.082     -6.032     -6.026     -6.024     -6.023     -6.021     -6.005     -5.967
                            1  SCC done.
 writing mo output ...
 molden style : F
 
speedup  3.90
cpu  time for all   17 h 36 m 30.9 s
wall time for all    4 h 31 m  8.8 s

But it is failing with 1180 methane molecules (5900 atoms):

 --------------------------------------------
          xTB calculation for sTDA...
 --------------------------------------------
 
 reading parameter file 
 /home/pbeaujea/bin/.xtb-all//share/xtb4stda/.param_stda2.xtb
 
      method parameters     
 k(s)        :  1.6000
 k(p)        :  2.1800
 k(d)        :  1.9500
 k(f)        :  2.0000
 k(R-V)      :  2.2750
 k(R-R)      :  1.7650
 Tscal       :  0.2580
 Gscal       :  1.0000
 fpol        :  1.0000
 Zcnf        :  0.3430
 Zqf         :  0.0000
 kcn         :  2.7000
 Ryd Hsplit  :  0.7000
 lshift(virt):  3.1000
 lshift(OS)  :  0.2000
 wllscaling  :  2.6000
 
 mowrcut     : 3.000
 
  Z AO/shell   Hii/eV     exponent
  1     Sun Feb 14 09:53:25 CET 2016    EN: 2.327 GAM: 0.473  GM3: 0.0000
     1s    -14.339618    1.220000
     2sp    -3.348946    0.600000
  6     Sun Feb 14 09:53:25 CET 2016    EN: 2.731 GAM: 0.422  GM3: 0.0000
     2s    -22.009312    1.565095
     2p    -13.020408    1.596905
     3sp    -3.914040    0.824500
 
 Nbf   :        33040
 T(el) :     0.0
 calculating S/T integrals ...
 cpu time for ints    320.219369000000     
 Nao   :        33040
 making H0...
 making H1...
 cpu time for H       141.714109000000     
 solving ...

Intel MKL ERROR: Parameter 11 was incorrect on entry to DSYGVD.
diag error

According to my research, it seems related to a to large integer (I don't know the equivalent in Fortran) that overflows (the number is too large for the number of bits available for that type, or something like that). But my BLAS is a bit rusty (and I never used it directly).

It is probably related to the number of basis functions more than to the number of atoms, though (the actual system on which this error happened for the first time contains a little bit less atoms than that, but way more carbons).

A gist containing the two inputs and outputs is available.

Expected behaviour
The calculation succeed.

Additional context
With more than 10 000 atoms, the program outputs that it cannot continue, so a quick (and dirty) fix would be to decrease this limit :/