evangelistalab / forte Goto Github PK
View Code? Open in Web Editor NEWHome Page: http://www.evangelistalab.org
License: GNU Lesser General Public License v3.0
Home Page: http://www.evangelistalab.org
License: GNU Lesser General Public License v3.0
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.
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();
Proceed with caution until this is resolved
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.
PR #149 introduced some numerical instability in the ACI-12 test case that only show up on Macs.
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?
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
------------------------------------------------------------------------
[10, 11, 12, 18]
)ACTIVE
, etc.)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!
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
Fix compilation with psi4 from master after major infrastructure changes. Will be addressed by pull request #33.
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.
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
CASSCF
CC
DMRGSCF
MRDSRG_SO
SOMRDSRG
DSRG_MRPT
DWMS_DSRGPT2
ACTIVE_DSRGPT2
CINO
MRCINO
ESNO
ProjectorCI_HashVec
ProjectorCI_Simple
ElementwiseCI
ProjectorCI
MRCI
ASCI
FCI_MO
MRPT2
AdaptiveCI
CI_Reference
V2RDM
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.
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.
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.
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
.
.
.
Need to consolidate files in the src
directory into fewer subfolders.
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
Shouldn't be too difficult, will result in at least ~2x speedup in building DF integrals
Let's get rid of the compilation warnings.
Instructions:
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
base_classes/
fci/
sparse_ci/
forte_old_options.cc
main.cc
options.cc
casscf/
finite_temperature/
forte_options.cc
mrdsrg-helper/
orbital-helpers/
srg/
cc/
forte-def.h
forte_options.h
mrdsrg-so/
pci/
v2rdm/
ci_rdm/
forte.h
helpers/
mrdsrg-spin-adapted/
python_api.cc
version.h
dmrg/
forte_old_methods.cc
integrals/
mrdsrg-spin-integrated/
sci/
version.h.in
All changes merged to master
...
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')
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>
Hi,
It is posible to print the 2-RDM matrix for the following methods ACI,PCI,DSRG and MRCI methods ?
Best,
Jose Luis
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:
retransform_integrals()
can be different from ii) computing U^+ H_old U.diag_algorithm
does not help.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.
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.
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.
make_spin_complete() in the DetermiantHashVec class produces determinants with wrong numbers of electrons.
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:
double
option and introduce appropriate checks.Tasks to perform:
Here is a wishlist of infrastructure improvements related to exposing Forte via pybind11
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')
Add test cases that run and check the value of results obtained using the MRPT2
Roadmap:
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
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.
With the release of Psi4 1.1 Forte no longer compiles.
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);
// }
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.
Recent changes to Ambit seem to have broken Travis CI. See jturney/ambit@324e049 for changes made by @jturney.
With the repository change all issues got lost. Please repost old issue (if still relevant) and feature requests.
Here are the TODO list for PR #182 . I just put them here in case I forget after merging to master branch.
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.