You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
as it stands, the norm of vvinit is broadcast in this way, whenever we need to add/remove a particle
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
The text was updated successfully, but these errors were encountered: