1. 06 Sep, 2019 6 commits
  2. 05 Sep, 2019 1 commit
  3. 02 Sep, 2019 3 commits
  4. 29 Aug, 2019 4 commits
    • Yann Pouillon's avatar
      Merge branch 'issue62' into 'master' · 171168bf
      Yann Pouillon authored
      [install] add an install target for esl-demo, choose the prefix with -DCMAKE_INSTALL_PREFIX, fixes #62
      
      Closes #62
      
      See merge request ElectronicStructureLibrary/esl-demo!147
      171168bf
    • Nick Papior's avatar
      bug: fixed wrong interface in elsi_fake · ae8777bb
      Nick Papior authored
      Now the smearing actually works!
      Also simplified the fermi-level calculation.
      Signed-off-by: Nick Papior's avatarNick Papior <nickpapior@gmail.com>
      ae8777bb
    • Nick Papior's avatar
      doc: updated install.rst and fixed WITH_ELSI support · e3840221
      Nick Papior authored
      Now cmake files are compliant to WITH_ELSI and tries to find it
      manually (if unspecified).
      Signed-off-by: Nick Papior's avatarNick Papior <nickpapior@gmail.com>
      e3840221
    • Nick Papior's avatar
      maint: clean-up of AC part · 9ed21b35
      Nick Papior authored
      A very big change in the AC part and overall structure of the
      SCF cycle etc.
      
      I try to give a comprehensive list of the changes and reasonings.
      Unless otherwise stated everything refers to AC
      
      1. Moved sparse_pattern and overlap matrix from system to basis_ac_t.
         Having type-dependent variables in the system is discouraged and
         this was just waiting to be moved.
      
      2. The sparse_pattern and overlap matrix now belongs to basis_ac_t
         which is also not completely optimal.
         basis_ac%init now also creates the sparse-pattern and the overlap
         matrix since they are intrinsic to the basis set.
         This means that there is a circular dependence for the overlap
         matrix calculation and required to move the type definition of the
         basic_ac_t to an *abstract* type > basis_ac_abc_t.
         We need to consider this since having separate modules for some
         operations may easily introduce these circular dependences.
      
         To alleviate this we need to have files with purely type definitions
         (*abstract* types) and thus allowing use of types.
      
      3. Added a calculate_DM to the density_ac type.
         TODO this needs to be somehow merged together with calc_density_matrix
         which uses ELSI.
         I think this functionality belongs to the density type and should
         probably be merged there at some point.
      
      4. Totaly removed the SCF cycle in the density_ac%calculate method.
         Now density_ac%calculate *only* expands the DM onto the grid
         (just as density_pw does with the states).
      
      5. Moved mulliken-analysis from a separate file into the density_ac
         type. Again, this is an intrinsic property of the density-matrix
         and should belong there. If we want to maintain separate files
         for different methods I think we should simply create a wrapper
         routine in the density_ac%mulliken_summary and then call the
         other routine.
      
         TODO: consider code layout 1) very long and comprehensive codes
         or 2) separate functionality codes called through the generic type
      
      6. For the hamiltonian_ac I have added two methods add_potential
         and eigensolver to follow the PW procedure.
      
         The add_potential simply calls the hamiltonian_ac_potential method.
         The eigensolver currently calls LAPACK and needs to be enabled for
         ELSI support.
      
         The hamiltonian_ac_t now uses states to store the states in.
      
      7. Since ELSI is now not required we needed a new method for calculating
         the occupations.
         I have somewhat done a copy-paste of ELSI methods (but much simpler).
         TODO there are still some issues with it and I need to clean this.
      
      8. energy_t%calculate now does not require states as input. I think
         this isn't necessary since this is very basis-type dependent.
         Energies should be calculated at points where the type allows
         and thus the energies type should be simple and basis-type agnostic.
      
      9. Fixed states initialization to account for spin.
         However, this still needs some fixtures due to smearing, i.e.
         when the smearing is large we should probably have some additional
         states to account for partial occupancies.
      
      10. density contains density_pw, I have renamed this to pw for consistency.
          Basically top-level types should have basis-type variables with their short
          names. This has now been fixed all-over (also for hamiltonian).
      
      11. density_ac calculate is now a bit weird. If states are *not* passed it will
          expand the current density matrix to the grid. If states are passed it will
          calculate the DM from the state object. This is a digress from the PW type
          but is due to their different nature. For now I think this logic is *OK*.
      
      12. scf had a major overhaul. The SCF loops for PW vs. AC are *very* different.
          Thus I have created a type routine in the "loop" contains segment to
          have them fully separate. Although there are some minor steps that
          overlaps I think having them truly separate is of much greater benefit
          due to the complex logic in both cases.
      
          In any case this can change later since the AC can do one of several things
          in the SCF-loop (i.e. starting from a DM or starting from a Hamiltonian).
      
          The AC scf loop came from density_ac%calculate.
      
      Now the flow and method names for AC and PW are more or less the same and AC now
      makes use of the states_t object.
      
      Build process changes:
      
      1. I still have issues compiling the bundle! Either this is due to my
         rather *obscure* setup or the bundle is not as easy to install.
         I can produce many bug-reports on the build-problems, if needed?
      2. I have enabled the possibility of compiling the demo without ELSI
         support. Currently the AC part does not require ELSI.
         Definition is WITH_ELSI (to follow nomenclature).
      3. As for PW support it merely prints out that it isn't supported during
         the SCF.
      4. I had to create an empty wrapper for ELSI-RCI
      Signed-off-by: Nick Papior's avatarNick Papior <nickpapior@gmail.com>
      9ed21b35
  5. 28 Aug, 2019 1 commit
  6. 27 Aug, 2019 1 commit
  7. 26 Aug, 2019 10 commits
  8. 19 Jan, 2019 2 commits
  9. 18 Jan, 2019 4 commits
  10. 17 Jan, 2019 3 commits
  11. 16 Jan, 2019 5 commits