evangelistalab / forte Goto Github PK

View Code? Open in Web Editor NEW

48.0 11.0 28.0 65.1 MB

Home Page: http://www.evangelistalab.org

License: GNU Lesser General Public License v3.0

Python 6.76% C++ 90.92% C 0.01% CMake 0.70% Shell 0.02% Jupyter Notebook 1.59%

forte psi ambit quantum-chemistry chemistry

forte's People

Contributors

Stargazers

Watchers

forte's Issues

Reproducing DSRG-MRPT2 results

Hi,

I'm trying to reproduce the the results in the paper J. Chem. Phys. 146,124132 (2017) for N2.
In the supporting information

  R       CASSCF    u-DSRG-MRPT2    DSRG-MRPT2    r-DSRG-MRPT2   fr-DSRG-MRPT2
0.800 -108.48569238  -108.63027566  -108.63064658  -108.63094833  -108.63094825

Using the following input, I managed to have the correct CASSCF energy, but the DSRG-MRPT2 number does not match. What did I do wrong?
Thanks

==> DSRG-MRPT2 Energy Summary <==

    E0 (reference)                 =   -108.485692373441381
    <[F, T1]>                      =     -0.009292415956127
    <[F, T2]>                      =      0.007202136010542
    <[V, T1]>                      =      0.008439844902073
    <[V, T2]> (C_2)^4              =     -0.166025162246817
    <[V, T2]> C_4 (C_2)^2 HH       =      0.001133379752693
    <[V, T2]> C_4 (C_2)^2 PP       =      0.006271250454330
    <[V, T2]> C_4 (C_2)^2 PH       =      0.008950803079923
    <[V, T2]> C_6 C_2              =     -0.001319923417720
    <[V, T2]>                      =     -0.150989652377590
    DSRG-MRPT2 correlation energy  =     -0.144640087421103
    DSRG-MRPT2 total energy        =   -108.630332460862491
    max(T1)                        =      0.609191865576933
    max(T2)                        =      0.091887841339497
    ||T1||                         =      0.939612899751587
    ||T2||                         =      1.791629750051084

#!N2

import forte
memory 1 Gb

molecule N2 {
N          0.000000       0.000000       0.000000
N          0.000000       0.000000       0.800000
symmetry d2h
0 1
units ang
}

basis mybas{
  assign N cc-PVDZ 
}

set globals{
  basis mybas
  reference rhf
  scf_type CD
  df_ints_io     save
  cholesky_tolerance 1.0e-6
#                        Ag   B1g   B2g   B3g    Au   B1u   B2u   B3u 
  docc             [     3,    0,    0,    0,    0,    2,    1,    1 ]
  restricted_docc  [     2,    0,    0,    0,    0,    2,    0,    0 ]
  active           [     1,    0,    1,    1,    0,    1,    1,    1 ]
  mcscf_maxiter 100
  nat_orbs true
}

scf_e, scf_wfn = energy('scf',                     return_wfn=True)
molden(scf_wfn, 'hf.molden')

cas_e, cas_wfn = energy('casscf', ref_wfn=scf_wfn, return_wfn=True)
molden(cas_wfn, 'casscf.molden', density_a=cas_wfn.get_opdm(0, 0, "A", True)) 

set forte {
    job_type              dsrg-mrpt2
    int_type              cholesky
    cholesky_tolerance    1e-6
    CAS_TYPE              fci
    root_sym              0
    nroot                 1
    dsrgpt                true
    dsrg_s                0.5
#                          Ag   B1g   B2g   B3g    Au   B1u   B2u   B3u 
    frozen_docc      [     1,    0,    0,    0,    0,    1,    0,    0 ]
    restricted_docc  [     1,    0,    0,    0,    0,    1,    0,    0 ]
    active           [     1,    0,    1,    1,    0,    1,    1,    1 ]
}

energy('forte', ref_wfn = cas_wfn)

Failing test cases (1/28/2019)

actv-dsrg:
- actv-dsrg-4-C4H6-triplet
- actv-dsrg-ipea-2
dsrg-mrpt2:
- dsrg-mrpt2-8-sa (the sa-sub should not run sa-full procedure)
- dsrg-mrpt2-9-xms
dwms-dsrgpt:
- dwms-dsrgpt-1-sa
- dwms-dsrgpt-2-sa
- dwms-dsrgpt-4-sa
- dwms-dsrgpt-5-ms
- dwms-dsrgpt-8-separated
- dwms-dsrgpt-3-sa
- dwms-dsrgpt-6-ms
- dwms-dsrgpt-7-ms
- dwms-dsrgpt-9-sa-C6H6

Reintroduce active space sanity checks

During the transition to python the following bit of C++ code that checks the size of the active space was not ported to python.

//    // Sanity check
//    if ((4 * sizeof(Determinant)) < mo_space_info->size("ACTIVE")) {
//        outfile->Printf("\n  FATAL:  The active space you requested (%d) is larger than allowed by
//        "
//                        "the determinant class (%d)!",
//                        mo_space_info->size("ACTIVE"), 4 * sizeof(Determinant));
//        outfile->Printf("\n          Please check your input and/or recompile Forte with a larger
//        "
//                        "determinant dimension");
//        exit(1);
//    }

//    if (((options.get_str("DIAG_ALGORITHM") == "DYNAMIC") or
//         (options.get_bool("SCI_DIRECT_RDMS") == true)) and
//        (mo_space_info->size("ACTIVE") > 64)) {
//        outfile->Printf("\n  FATAL:  Dynamic diagonalization or dynamic RDM builds cannot be used
//        "
//                        "for active spaces larger than 64 orbitals!");
//        exit(1);
//    }

Deboost Forte

Soon Boost will be removed from Psi4 (see psi4/psi4#450). This change will break Forte since it uses a few boost libraries. Moving Boost should be simple for the most part, but will need to find a replacement for the ODE integrators, or find a way to include parts of Boost in Forte.

Setup Travis CI

Forte manual improvements

Add code to generate option documentation for all modules. All data is already in ForteOptions objects, it just needs to be printed out in a formatted way.
Add table with tested methods. This should specify when certain limitations apply (e.g. works only for low-spin states, only restricted orbitals, etc.)
Document ACI
Document PCI
Document DSRG-MRPT2/3 codes and clear confusion about method calls. This includes SA and VCIS/VCISD features and future extensions (XMS, etc.)
Document MR-LDSRG(2)
Document aosubspace, avas, sorting, ci-no
Document FCI code, CASSCF, and SA-CASSCF

Add MR-LDSRG(2) tests

...

Remove libthce, use psi4 dfhelper

Shouldn't be too difficult, will result in at least ~2x speedup in building DF integrals

Improve the handling of spin quantum numbers

The spin state is controlled by the keywords multiplicity and ms. The former is 2S+1 while the latter is defined as 2 x M_S, an unfortunate choice that is potentially confusing to new users.

Address this issue by either:

Defining M_S as a double option and introduce appropriate checks.
Introducing rational option types in Psi4.

Tasks to perform:

Modify definition of Ms
Update manual

Failing test cases

Here are the tests that fail:

    DSRG-MRPT2-6..............................................DOES NOT MATCH
    DSRG-MRPT3-5..............................................DOES NOT MATCH
    PCI-1.....................................................DOES NOT MATCH
    PCI-2.....................................................DOES NOT MATCH
    PCI-3.....................................................DOES NOT MATCH
    PCI-4.....................................................DOES NOT MATCH
    PCI-5.....................................................DOES NOT MATCH
    PCI-6.....................................................DOES NOT MATCH
    PCI-7.....................................................DOES NOT MATCH
    PCI-8.....................................................DOES NOT MATCH

Note that the DSRG-MRPT3-5 does not fail each time. When it does, it it is the 10th digit which causes the 9th digit (which is compared) to be different.

For the DSRG-MRPT2-6, the number of trial vectors per root is 10, while it is 56 is the reference output. Maybe something changed with how this parameter is set.

Davidson-Liu solver converge to incorrect value

Test case 'apifci-1' (commit ac15a0d) fails to converge the post diagonalization to correct value.
Input file:
import forte

refscf = -14.6097447388741113 #TEST
refapifci = -14.646160455930 #TEST
refpostdiag = -14.646164858074 #TEST

molecule li2{
Li
Li 1 2.0000
}

set {
basis sto-3g
scf_type pk
e_convergence 12
}

set forte {
job_type apici
tau 0.1
spawning_threshold 0.0001
post_diagonalize true
DIAG_ALGORITHM DLSOLVER
}
energy('scf')
compare_values(refscf, get_variable("CURRENT ENERGY"), 11, "SCF energy") #TEST

energy('forte')
compare_values(refapifci, get_variable("APIFCI ENERGY"), 11, "APIFCI energy") #TEST
compare_values(refpostdiag, get_variable("APIFCI POST DIAG ENERGY"), 10, "APIFCI POST DIAG ENERGY") #TEST

It seems that this test fails only when
sparse_ci_solver.cc: line 1484:
size_t nguess = std::min(static_cast<size_t>(nroot) * 100,nets);
the multiplier of nroot is between 93~100.

One solution can be delete
sparse_ci_solver.cc: line 1680:
dls.set_project_out(bad_roots);

This issue may need further attention to make sure DLSolver converge to correct value.

Fix ambit compilation in Travis CI

Recent changes to Ambit seem to have broken Travis CI. See jturney/ambit@324e049 for changes made by @jturney.

Lost previous issues

With the repository change all issues got lost. Please repost old issue (if still relevant) and feature requests.

Improvements to the orbital localization code

When localization is invoked print a small summary of which orbitals are localized
Allow the user to decide which orbitals to localize using multiple input types:
- by a vector of MO indices ([10, 11, 12, 18])
- By orbital space using MOInfoSpace labels (ACTIVE, etc.)
Add IBO localization

CI vectors are somehow random

We are having some trouble for CO molecule when symmetry is turned off. Here is the sample input.

import forte

molecule CO{
0 1
C
O 1 2.0

symmetry c1
}

set {
  basis          6-31g
# basis          cc-pvdz
  reference      rhf
  scf_type       pk
  e_convergence  15
  d_convergence  12
  maxiter        100
  guess          core
}
Escf, wfn = energy('scf', return_wfn=True)

set forte{
  job_type           dsrg-mrpt2
  multiplicity       1
  frozen_docc        [2]
  restricted_docc    [2]
  active             [6]
# frozen_docc        [2,0,0,0]
# restricted_docc    [2,0,0,0]
# active             [2,0,2,2]
  nroot              6
  root               5
  dsrg_s             0.5
  e_convergence  12
  d_convergence  10
  fci_iterations 100
# diag_algorithm     full
}
energy('forte', ref_wfn=wfn)

The corresponding frozen_docc, restricted_docc, and active in C2v symmetry are commented out.
Note that CO is stretched.
The problem is that the CI coefficients before semi-canonicalization is somewhat random.
Moreover, the semi-canonicalization step does not really semi-canonicalize the orbitals as tested by the DSRG-MRPT2 code at the very beginning.
The final MRPT2 energy is not affected because it will re-diagonalize the diagonal blocks of the Fock matrix and obtain the unitary matrix.

Things I tested so far:

There is no problem with symmetry.
The orbital rotation will block-diagonalize the Fock matrix, that is, F_semi = U^+ F_old U where diagonal blocks of F_semi is diagonal.
The retransformed integrals from the integral class are not guaranteed (somehow random) to be the same as manually transformed integrals. For example, the one-electron integrals obtained from i) passing C_semi = C_old U to the wavefunction and calling retransform_integrals() can be different from ii) computing U^+ H_old U.
Even two approaches in 3) give identical integrals, the density obtained by re-diagonalizing the Hamiltonian is not the same as doing U^+ D_old U.
Changing diag_algorithm does not help.
The behavior can be reproduced by just computing 1 root.

