scm-nv / nano-qmflows Goto Github PK

• On-the-fly update of terminated single point calculations. Now it just prints everything at the beginning and at the end.
• On-the-fly update of overlap files during reading.
• Adding version of qmworks-namd at the beginning of the file, including branch, latest branch update. Issue a warning when there is a most recent version available.

The cell_parameters input keyword should accept one of the following three types:

• float
• [float, float, float]
• [[float, float, float], [float, float, float], [float, float, float]]

Currently it only accepts the first type

There is a bug in the computation in the momentum density using the Fourier transform for a molecular orbital according to this paper.

The derivative couplings computations are started once all the molecular orbitals have been calculated. Then, all the coupling calculation are scheduled, holding in memory all the molecular orbitals until they are requested. It cause a huge memory consumption.

In case of a NPT trajectory or a set of differently shaped structures, the cell parameters change at each structure. It'd be nice to update the cell parameters values by reading an external file (like the .cell from cp2k) or by using a list of lists with the cell parameters.

Use mpi4py

The default implementation uses python multiprocessing, unfortunately it bound to a single node and therefore not suitable for large computing infrastucture.
Libraries like dispy and mpi4py solve this issue. Therefore it would be great it the integrals can be distributed using these libraries.

The current implementation is slow and consumes a lot of memory. Therefore the botleneck computation will be accelerated with numba instead of cython and the parallel distribution will run using Dask.

Drop the dependence from PYXAID and just do-it-yourself

The CP2K molecular orbital file are huge and also cause problem with the restart since it does keep on appending data

• Adding documentation and possibly making them more general. For example, adding a command parser to remove_couplings.py

make the mergeHDF5 script generic for all kind of group structures.

Reduce the number of parameters receive but the workflow functions

Split the Molecular Orbitals into HOMOs and LUMOs, avoiding crossing between the HOMOs and LUMOs.

Move the options of distribute_jobs.py to a yaml file

SCOOP is another library to distribute the computations.

Currently the workflow_coupling implementation works in such a way that if the CP2K calculation fails due to a SCF convergence problem, further calculation are carried out even though they contain garbage results.
If a CP2K calculation fails we should relaunch an OT calculation to compute new more accurate guess for the Wave function.

Before moving to libinit to compute the integrals, it would be great if we get rid on unused dependencies

Use the new input standard to rewrite the electron transfer workflow

This should reduce the calculation of the overlap matrices by a factor of 2

Distribute the integrals computation with parallel python

the libint seems a great library to compute the multipole integrals

CP2K interface in qmworks has change. Fix then coupling calculation accordingly.

Check Properly that either the gcc or icc commands are available

Instead of calculating excited states as single Slater determinants, they will be computed in CIS approximation. Accuracy will be improved.

Currently the input specification is quite verbose, I would be great to replace the yaml input for something more simple like:

workflow:
  distribute_derivative_couplings
project_name: FAPbI3
dt: 1
algorithm: "levine"
tracking: False
path_traj_xyz: "../../2.6nm_FAPbI3_PBE_MDRES-pos-1.xyz"
blocks: 5

workdir: "."
path_hdf5: "FAPbI3.hdf5"
scratch_path: "/tmp/test/derivative_couplings"
runner: multiprocessing
job_scheduler:
  scheduler: SLURM
  nodes: 1
  tasks: 24
  wall_time: "24:00:00"
  load_modules: "source activate qmflows\nmodule load eb\n module load CP2K/5.1-foss-2017b\n"

cp2k_general_settings:
  nHOMO: 100    
  path_basis: "/home/v13/cp2k_basis/BASIS_MOLOPT"
  path_potential: "/home/v13/cp2k_basis/GTH_POTENTIALS"
  potential: "GTH-PBE"
  basis: "DZVP-MOLOPT-SR-GTH"
  cell_parameters: 45.0
  cell_angles: [90.0, 90.0, 90.0]

cp2k_settings_main:
    specific:
      template: pbe_main

cp2k_settings_guess:
     mo_index_range: [1933, 2182]
     specific:
      template:
        pbe_guess

Fix the following numpy warnings:

test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:425: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    return np.stack(sum(len(x) for x in ys[i]) for i in range(len(mol)))
test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:455: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    hardness_vec = np.stack(hardness(mol[i][0]) for i in range(n_atoms)).reshape(n_atoms, 1)
test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:142: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    for i in range(nocc*nvirt))
test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:387: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    output[:, 6] = np.hstack(np.max(xia[:, i] ** 2) for i in range(nocc*nvirt))
test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:393: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    xia[:, i] ** 2)) for i in range(nocc*nvirt)).reshape(nocc*nvirt)
test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:396: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    output[:, 7] = np.stack(excs[index_weight[i]][0] for i in range(nocc*nvirt)) + 1
test/test_absorption_spectrum.py::test_oscillators_multiprocessing
  /home/travis/build/SCM-NV/qmflows-namd/nac/workflows/workflow_stddft_spectrum.py:400: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16 and will raise an error in the future.
    output[:, 9] = np.stack(excs[index_weight[i]][1] for i in range(nocc*nvirt)) + 1

Currently the function lazy_schedule_couplings all the molecular orbitals coefficients (100 HOMOs and 100 LUMOs) and compute all the coupling between them.
Instead of calculating all the coupling the function should allow the user to choose how many MO she wants to use.

On the previous implementation the overlaps and the multipoles the integral were computed separately. In the current implementation both the overlap and the multipole integrals are computed when the multipole funcion is called.
Avoid the double computation of the overlaps by calling the multipole only once.

Implementing spin-orbit coupling as a perturbation for improved couplings. This is especially important for excited states in perovskites.

Computing at two consecutive time steps the non-adiabatic coupling vectors from excited states computed at the TDDFT level of theory. The calculation can follow the approach from :
J. Phys. Chem. Lett., 2015, 6 (21), pp 4200–4203

• The overlap matrix at time t is now defined as : S(t) = <phi_t | phi_t+dt> . It should be : S(t+dt) = <phi_t | phi_t+dt>
• The coupling calculated using the Levine scheme is evaluated at time: t+dt/2
• The energy should be evaluated also at time t+dt/2 by doing an interpolation between two time step: E(t)+E(t+dt)/2

This addition will help in the analysis of the wavefunction obtained at the DFT level. It requires the overlap, dipole and quadrupole matrices in AO basis that are already implemented.

This may be done via some ADF input tricks without computing explicitly the S matrix in AO basis.

Testing the code to calculate transition dipole moments

Make the Workflow_coupling usable with other packages different of CP2K

The std_workflow finishes with the following error:

nac/workflows/workflow_stddft_spectrum.py", line 475, in construct_A_matrix_tddft
 k_iajb = pqrs_K[:nocc, nocc:, :nocc, nocc:].reshape(nocc*nvirt, nocc*nvirt)
ValueError: can only specify one unknown dimension

Follow the unavoided crossing between molecular orbitals to preserve the initial order of the states.
see: dentification of unavoided crossings in nonadiabatic photoexcited dynamics

Currently the user needs to specified the for a cp2k run something like:

  settings_main:
    potential: "GTH-PBE"
    basis: "DZVP-MOLOPT-SR-GTH"
    cell_parameters: 38.0  
    cell_angles: [90.0, 90.0, 90.0]
    specific:
      cp2k:
        force_eval:
          subsys:
            cell:
              periodic: "None"
            kind:
              Cs:
                BASIS_SET: DZVP-MOLOPT-SR-GTH-q9
                POTENTIAL: GTH-PBE-q9
              Pb: 
                BASIS_SET: DZVP-MOLOPT-SR-GTH-q4
                POTENTIAL: GTH-PBE-q4
              Br: 
                BASIS_SET: DZVP-MOLOPT-SR-GTH-q7
                POTENTIAL: GTH-PBE-q7
          dft:
            BASIS_SET_FILE_NAME: "/home/v13/cp2k_basis/BASIS_MOLOPT"
            POTENTIAL_FILE_NAME: "/home/v13/cp2k_basis/GTH_POTENTIALS"
            xc:
              xc_functional: "pbe"
            scf:
              eps_scf: 0.0005
              max_scf: 200
              added_mos: 35
            print:
              mo:
                mo_index_range: "1453 1507"

While in the input for the workflow the keywords nHOMO and ci_range are mandatory. The mo_index_range is the same keyword that ci_range (except one is a tuple and the other a str).
While the added_most can be deduce like:

added_mos = ci_range[1] - ci_range[0] - nHOMO + 1

Therefore the following actions are required:

• Replace ci_range keyword by mo_index_range and add it to the general settings
• Compute the added_mos keyword based on the available info
• Create templates for the PBE and PBE0 computations in CP2K

We have now some simulations where the time step is either 2.5fs and 5fs. We will run into problems when delta_t is included in the calculation of the coupling. We assume now that delta_t = 1fs always (I guess).

The current implementation does not follow the THOMAS-REICHE-KUHN sum rule

Currently the coupling calculation algorithm does not distinguish between the avoided and the trivial crossings. The trivial crossing must have a value of zero while the avoided crossings are different of zero.

The figure below some of the crossings that are wrongly treated as trivial, but there are not such crossings,

Replace all the jsonschemas with the schema library.