Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the broadcast of norm2 in ED_GF_NORMAL #2

Open
lcrippa opened this issue Jun 11, 2022 · 0 comments
Open

Fix the broadcast of norm2 in ED_GF_NORMAL #2

lcrippa opened this issue Jun 11, 2022 · 0 comments
Assignees

Comments

@lcrippa
Copy link
Collaborator

lcrippa commented Jun 11, 2022

as it stands, the norm of vvinit is broadcast in this way, whenever we need to add/remove a particle


if(MpiStatus)then
             if(MpiComm /= MPI_COMM_NULL)call Bcast_MPI(MpiComm,norm2)
             vecDim = vecDim_Hv_sector(jsector)
             allocate(vvloc(vecDim))
             if(MpiComm /= MPI_COMM_NULL) call scatter_vector_MPI(MpiComm,vvinit,vvloc)
             call sp_lanc_tridiag(MpiComm,spHtimesV_p,vvloc,alfa_,beta_)

this creates an issue when a large number of cores is used, and the vector is small: only the cores in mpi_comm_group will get the norm, the others will get nothing. Then when they creare impG, the weights will all be 0. When they try to invert it in order to get Sigma, they will fail.
The solution can be

a) move the bcast after the delete_hv_sector line, where the communicator is reset
b) implement the new functions added in the single-site code (e.g. tridiag_Hv_sector_normal)

b) is preferred for uniformity and future-proof

@beddalumia beddalumia self-assigned this Jun 13, 2022
beddalumia added a commit that referenced this issue Jan 10, 2023
This code has been increasingly diverging with respect to the single site
one lately (or perhaps since ever). Not only on the key aspects allowing
for treating clusters of sites, but in general in many other points of the
shared infrastructure. I believe it may be time to pay a fair amount of
this /technical debt/ and start working actively to reunite as many parts
as we can, so to make it easier working on shared updates and eventually
merge everything in a unique library (which I suppose is what we want to
accomplish eventually... though not so easy to define a good way to do it
for now).

Here I start trying to bring in something that has been missing for a very
long time, namely the "new" object oriented treatment of global (or pseudo
global) sector quantities. Currently the CDMFT code features only a type
for the sector *map* and not the type(sector) containing the map itself,
alongside its spin-resolved dimensions, Nlanc, etc. This makes very uneasy
to compare and import code from the single site code, which has built a lot
on that baseline, in several years of development already.
Hence let's start defining here this type(sector) too, excluding the fields
that are obviously unused at the moment (phonon related, NONSU2&SUPERC...),
and making build_sector and delete_sector work on these objects instead of
the maps alone. This already triggers an inevitable cascade of changes for
every call to those procedures.

This directly allows to import the 'tridiag_Hv_sector' procedure, which has
been needed for a long time to address issue #2, and now should enable a
quick import/adaptation of the spin and charge impurity susceptibilities,
from LIB_DMFT_ED.

Should the refactory prove too heavy/problematic we would device a quicker
fix to the issue and recode from scratch the susceptibilities, giving up
the nice infrastructure, on a different branch. Hopefully this would not
be the case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants