Allow to influence the automatic scheme molsturm chooses to solve the SCF, i.e. the user should be able to

• change criteria when solvers are switched
• supply an arbitrary chain of solver algorithms and criteria to switch between them

This issue is related to #20, but the interfacing would not happen on the level of data formats,
but much rather on the python or c++ level using the programming interface the projects offer.

• Integrate with xcfun or libxc for XC functionals (see #22)
• Act as an external SCF supplier for pyscf
• Look how we could fit into the modular system of Psi4
• Employ orbkit for post-processing SCF data
• Solvent models using pcmsolver

Use the functionality of gint to plot MOs on an arbitrary grid in order to achieve the following:

• Export MOs and density to a VTK file
• Use matplotlib to construct an easy to use interactive plotting session for MOs and density

It would be nice to have coverage analysis in molsturm, too. The hard part is, that we would ideally test both the C++ as well as the python code and produce a common coverage.

Properly integrate with clang-tidy and fix all the issues suggested

• krims
• gint
• gscf
• molsturm

The tests should not have binary data (i.e. hdf5 files) in the repository, but instead this data should be downloaded from some remote location to not blow up the repository size.

Some points to be achieved:

• Add mechanisms to download data from servers (achieved in #36)
• Upload remaining large data files
• Enhance tests by a few larger cases

Right now the molsturm python state object is pretty much only a python dict, but it would be nice to link the state directly with an hdf5 file in a transparent way, such that large objects could be cached to disk and read later with ease and fully transparent to the user of molsturm.

Milestones:

• Implement new parameter interface (see #23)
• Replace state dict by state class
  • Lazy generation of ERI tensor and fock matrix as needed
  • Cache requested objects directly in file
  • Allow reading and writing such states to/from yaml
• Make sure the tests still work and give the same results.
• Prepare for state-driven workflow see #41.

With lazyten being integrated into Spack, it would be nice to get molsturm there, too.

Once this has been achieved one could actually use Spack to setup the build environment to test molsturm on Travis. See the Spack documentation chapter about this for example. The proposed change is therefore:

• In molsturm have submodules and a build system to build them together with molsturm
• Each individual submodule (krims, lazyten, gint and gscf) can be build and installed, but only if all required dependencies are met.
• This avoids the complicated and partially non-portable code to pull in the submodules as needed. If tests are desired or dependencies are needed, the setup can be achieved via Spack or needs to be done one-by-one manually.
• This is ok in my humble opinion, since the full-fletched project molsturm still comes with cmake build scripts to build all the submodules in one go if this is required.

Ideas about some work packages:

• Get all submodules into Spack:
  • gint
  • gscf
  • molsturm
  • tests for all of them (i.e. rapidcheck)
• Replace setup in molsturm such that a git clone followed by a cmake takes care of all required dependencies. Use ExternalProject and git submodules as needed. Take a look at Hunter and check whether that could be useful.
• Replace test system on Travis by a setup based on Spack. As we go along with doing this also (deprecate and) remove the unnecessary setup scripts and cmake modules.

This issue should serve as a collection of ideas for the extension of data and input formats supported inside molsturm and the lists here will probably continue to grow. The formats mentioned here are used by some wide-spread quantum-chemistry programs or packages and it would be nice to implement conversion functions and interface modules/classes for allow an easy interaction with these programs.

Data formats

• pyscf (most importantly the mo eri data)
• Psi4
• Gaussian Fchk
• Molpro FCIDump
• molden files

Input formats

• Gaussian
• Molpro
• ORCA
• Q-Chem
• Psi4
• TURBOMOLE (probably harder)

For this openbabel could be a useful resource. Look at how the people from the atomistic simulation environment (ASE) achieve this. Perhaps their efforts could be reused inside molsturm.

• Compile lazyten with bohrium
• Implement required solver interfaces in lazyten
• Setup and link molsturm with bohrium

Use libxc or xcfun to achieve this.

Integrate molsturm and the dependent packages with the
cmake mode FeatureSummary
in order to make it easier to manage and show the list of features
and which are enabled.
Probably it is a good idea to integrate this somehow into
krims/cmake/modules/ProjectFeatures.cmake.

This integration of FeatureSummary is especially important for

• lazyten (backend libraries and solvers)
• gint (integral libraries)
• molsturm (e.g. python packages and 3rd party libraries)

Many tests, especially the ones driven by python will also work if rapidcheck is not installed.
It would therefore be good to make rapidcheck an opitonal requirement and still allow testing in case it is not available.

This applies especially to the following modules:

• molsturm
• gint
• gscf

A rather good workflow for molsturm in my opinion would be based on "propagating"
states during each calculation step.
Roughly the interface I have in mind is:

# Get input parameters from yaml
file_dict = yaml.safe_load(file)
state = molsturm.State.from_dict(file_dict)
# or just set them
state = molsturm.State()
state.system = ...
state.basis = ...
# or first build parameter tree, then set them (maybe even omit this .. let's see)
params = molsturm.Parameters()
params.bla = ...
state.parameters = params

# Get guess from a few parameters
state1 = molsturm.scf.guess(system, basis, restricted=True, n_elec=)
# or from state containing previous solution and/or input parameters
state1 = molsturm.scf.guess(state)
# or a combination of both (where the explict parameters override)
state1 = molsturm.scf.guess(state, restricted=False)

# Run scf -> same interface
state2 = molsturm.scf.hartree_fock(state1)
state2 = molsturm.scf.self_consistent_field(state1, extra_overriding_params)

# Run posthf -> same interfaces
state3 = molsturm.mp.mp2(state2)
# or with parameters
state3 = molsturm.mp.mp2(state2, threshold=1e-6)

In this way

• Input parameters may contain fci or post-hf parameters
• All functions have the same interface (state plus optional, overriding parameters)
• For SCF and guess methods the state may be omitted

I think we should think about a more unified convention for the parameters.
I propose for example:

• n_max -> nmax (Since no number like for example n_diis_size)
• Similarly l_max, m_max -> lmax, mmax
• k_exp -> kexp