The correct (from MOLPRO) CI vector for the ground state in semi-canonical basis is the following:

 222000      0.6676995
 b220a0      0.3001168
 a220b0     -0.3001168
 2b2a00     -0.3001168
 2a2b00      0.3001168
 22b00a     -0.1456175
 22a00b      0.1456175
 202200     -0.1265292
 022020     -0.1265292
 220002     -0.1205968
 a200b2      0.0739910
 b200a2     -0.0739910
 2b0a02      0.0739910
 2a0b02     -0.0739910
 ab2ab0     -0.0695942
 ba2ba0     -0.0695942
 b2a0ba     -0.0602882
 a2b0ab     -0.0602882
 2bab0a      0.0602882
 2aba0b      0.0602882
 aaabbb      0.0601733
 bbbaaa     -0.0601733
 bb0aa2     -0.0510834
 aa0bb2     -0.0510834
 2abb0a     -0.0504317
 2baa0b     -0.0504317
 a2b0ba      0.0504317
 b2a0ab      0.0504317

while FCI-canonicalization-FCI gives:

    222000      0.66769959
    2b2a00      0.27588391
    a220b0      0.27588391
    b220a0      0.27588391
    2a2b00      0.27588391
    22b00a     -0.14561763
    22a00b     -0.14561763
    220002     -0.12059684
    a22b00      0.11814446
    2a20b0     -0.11814446
    b22a00      0.11814446
    2b20a0     -0.11814446
    202200     -0.10862462
    022020     -0.10862462

The dominant is almost the same while the rest are very different and they can vary from computation from computation.

It seems to me there is a memory problem in sparse_ci_solver or fci_solver. Does anyone can reproduce this error and have any idea on this issue? Many thanks.

New SemiCanonicalize class not working for total spin > 0

Proceed with caution until this is resolved

Python Forte driver/interface

Here is a wishlist of infrastructure improvements related to exposing Forte via pybind11

Expose Forte's methods (start/cleanup/integral setup,...) in Python via pybind11
Cleanup of integrals at exit
Port method logic to Python scripts
Expose Forte classes in Python
Experiment with options vs. function parameters

Forte output improvements

Create a Forte banner with authors names and git version/date.
Create script and Make hook to generate version file.
Automatic loading of Forte in Psi4?
Printing of Ms should be able to handle ratios (e.g. 3/2).
Printing units
Data formatted for other programs (xml, latex, html?)
...

Print more info at the end of a FCI computation

MPI in Forte

There are a few lingering issues regarding MPI usage in Forte.

File writing in Psi. This issue will be fixed by PR psi4/psi4#549, but remains a problem for us until it is actually integrated.
Initializing/Finalizing MPI. Currently, MPI is initialized/finalized in src/main.cc, which prevents Forte from being called multiple times in the same input. The quickest fix of this is to have Psi do the initializing/finalizing, which is simple, but it seems Psi has removed all MPI-compatibility so we'd need to make our changes with each Psi update. Alternatively, it may be possible to keep all MPI code within Forte, but we'd need to find a clever way to call Finalize() only once at the end.
Global Arrays. Somewhat of a tangent, but we should decide if we want to fully use GA in all parallel code or not. @kannon92 will have the best insight on this. Side note: Forte with GA does not currently compile with post-inversion Psi.

Currently, we can add MPI to Forte in a somewhat experimental way, but it would be good to discuss how we want to organize MPI in Forte for future development.

Change license to LGPL

Compilation issue, cannot find boost header file

Hi, I am compiling forte on a Ubuntu 18.04 machine. I have psi4 dev version installed and following the steps in README. I encounter the following error in the step of make

In file included from /PATH/forte/src/mrdsrg-helper/run_dsrg.h:10:0,
                         from /PATH/forte/src/api/forte_python_module.cc:57:
/PATH/src/mrdsrg-spin-integrated/dsrg_mrpt3.h:41:10: fatal error: boost/assign.hpp: No such file or directory
 #include "boost/assign.hpp"

compilation terminated.

I do have boost installed and the header file is in: /usr/local/include/boost/
How can I link to the boost header file during compilation? Thank you!

ActiveSpaceIntegrals::print()

ActiveSpaceIntegrals::print() function prints 2-e integral with index overflow

Enforce spin complete function doesn't work

make_spin_complete() in the DetermiantHashVec class produces determinants with wrong numbers of electrons.

Future: test case ACI-MRCISD-2 is bound to break

Cannot yet predict the future, but I know that once changes to the Be basis introduced by pull request psi4/psi4#728 come into effect, the SCF and CI energies will change slightly in test case ACI-MRCISD-2. Once psi4/psi4#728 propagates to Travis update test case.

Failing test cases

The following test cases fail on my laptop with commit f07391b

    CASSCF-3..................................................DOES NOT MATCH
    CASSCF-4..................................................DOES NOT MATCH
    CASSCF-5..................................................DOES NOT MATCH
    MR-DSRG-PT2-1.............................................DOES NOT MATCH
    DSRG-MRPT2-6..............................................DOES NOT MATCH

Can anyone confirm this?

Here is a task list to check progress on this issue

Add test cases for MRPT2 class.

Add test cases that run and check the value of results obtained using the MRPT2

Roadmap:

Add test cases
Extend functionality to ACI and add tests

Port Forte to Psi4 1.1

With the release of Psi4 1.1 Forte no longer compiles.

TODOs for the spin-adapted MRDSRG

Here are the TODO list for PR #182 . I just put them here in case I forget after merging to master branch.

Implement internal amplitudes for general PT
Test speed for PT2 threading
The test cases' numbers may be updated when Psi4's CASSCF problem is fixed.

Fail to compile on cluster

Hey everybody,

I am not able to compile the code on both my mac and the linux box. I get this error:

mini-boost/boost/numeric/odeint.hpp:74:63: fatal error:      
boost/numeric/odeint/integrate/max_step_checker.hpp: No such file or directory
#include <boost/numeric/odeint/integrate/max_step_checker.hpp>

Changes to forte to make sure it works with new PSI4CMAKE

I think we should maybe pick a time to transfer forte to the new PSI4. I think we probably just have to make sure that we switch all shared_ptrs to be the standard. And make sure to change SharedMatrix if we put in the full type name.

We should do this once ambit is completed merged into the new cmake rewrite.

Fix issues from psi4 PR#736

Fix compilation with psi4 from master after major infrastructure changes. Will be addressed by pull request #33.

AO Subspace does not work on cluster

I am not able to run any code with the ao subspace part of forte on our cluster.

I can run it on my mac with both intel and clang compilers with no problem.

I get this error:

An error has occurred python-side. Traceback (most recent call last):

File "<string>", line 60, in <module>

 File "/home/kannon/src/psi4src/psi4/share/python/driver.py", line 444, in energy
wfn = procedures['energy'][lowername](lowername, molecule=molecule, **kwargs)

 File "/home/kannon/src/forte_parallel_release/pymodule.py", line 30, in run_forte
returnvalue = psi4.plugin(sofile,ref_wfn)

RuntimeError: regex_error

You can reproduce this error with any reg ex expression so it is not a typo.

Here is a minimal input that works on my mac.

import forte

molecule N2 {
N    0.00000    0.0000    -0.550
N    0.00000    0.0000     0.550
symmetry c1
}

set basis cc-pvdz
set scf_type direct

energy('scf')
set forte {
    subspace ['N(2p)']
}
energy('forte')

Relaxed density matrices

Hi,

It is posible to print the 2-RDM matrix for the following methods ACI,PCI,DSRG and MRCI methods ?

Best,
Jose Luis

New failing test cases

The following test cases fail on the new version of forte (inversion).

        ------------------------------------------------------------------------
        MR-DSRG-PT2-1.............................................DOES NOT MATCH
        DSRG-MRPT2-6..............................................DOES NOT MATCH
        DSRG-MRPT2-8..............................................DOES NOT MATCH
        DF-DSRG-MRPT2-2...........................................DOES NOT MATCH
        DF-DSRG-MRPT2-THREADING1..................................DOES NOT MATCH
        DF-DSRG-MRPT2-THREADING2..................................DOES NOT MATCH
        DF-DSRG-MRPT2-THREADING4..................................DOES NOT MATCH
        DISKDF-DSRG-MRPT2-THREADING1..............................DOES NOT MATCH
        DISKDF-DSRG-MRPT2-THREADING4..............................DOES NOT MATCH
        DISKDF-DSRG-MRPT2-2.......................................DOES NOT MATCH
        ACI-14....................................................DOES NOT MATCH
        ------------------------------------------------------------------------

Improve ACI/PCI initial guess

Switch to CASCI guess with largest possible number of active orbitals given S, and Ms.

AVAS-1 fails

I noticed some odd behavior with the avas-1 test. If I run it ten times or so, about a quarter of those runs fail due to the incorrect number of active orbitals being chosen. Any ideas @henankf223 or @fevangelista?

Remove inheritance from psi::Wavefunction

We are removing the inheritance from psi::Wavefunction. Instead of passing the psi::Wavefunction to each method, we should try to exclusively use new classes (StateInfo, SCFInfo, ForteOptions, ForteIntegrals).

Here are the classes that currently need updating:

DynamicCorrelationSolver

Claimed
Done

CASSCF

Claimed
Done

Claimed
Done

DMRGSCF

Claimed
Done

MRDSRG_SO

Claimed
Done

SOMRDSRG

Claimed
Done

DSRG_MRPT

Claimed
Done

DWMS_DSRGPT2

Claimed
Done

ACTIVE_DSRGPT2

Claimed
Done

CINO

Claimed
Done

MRCINO

Claimed
Done

ESNO

Claimed
Done

ProjectorCI_HashVec

Claimed
Done

ProjectorCI_Simple

Claimed
Done

ElementwiseCI

Claimed
Done

ProjectorCI

Claimed
Done

MRCI

Claimed
Done

ASCI

Claimed
Done

FCI_MO

Claimed
Done

MRPT2

Claimed
Done

AdaptiveCI

Claimed
Done

CI_Reference

Claimed
Done

V2RDM

Claimed
Done

Error initforte

Hi developers,

I'm trying to install forte and running the tests but I encounter this error

Traceback (most recent call last):
  File "/temp0/tm/source/psi4-foss2017/bin/psi4", line 248, in <module>
    exec(content)
  File "<string>", line 20, in <module>

ImportError: dynamic module does not define init function (initforte)

Could you please help me solve this error?
To compile forte I used:
gcc version 6.3.0
python-2.7.13
the most recent psi4 from github, all the tests of psi4 passed
the most recent ambit from github

Thanks in advance

No explicit/top-level license/copyright

Some of the forte files in src/ (and src/mini-boost in general, but that is external code I think) have a GPLv2+ license, but at least half of the files have no copyright or license header and there is no copyright/license statement in README.md or a separate COPYING.md/LICENSE.md

Restructure folders

Need to consolidate files in the src directory into fewer subfolders.

Too many warnings

Let's get rid of the compilation warnings.

Instructions:

Check the Claimed box to tell us you're working on a file/folder.
Check Done once you have fixed the warnings.
Find an unclaimed file/folder and repeat.

Be sure to refresh this page often to see when people are checking boxes.

Be sure to make your changes on a local branch named warnings_yourname

Travis fails

Travis is unable to compile forte. It fails with:

/home/travis/build/evangelistalab/forte/src/integrals/diskdf_integrals.cc:38:10: fatal error: 
'psi4/libthce/lreri.h' file not found

I'm not too sure why this happens, I can successfully run an compile on my laptop using the newest version of Psi.

Grand unification plan

Use polymorphism to encode different combinations of theories.

   // 1.
   SharedActiveSpaceSolver solver = build_active_space_solver(options.get_str("CAS_TYPE"));
   solver->compute_energy();
   auto references = solver->build_reference({0,1});
   code to average reference1 and reference2

   // 2. For all (h,S,M_S) or just one?
   SharedActiveSpaceSolver solver = build_active_space_solver(options.get_str("CAS_TYPE"));
   solver->set_states({2},{1,1}); // two states each with weight = 1
   solver->do_average(true);
   solver->compute_energy();
   auto reference = solver->reference();

   SemiCanonical semi(ref_wfn, options, ints, mo_space_info);
   semi.semicanonicalize(reference);
   auto cm = std::make_shared<CorrelationMethod>(ref_wfn, options, ints,mo_space_info,reference));
   cm->compute_energy();

Add test case for computations with CASSCF orbitals and frozen_docc

Once issue psi4/psi4#740 is addressed, add a DSRG-MRPT2 test case for N2 with core orbitals showing that energy is the same with natural and semicanonical orbitals.

'PCM Polarization Energy' randomly appear in SCF Energetics section

For a simple scf job with forte parameter specified (but no need to run forte), the 'PCM Polarization Energy' randomly appears in the SCF output '=> Energetics <=' section with the statement 'Alert: EFP and PCM quantities not currently incorporated into SCF psivars.'

A sample input is

import forte

molecule H2O{
0 1
O
H 1 1.1
H 1 1.1 2 104.5
}

set {
  basis sto-3g
  scf_type pk
  e_convergence 10
  d_convergence 10
  r_convergence 10
}

set forte {
  job_type aci
}
energy('scf')

Sometimes the output appears as

=> Energetics <=

Nuclear Repulsion Energy =              8.0013322999746084
One-Electron Energy =                -120.2007809086825745
Two-Electron Energy =                  37.2576460440522581
PCM Polarization Energy =               0.0000000000000000
Total Energy =                        -74.9418025646557169

Alert: EFP and PCM quantities not currently incorporated into SCF psivars.

and sometimes just

=> Energetics <=

Nuclear Repulsion Energy =              8.0013322999746084
One-Electron Energy =                -120.2007809086825745
Two-Electron Energy =                  37.2576460440522581
Total Energy =                        -74.9418025646557169

This happens both on my mac and on the group linux cluster.
In my limited times of trial, I could not reproduce the randomness if all the lines involve forte are removed, but I noticed that the PCM lines only appear on the cluster, but never appear on my mac.
This appears as a memory issue, but I haven't found a solution.

Davidson-Liu improvements

The current implementation of Davidson-Liu seems to fail when the number of determinants is small (less than 100-200). There must be some small issue that needs to be fixed. A working example is the following

import forte

molecule mbenzyne{
  0 1
   C   0.0000000000  -2.5451795941   0.0000000000
   C   0.0000000000   2.5451795941   0.0000000000
   C  -2.2828001669  -1.3508352528   0.0000000000
   C   2.2828001669  -1.3508352528   0.0000000000
   C   2.2828001669   1.3508352528   0.0000000000
   C  -2.2828001669   1.3508352528   0.0000000000
   H  -4.0782187459  -2.3208602146   0.0000000000
   H   4.0782187459  -2.3208602146   0.0000000000
   H   4.0782187459   2.3208602146   0.0000000000
   H  -4.0782187459   2.3208602146   0.0000000000

  units bohr
}

set globals{
   basis                   DZ
   df_basis_mp2            cc-pvdz-ri
   reference               uhf
   scf_type                pk
   d_convergence           10
   e_convergence           12
   guess gwh
}

set forte {
  multiplicity 1
  frozen_docc            [2,1,0,0,0,0,2,1]
  restricted_docc        [3,2,0,0,0,0,2,3]
  active                 [1,0,1,2,1,2,1,0]
  root_sym               0
  nroot                  1
  active_space_solver    aci
  sigma                   0.001
  aci_enforce_spin_complete  true
  aci_add_aimed_degenerate false
  sci_project_out_spin_contaminants false
  diag_algorithm dynamic
}

scf = energy('scf')
energy('forte')

Investigate ACI-12 test case

PR #149 introduced some numerical instability in the ACI-12 test case that only show up on Macs.

Problem with FCIIntegral

We are trying to run a CI-NO computation on octatetraene. Here is the input.

import forte

memory 1 gb

molecule {
0 1
    H   0.971328   1.220141   0.000000
    H  -0.971328  -1.220141   0.000000
    H  -2.098090   0.984719   0.000000
    H   2.098090  -0.984719   0.000000
    H  -0.146884   3.418505   0.000000
    H   0.146884  -3.418505   0.000000
    H  -2.193473   4.766086   0.000000
    H   2.193473  -4.766086   0.000000
    H  -3.225698   3.230501   0.000000
    H   3.225698  -3.230501   0.000000
    C   0.000000   0.721498   0.000000
    C   0.000000  -0.721498   0.000000
    C   1.125020  -1.479523   0.000000
    C  -1.125020   1.479523   0.000000
    C   1.121077  -2.928812   0.000000
    C  -1.121077   2.928812   0.000000
    C   2.237388  -3.682282   0.000000
    C  -2.237388   3.682282   0.000000

no_reorient
}


set {
  docc           [13,2,2,12]
  basis          def2-tzvp
  scf_type       df
  df_basis_scf   def2-tzvp-jkfit
  df_basis_mp2   def2-tzvp-jkfit
  maxiter        100
  e_convergence  12
}
set forte {
  job_type             nojob
  cino                 true
  CINO_THRESHOLD       0.99
  cino_roots_per_irrep [1,0,0,1]
  int_type             df
}
E,wfn = energy('forte',return_wfn=True)

However this job will fail after the DF integrals are computed. When I run lldb, here is the error I get:

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGKILL
    frame #0: 0x000000010c465433 forte.so`std::__1::__split_buffer<double, std::__1::allocator<double>&>::__construct_at_end(unsigned long) + 131
forte.so`std::__1::__split_buffer<double, std::__1::allocator<double>&>::__construct_at_end:
->  0x10c465433 <+131>: vmovsd %xmm0, (%rax)
    0x10c465437 <+135>: movq   0x10(%rcx), %rax
    0x10c46543b <+139>: addq   $0x8, %rax
    0x10c46543f <+143>: movq   %rax, 0x10(%rcx)

and back trace

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGKILL
  * frame #0: 0x000000010c465433 forte.so`std::__1::__split_buffer<double, std::__1::allocator<double>&>::__construct_at_end(unsigned long) + 131
    frame #1: 0x000000010c465348 forte.so`std::__1::vector<double, std::__1::allocator<double> >::__append(unsigned long) + 648
    frame #2: 0x000000010c444e4b forte.so`std::__1::vector<double, std::__1::allocator<double> >::resize(unsigned long) + 123
    frame #3: 0x000000010c6b1e84 forte.so`psi::forte::FCIIntegrals::startup() + 132
    frame #4: 0x000000010c6b1d26 forte.so`psi::forte::FCIIntegrals::FCIIntegrals(std::__1::shared_ptr<psi::forte::ForteIntegrals>, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >) + 1894
    frame #5: 0x000000010c6b1f45 forte.so`psi::forte::FCIIntegrals::FCIIntegrals(std::__1::shared_ptr<psi::forte::ForteIntegrals>, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >) + 21
    frame #6: 0x000000010c1017b7 forte.so`std::__1::shared_ptr<psi::forte::FCIIntegrals> std::__1::shared_ptr<psi::forte::FCIIntegrals>::make_shared<std::__1::shared_ptr<psi::forte::ForteIntegrals>&, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> > >(std::__1::shared_ptr<psi::forte::ForteIntegrals>&&&, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >&&, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> >&&) + 3735
    frame #7: 0x000000010c68f6d2 forte.so`psi::forte::CINO::CINO(std::__1::shared_ptr<psi::Wavefunction>, psi::Options&, std::__1::shared_ptr<psi::forte::ForteIntegrals>, std::__1::shared_ptr<psi::forte::MOSpaceInfo>) + 2258
    frame #8: 0x000000010c690d4d forte.so`psi::forte::CINO::CINO(std::__1::shared_ptr<psi::Wavefunction>, psi::Options&, std::__1::shared_ptr<psi::forte::ForteIntegrals>, std::__1::shared_ptr<psi::forte::MOSpaceInfo>) + 29
    frame #9: 0x000000010c295bc8 forte.so`std::__1::shared_ptr<psi::forte::CINO> std::__1::shared_ptr<psi::forte::CINO>::make_shared<std::__1::shared_ptr<psi::Wavefunction>&, psi::Options&, std::__1::shared_ptr<psi::forte::ForteIntegrals>&, std::__1::shared_ptr<psi::forte::MOSpaceInfo>&>(std::__1::shared_ptr<psi::Wavefunction>&&&, psi::Options&&&, std::__1::shared_ptr<psi::forte::ForteIntegrals>&&&, std::__1::shared_ptr<psi::forte::MOSpaceInfo>&&&) + 3464
    frame #10: 0x000000010c27f18c forte.so`psi::forte::forte_old_methods(std::__1::shared_ptr<psi::Wavefunction>, psi::Options&, std::__1::shared_ptr<psi::forte::ForteIntegrals>, std::__1::shared_ptr<psi::forte::MOSpaceInfo>, int) + 2428
    frame #11: 0x000000010c2edc20 forte.so`forte + 1776
    frame #12: 0x00000001022a6a30 core.so`py_psi_plugin(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>) + 624
    frame #13: 0x00000001022a8357 core.so`std::__1::shared_ptr<psi::Wavefunction> pybind11::detail::argument_loader<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction> >::call_impl<std::__1::shared_ptr<psi::Wavefunction>, std::__1::shared_ptr<psi::Wavefunction> (*&)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>), 0ul, 1ul>(std::__1::shared_ptr<psi::Wavefunction> (*&&&)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>), pybind11::detail::index_sequence<0ul, 1ul>) + 71
    frame #14: 0x00000001022a81b3 core.so`void pybind11::cpp_function::initialize<std::__1::shared_ptr<psi::Wavefunction> (*&)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>), std::__1::shared_ptr<psi::Wavefunction>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>, pybind11::name, pybind11::scope, pybind11::sibling, char [62]>(std::__1::shared_ptr<psi::Wavefunction> (*&&&)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>), std::__1::shared_ptr<psi::Wavefunction> (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::shared_ptr<psi::Wavefunction>), pybind11::name const&, pybind11::scope const&, pybind11::sibling const&, char const (&) [62])::'lambda'(pybind11::detail::function_record*, pybind11::handle, pybind11::handle, pybind11::handle)::operator()(pybind11::detail::function_record*, pybind11::handle, pybind11::handle, pybind11::handle) const + 131
    frame #15: 0x000000010216e4a4 core.so`pybind11::cpp_function::dispatcher(_object*, _object*, _object*) + 884
    frame #16: 0x000000010012e302 libpython2.7.dylib`PyEval_EvalFrameEx + 3730
    frame #17: 0x00000001001377dc libpython2.7.dylib`PyEval_EvalCodeEx + 2092
    frame #18: 0x00000001000c0c1b libpython2.7.dylib`function_call + 347
    frame #19: 0x0000000100097761 libpython2.7.dylib`PyObject_Call + 97
    frame #20: 0x000000010012ecea libpython2.7.dylib`PyEval_EvalFrameEx + 6266
    frame #21: 0x00000001001377dc libpython2.7.dylib`PyEval_EvalCodeEx + 2092
    frame #22: 0x0000000100137988 libpython2.7.dylib`fast_function + 296
    frame #23: 0x000000010012e38a libpython2.7.dylib`PyEval_EvalFrameEx + 3866
    frame #24: 0x00000001001377dc libpython2.7.dylib`PyEval_EvalCodeEx + 2092
    frame #25: 0x0000000100137856 libpython2.7.dylib`PyEval_EvalCode + 54
    frame #26: 0x00000001001564e9 libpython2.7.dylib`PyRun_StringFlags + 121
    frame #27: 0x0000000100133ff3 libpython2.7.dylib`PyEval_EvalFrameEx + 27523
    frame #28: 0x00000001001377dc libpython2.7.dylib`PyEval_EvalCodeEx + 2092
    frame #29: 0x0000000100137856 libpython2.7.dylib`PyEval_EvalCode + 54
    frame #30: 0x00000001001563d4 libpython2.7.dylib`PyRun_FileExFlags + 164
    frame #31: 0x0000000100157709 libpython2.7.dylib`PyRun_SimpleFileExFlags + 409
    frame #32: 0x000000010016b1ca libpython2.7.dylib`Py_Main + 2938
    frame #33: 0x0000000100000f14 python`start + 52

I am confused why this is happening in the startup() function of FCIIntegral which just resize some std vector. Could this be related to the recently added json.hpp? Thanks.

Improvements to the Integral classes

Goals for a new PR

Develop the CustomIntegrals objects and introduce the ability to read integrals stored on disk I various formats (including FCIDUMP).
Introduce separate classes for integrals based on 3- or 4-dimensional tensors. Currently we derive all classes from ForteIntegrals as follows:

ForteIntegrals --|
                 -- ConventionalIntegrals
                 |
                 -- DFIntegrals
                 |
                 -- DiskDFIntegrals
                 .
                 .
                 .

This requires the ForteIntegrals interface to be too general. A better way would be to separate integrals based on 3- and 4- indices and write a consistent interface in two separate classes FourIndexIntegrals and ThreeIndexIntegrals

ForteIntegrals --|
                 -- FourIndexIntegrals  --|
                 |                        -- ConventionalIntegrals
                 |                        |
                 |                        -- CustomIntegrals
                 |                        
                 -- ThreeIndexIntegrals --|
                                          -- DFIntegrals
                                          |
                                          -- DiskDFIntegrals
                                          .
                                          .
                                          .

evangelistalab / forte Goto Github PK

forte's People

Contributors

Stargazers

Watchers

Forkers

forte's Issues

Recommend Projects

Recommend Topics

Recommend Org