Multiple cores writing on the used input file #7
Comments
|
Premessa: commento da profano siccome non ho mai usato la parte real-space
del solver e potrei perdermi dei pezzi.
Credo ci siano casi in cui possa essere utile avere input file diversi.
In linea di principo sarebbe utile per fare siti inequivalenti, uno
potrebbe volere un input file per ogni sito.
Al momento il driver dovrebbe poter essere scritto in maniera tale che la
variabile ed_input_file sia diversa per tutti i diversi processi e quindi
ciascuno può leggersi il suo file.
Dentro ED_INPUT_VARS vedo che save_file viene chiamato solo dal master
quindi il punto che hai indicato è l'unico dove gli altri processi salvano
il proprio input. Senza di quello non verrebbe mai salvato.
Attendo risposte da chi ha più familiarità con queste situazioni
…On Thu, Jun 13, 2024 at 12:11 PM Lorenzo Crippa ***@***.***> wrote:
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?
—
Reply to this email directly, view it on GitHub
<#7>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASVA45AR2SOC542YGC6TJJ3ZHFV5NAVCNFSM6AAAAABJICIAOOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM2TANZUGY3TOMY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Ciao Samuele, sono d'accordo che sarebbe una cosa utile, anche perchè ci sono delle possibilità che in questo momento o sono hardcoded o non sono accessibili (e.g. una U diversa per ogni sito). Però questo richiederebbe un secondo di riflessione, perchè dovremmo decidere ad esempio se l'utente debba scriversi N input file diversi, o se le quantità site-dependent possono essere inserite in un unico input file, o se il codice deve essere in grado di accettare input file diversi (chiamati come?) ma può defaultare a uno. Una soluzione che avrei per il problema così com'è adesso è che nella ed_solve_single si mette un if(fmpi_) prima di salvare l'input, e poi, solo nel caso specifico in cui fmp_ (cioè mpi_lanc) sia false, in ed_solve lattice mettere il print da parte del master (che non è lo stesso master di ed_solve_single quando il sito è uno solo) |
|
Sì, sono d'accordo che è una rapida soluzione per la situazione attuale.
Io intendevo però che al momento dovrebbe già essere possibile (credo, ho
solo guardato rapidamente alcune condizioni) fare Real-Space-DMFT con siti
differenti se nel driver vengono passate differenti variabili di input. Non
credo sia necessario ripensare il codice diverso da come è ora, rimane solo
questa cosa disturbante che nel caso i file siano lo stesso file vengono
riscritti da tutti i processi.
Tuttavia non so se qualcuno ha mai veramente fatto calcoli con, ad esempio,
U diverse fra vari siti quindi potrebbero esserci altri impedimenti.
Ad ogni modo la tua soluzione è totalmente ok per me 👍
…On Thu, Jun 13, 2024 at 1:52 PM Lorenzo Crippa ***@***.***> wrote:
Ciao Samuele,
sono d'accordo che sarebbe una cosa utile, anche perchè ci sono delle
possibilità che in questo momento o sono hardcoded o non sono accessibili
(e.g. una U diversa per ogni sito). Però questo richiederebbe un secondo di
riflessione, perchè dovremmo decidere ad esempio se l'utente debba
scriversi N input file diversi, o se le quantità site-dependent possono
essere inserite in un unico input file, o se il codice deve essere in grado
di accettare input file diversi (chiamati come?) ma può defaultare a uno.
Una soluzione che avrei per il problema così com'è adesso è che nella
ed_solve_single si mette un if(fmpi_) prima di salvare l'input, e poi, solo
nel caso specifico in cui fmp_ (cioè mpi_lanc) sia false, in ed_solve
lattice mettere il print da parte del master (che non è lo stesso master di
ed_solve_single quando il sito è uno solo)
—
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASVA45FEUBLIPGWYSYSJCATZHGBXNAVCNFSM6AAAAABJICIAOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGQZTMNJQGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Ah ok, ora capisco cosa intendi. Probabilmente la soluzione più pulita sarebbe una cosa tipo: |
|
Mi sembra una ottima soluzione!
…On Thu, Jun 13, 2024 at 2:35 PM Lorenzo Crippa ***@***.***> wrote:
Ah ok, ora capisco cosa intendi. Probabilmente la soluzione più pulita
sarebbe una cosa tipo:
ci aspettiamo variabili di inputfile diverse per ogni core (magari
decidendo un suffisso tipo quello di hamiltonian.restart). Se queste sono
tutte uguali impediamo a tutti i core tranne uno di scrivere. Per decidere
quale core scrive probabilmente ha senso mettere il write in
ed_solve_lattice, magari verso linea 347 (supponendo che in ed_solve_single
non venga fatto nulla di rilevante prima che save_input_file venga chiamata)
—
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ASVA45FDWWZ76PHPIPGLLLDZHGGXTAVCNFSM6AAAAABJICIAOOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRVGUZTCMZWGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
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'è
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'è
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?
The text was updated successfully, but these errors were encountered: