aamaricci / edipack2.0

A Massively Parallel Exact Diagonalization solver for generic Quantum Impurity problems.

EDIpack2.0: Massively parallel Exact Diagonalization for generic Quantum Impurity problems

A suitable extension of EDIpack: a Lanczos based method for the solution of generic Quantum Impurity problems, exploiting distributed memory MPI parallelisation. This updated version, aims to solve single-site, multi-orbital models, in either normal, superconducting (s-wave) or Spin-non-conserving (e.g. with Spin-Orbit Coupling or in-plane magnetization) phases, including electron-phonons coupling. The code works at zero and low temperatures.

See j.cpc.2021.108261 for further information about the underlying algorithms. Yet, suitable modifications have been developed to address the Superconducting and non-SU(2) channels.

Dependencies

The code is based on:

• SciFortran https://github.com/aamaricci/SciFortran

• MPI

Installation

Installation is available using CMake. In the current v0.0.1 API are only provided in Fortran. In a future release Python and C/C++ API will be included.
The software gives acces to the static library libedipack2.a and the related modules EDIPACK2

Clone the repo:

git clone https://github.com/aamaricci/EDIpack2.0 EDIpack2

And from the repository directory (cd EDIpack2) make a standard out-of-source CMake compilation:

mkdir build cd build cmake ..
make
make install
make post-install

Please follow the instructions on the screen to complete installation on your environment.
The library can be loaded using one of the following, automatically generated, files :

• pkg-config file in ~/.pkg-config.d/EDIpack2.pc
• environment module file ~/.modules.d/EDIpack2/<PLAT>
• homebrew bash script <PREFIX>/bin/configvars.sh

The CMake compilation can be controlled using the following additional variables, default values between < >:

• -DPREFIX=prefix directory <~/opt/EDIpack2/VERSION/PLAT/[GIT_BRANCH]>

• -DUSE_MPI=<yes>/no

• -DVERBOSE=yes/<no>

• -DBUILD_TYPE=<RELEASE>/TESTING/DEBUG

For any information contact the author as:
adriano DOT amaricci @ gmail DOT com

--

LICENSE
Copyright 2020- (C) Adriano Amaricci, Lorenzo Crippa, Alberto Scazzola, Gabriele Bellomia, Samuele Giuli, Giacomo Mazza, Francesco Petocchi

The software is provided with no license, as such it is protected by copyright. The software is provided as it is and can be read and copied, in agreement with the Terms of Service of GITHUB. Use of the code is constrained to author agreement.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

edipack2.0's Issues

Expected variable length in input file

Ciao, segnalo un problema minimale e di (i guess) facile soluzione: si ottiene questo errore se il numero di orbitali con cui si lavora è minore del massimo consentito dall'input file.

Variable ULOC updated to 0.000000000 0.000000000
*** Error in `/home/***/.bin/ed_bhz_2d': free(): invalid pointer: 0x0000000002b82790 ***

Segfault when ED_MODE is NORMAL, Jhflag !=0 and MPI is used

Hi, as per title.

I did some debugging and perhaps I found the culprit: in the file H_non_local.f90, version "stored", at lines 42(44) and 75(77) the code reads

call sp_insert_element(MpiComm,spH0nd,htmp,j,i)

if the indices i and j are inverted, the issue is not manifesting. For reference, in the nonsu2 code the interaction H is similarly constructed (as far as I gather) and at lines 80(82) and 112(114) the code reads

call sp_insert_element(MpiComm,spH0,htmp,i,j)

As far as I can see, i and j represent the same indices in both cases and the operators are applied in the same way.
May it be that in the first case i and j are swapped in the function call?

Controllare l'espressione per G_ab se le componenti off-diagonali sono asimmetriche

Copio qui una issue aperta su CDMFT, che però probabilmente è giusto

Ciao,

stavo riguardando il codice e confrontandolo con la versione NONSU2 del single site. Mi sono accorto di una discrepanza che potrebbe avere alcune conseguenze:

la premessa è che questo codice calcola G1=<c†_a+c†_b | c_a+c_b> e G2=<c†_a+ic†_b | c_a-ic_b> per le componenti offdiagonali. Se guardate a linea 96-98 di ED_GF_NORMAL.f90, la G off-diagonale è calcolata come 1/2(G1 -i*G2 -(1-i)G_aa -(1-i)G_bb).

Questo si può verificare controllando per esempio il fatto che il peso a linea 809 e 890 è -xi*norm2, quindi sta effettivamente sottraendo G2.

Ora, se si fa il conto con questa convenzione, quello che vien fuori non è G_ab, ma G_ba, se non ho sbagliato i calcoli.
Infatti questa implementazione risale al vecchio codice single-site, prima che N_up N_dw fossero disaccoppiati (ca. 2017).
Nel repo edipack2.0, adesso, viene usata un'altra convenzione: G1 e G2 sono calcolate come prima, ma la G off-diagonale è calcolata come 1/2(G1 +i*G2 -(1+i)G_aa -(1+i)G_bb), e qui sono d'accordo che questo effettivamente dia G_ab.

Ora, questo nella maggior parte dei casi potrebbe non aver alcun risvolto, ma consideriamo per esempio il BHZ, componenti G_sito12_orb12 e G_sito21_orb21. Queste hanno, per esempio, la parte immaginaria opposta. Non è che questo ci porta a costruire una G, e di conseguenza una Σ, ribaltate?

In ogni caso, una soluzione a questo sarebbe di portare la G anche qui alla nuova convenzione, ossia xi * norm2 e G_ab= 1/2(G1 +i*G2 -(1+i)G_aa -(1+i)G_bb)

Multiorbital problem

ED_OBSERVABLES_SUPERC.f90 at line 169 sectorI is deleted before spanning all orbitals, should be brought outside of for cycle

Possible error in analytic gradient for `bath_type='general'`

https://github.com/QcmPlab/LIB_DMFT_ED/blob/900859dcd2d33f44dee501bbd5870481ec355e84/src/ED_BATH/ED_FIT_GENERAL.f90#L526-L528

Since invH_knn is not initialized upstream in grad_delta_general I believe these are junk lines, perhaps a vestigia of some intermediate rewrite. Check them out please :)

@SamueleGiuli

Real-space DMFT Neigen initialization

in ED_MAIN.f90, in subroutine ed_solve_lattice_mpi the following is issued:

neigen_sector_ineq=0 ; neigen_total_ineq =0

this overrides the previous initialization and sets the number of required eigenvectors for every sector to 0 (of course then arpack fails). Could probably be fixed just by removing this line. I can do it if you agree

Multiple cores writing on the used input file

Ciao,

c'è una strana condizione che si verifica nel caso real-space DMFT se ogni core sta risolvendo un sito diverso: a riga 198-200 di ED_MAIN.f90 c'è

#ifdef _MPI    
    if(check_MPI().AND.fmpi_)call ed_set_MpiComm()
#endif

Questa condizione non è mai verificata, perch'è fmpi_ è settato a false all'interno di ed_solve_lattice. Di conseguenza il comunicatore interno non è inizializzato, e ok.

Il problema penso che sia sotto, a riga 207, dove c'è

if(MpiMaster)call save_input_file(str(ed_input_file))

perchè ogni core crede di essere il Master e quindi tutti scrivono nel logfile.

Prima domanda, è necessario che il file venga riscritto adesso? Viene già fatto in ED_read_input...?

Se fosse necessario, bisognerebbe o far scrivere ad ogni core su un inputfile diverso, o mettere questa print dentro a una if come if(check_MPI().AND.fmpi_) e fare fare il print in questo specifico caso all'interno di ed_solve_lattice.

Che ve ne pare?