search

aamaricci / EDIpack2.0

A Massively Parallel Exact Diagonalization solver for generic Quantum Impurity problems.
0 stars 2 forks source link

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

Closed lcrippa closed 4 months ago

lcrippa commented 5 months ago

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 +iG2 -(1+i)G_aa -(1+i)G_bb)

lcrippa commented 5 months ago

In realtà il discorso qui sopra non è corretto, perchè in G1 e G2 i termini bra e ket dovrebbero essere ribaltati.

Sto testando un caso (t2g con soc) e U=0; la self-energia dovrebbe essere 0 a tappeto.

lcrippa commented 5 months ago

Update: fatto un test con U=0 e SOC NONSU(2), le componenti off-diagonali di Sigma vengono nonzero (non accludo immagine perchè sono un cretino e ho cancellato la cartella per sbaglio). Faccio un altro test con la "vecchia" convenzione, dovrebbe venire 0 a tappeto.

Ho un'idea del perchè, nel caso, c'è stata questa discrepanza. Nel vecchio codice (dmft-ed) la versione "normal" e quella "sc" hanno la vecchia convenzione, nonsu2 ha la nuova. Ora, quel codice aveva in ED_HAMILTONIAN un bug per cui H veniva costruita al contrario. Questo non è rilevante nel caso normal, ma lo diventa nel caso nonsu2 se per esempio ci sono termini SOC local. Siccome conti NONSU2 all'epoca erano stati fatti, non potrebbe essere che una sigma inverosimile era stata notata, ma la sua origine era stata erroneamente attribuita alla routin che crea G, invece che a quella che crea H?

aamaricci commented 5 months ago

Bene, ma non benissimo. I conti CDMFT sono salvi.

Direi che a occhio i casi nonSU2 con simmetrici anche sono salvi. Aspettiamo questo tuo secondo check. Poi controllo a cascata i dati del BHZ con eccitoni e direi che Gabriele deve controllare il suo caso Kane-Mele con Sx>0, che pero' sara' quasi certamente untouched dato che e' locale e totalmente simmetrico.

Sul motivo, non so pronunciarmi. E' possibile, ma difficilmente verificabile. Abbiamo fatto vari tests a piu' riprese, io certamente ho controllato il caso BHZ-Eccitonico contro la soluzione MF, non vedendo problemi non ho ricontrollato il segno. Certamente una svista da parte mia.

On Mon, May 20, 2024 at 1:54 PM Lorenzo Crippa @.***> wrote:

Update: fatto un test con U=0 e SOC NONSU(2), le componenti off-diagonali di Sigma vengono nonzero (non accludo immagine perchè sono un cretino e ho cancellato la cartella per sbaglio). Faccio un altro test con la "vecchia" convenzione, dovrebbe venire 0 a tappeto.

Ho un'idea del perchè, nel caso, c'è stata questa discrepanza. Nel vecchio codice (dmft-ed) la versione "normal" e quella "sc" hanno la vecchia convenzione, nonsu2 ha la nuova. Ora, quel codice aveva in ED_HAMILTONIAN un bug per cui H veniva costruita al contrario. Questo non è rilevante nel caso normal, ma lo diventa nel caso nonsu2 se per esempio ci sono termini SOC local. Siccome conti NONSU2 all'epoca erano stati fatti, non potrebbe essere che una sigma inverosimile era stata notata, ma la sua origine era stata erroneamente attribuita alla routin che crea G, invece che a quella che crea H?

— Reply to this email directly, view it on GitHub https://github.com/aamaricci/EDIpack2.0/issues/6#issuecomment-2120307266, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRDWDRAZ42FKQYDMWHHR3ZDHP57AVCNFSM6AAAAABH7KGZ46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGMYDOMRWGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

lcrippa commented 5 months ago

Allora: ho controllato il modello SOC con NONSU2 e la "vecchia convenzione". Ora tutte le componenti si Sigma sono 0 a tappeto se U è 0. Quindi c'era effettivamente un bug qui. Non posso allegare la patch perchè Linux è stronzo ("this is a known bug"), ve la mando per mail. Controllate se vi torna.

aamaricci commented 5 months ago

Confirmed!

Applicando la patch di Lorenzo nel caso BHZ-Eccitonico il risultato non cambia: Sigma=0 a tappeto con Uloc=0. Aspettiamo la conferma di Gabriele per chiudere ma direi che per simmetria nei casi fatti fin'ora (e pubblicati che e' quello che conta) non ci sono problemi creati dal bug.

Well done, Lorenzo.

On Mon, May 20, 2024 at 3:53 PM Lorenzo Crippa @.***> wrote:

Allora: ho controllato il modello SOC con NONSU2 e la "vecchia convenzione". Ora tutte le componenti si Sigma sono 0 a tappeto se U è 0. Quindi c'era effettivamente un bug qui.

— Reply to this email directly, view it on GitHub https://github.com/aamaricci/EDIpack2.0/issues/6#issuecomment-2120509696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRDWDR3RZMYHHGUR335ITZDH55HAVCNFSM6AAAAABH7KGZ46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGUYDSNRZGY . You are receiving this because you commented.Message ID: @.***>

lcrippa commented 5 months ago

fai tu il commit?

aamaricci commented 5 months ago

Aspetto Gabriele, ma se vuoi puoi fare tu. Mi pare più giusto.

Il giorno lun 20 mag 2024 alle 18:09 Lorenzo Crippa < @.***> ha scritto:

fai tu il commit?

— Reply to this email directly, view it on GitHub https://github.com/aamaricci/EDIpack2.0/issues/6#issuecomment-2120760702, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRDWFFQGCZ32UUZAPSTZ3ZDIN4DAVCNFSM6AAAAABH7KGZ46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQG43DANZQGI . You are receiving this because you commented.Message ID: @.***>

lcrippa commented 5 months ago

Ah no no, nessun problema. Scusa, mi ero dimenticato. Ok aspettiamo i test di Gabriele

beddalumia commented 4 months ago

Ciao, scusate l'attesa. Per il Kane Mele ho provato (t2=0.3*t1) U=0 e U=9 (molto magnetizzato, nel piano). U=0 non succede nulla di strano alle componenti off-diagonali della sigma (sono nulle E-9 in entambi i casi). U=9 parte imaginaria identicamente nulla e parte reale sovrapposta al conto vecchio (LIB-DMFT-ED v0.6.0), errore assoluto E-3. Forse potrebbe essere piu' piccolo ma sono cambiate tante cose nel codice nel frattempo dai e essendo a saturazione la sigma e' molto grande (qualcosa come 3.5E0). Penso sia a posto.

aamaricci commented 4 months ago

Perfetto, grazie mille. Molto Confortante. Se con U=0 non succede nulla siamo a l’osto.

Ciao A

Il giorno mer 22 mag 2024 alle 15:18 Gabriele Bellomia < @.***> ha scritto:

Ciao, scusate l'attesa. Per il Kane Mele ho provato (t2=0.3*t1) U=0 e U=9 (molto magnetizzato, nel piano). U=0 non succede nulla di strano alle componenti off-diagonali della sigma (sono nulle E-9 in entambi i casi). U=9 parte imaginaria identicamente nulla e parte reale sovrapposta al conto vecchio (LIB-DMFT-ED v0.6.0), errore assoluto E-3. Forse potrebbe essere piu' piccolo ma sono cambiate tante cose nel codice nel frattempo dai e essendo a saturazione la sigma e' molto grande (qualcosa come 3.5E0). Penso sia a posto.

— Reply to this email directly, view it on GitHub https://github.com/aamaricci/EDIpack2.0/issues/6#issuecomment-2124778278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRDWGCMI6XXLL4HS4NQJLZDSLKBAVCNFSM6AAAAABH7KGZ46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUG43TQMRXHA . You are receiving this because you commented.Message ID: @.***>