qcmplab / lib_dmft_ed Goto Github PK

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 ***

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

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?

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

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)

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?

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