alpscore / ct-hyb-segment Goto Github PK

Replace greens_function.h with alps::gf.

With the following parameter file:

  1 SC_LOOP=SINGLE_SITE
  2 FLAVORS=2
  3 U=6.0
  4 MU=0
  5 t=1
  6 tprime=0
  7 N=500
  8 NMATSUBARA=500
  9 BETA=1.0
 10 H=0
 11 G0_OMEGA_INPUT ="G0_omega_input"
 12 G0_OMEGA_OUTPUT ="G0_omega_output"
 13
 14 MAX_TIME=2000           # Time limit for each iteration
 15
 16 [sc]
 17 MAX_IT=5               # Maximum iterations
 18
 19 [solver]
 20 # Replace ${CTHYB_INSTALL_DIR} with CT-HYB-SEGMENT installation path
 21 # Replace ${MPI_EXEC} with proper MPI commands
 22 SOLVER="${MPI_EXEC} ${CTHYB_INSTALL_DIR}/bin/alps_cthyb"
 23 INFILE_H5GF="alps_solver_in.h5gf"
 24 OUTFILE_H5GF="alps_solver_out.h5gf"
 25
 26 [cthyb]
 27 DMFT_FRAMEWORK=1        # Required for self-consistency
 28 N_MEAS=5
 29 THERMALIZATION=1000
 30 SWEEPS=1000000000
 31 TEXT_OUTPUT=0
 32 MEASURE_freq=1          # For frequency mesurement

Dear Dr. Antipov,

I'm trying to compile the cthyb code, but it shows the following error, which seems to be the problem between boost and mpi. I'm wondering how to solve this problem? Thank you!

Scanning dependencies of target alps_hyb_exp
[ 8%] Building CXX object CMakeFiles/alps_hyb_exp.dir/hybsim.cpp.o
In file included from /usr/include/boost/mpi/allocator.hpp(15),
from /usr/include/boost/mpi.hpp(22),
from /usr/local/include/alps/utilities/boost_mpi.hpp(13),
from /usr/local/include/alps/accumulators/mpi.hpp(16),
from /usr/local/include/alps/accumulators/feature.hpp(22),
from /usr/local/include/alps/accumulators/feature/mean.hpp(12),
from /usr/local/include/alps/accumulators/wrappers.hpp(12),
from /usr/local/include/alps/accumulators/accumulator.hpp(13),
from /usr/local/include/alps/accumulators.hpp(10),
from /usr/local/include/alps/mc/mcbase.hpp(12),
from /home/thlee/alps-cthyb/hyb.hpp(31),
from /home/thlee/alps-cthyb/hybsim.cpp(35):
/usr/include/boost/mpi/config.hpp(20): catastrophic error: cannot open source file "mpi.h"
#include <mpi.h>
^

compilation aborted for /home/thlee/alps-cthyb/hybsim.cpp (code 4)
make[2]: *** [CMakeFiles/alps_hyb_exp.dir/hybsim.cpp.o] Error 4
make[1]: *** [CMakeFiles/alps_hyb_exp.dir/all] Error 2
make: *** [all] Error 2

Dear ALPS team,
I am trying to run some model calculations using ALPS. Sometimes I get the error as shown in the attached screenshot and the calculation gets stopped. Will you please help me out in understanding the problem here and get the solution.

Some of the parameters I am using are,
'SWEEPS' : 1000000000,
'THERMALIZATION' : 1000,
'SEED' : 42*mpi.rank,
'N_MEAS' : 1000,
'N_MATSUBARA' : 1024,
'N_TAU' : 4000,
'N_HISTOGRAM_ORDERS' : 300,

Thank you
SUJAN K K

Dear developers,

I was wondering about the Hartree/high-frequency limit of the Selfenergy
when using a frequency-dependent interaction.
When I evaluate the local Hartree+Fock diagrams myself I get the same expression
as formula (3) in the hybdoc.pdf, except for the 1/2 in front of the second sum, which I think
is just a typo.
Though, when running a simple 1-orbital model calculation the high-frequency limit
of the Selfenergy determined by the solver differs from this formula. Its value is instead
given by:
(N is the sum of the up/down occupation, n is the occupation of a single channel, paramagnetic)

-2K'(0)*(N-1) + U*n

instead of the formula from the hybdoc.pdf and my derivation

-2K'(0)*N + U*n

Also for a multiorbital calculation with U,J this holds.
Do you know why this is the case?

Hi,
I was wondering when the python bindings would be re-enabled, and how much (if anything) still works on that end.

Dear developers,

when I run the solver doing a large number of sweeps the program crashes every time
the number of sweeps exceeds the range of an unsigned integer.

For example, if I run a 3-orbital calculation, beta=40 on 20 cores,
after about 36 minutes I get still a valid result:

total (effective) number of sweeps, normalized by N_meas: 4.20709e+09
Simulation details after 210624900 sweeps...

But after 38 minutes, which then exceeds 4.294e+09 sweeps, I get the error message:
"insert segment end time could not be inserted."
and the code exits.

best regards,
Steffen

Dear developers,

I found that the hybridization matrix is rebuit everytime in remove_antisegment.
https://github.com/ALPSCore/CT-HYB-SEGMENT/blob/master/hybconfig.cpp#L69

Is it necessary? It seems that this line should be commented out as in other methods such as remove_segment.

The thing is that, at low temperature, the program often stops with an error message "in dgesv: info was not zero." This error is raised in invert function, which computes the inversion of large-size matrix, e.g., 100 x 100.

Best regards,
Junya Otsuki

In line 214 of hybmatrix.cpp, the base object (bias_matrix) is copy-constructed as "bup". However, in the subsequent lines this bup object was never used; it is "this", which points to a derived object (hybmatrix), getting rebuilt. At the end of this function call, the bup object is destroyed.

Based on a few quick tests, I think killing line 214 can gain about 1% efficiency (acceptance rate of removing an antisegment times about 0.3~0.5, as creating and destroying a blas_matrix object involves memory allocation, which is expensive). While it's probably not particularly appealing to you, I post it anyway as it's just a quick fix. Let me know if I'm wrong.

ps. I did the test on the old version of this code that came with ALPS, not the ALPSCore one, so it might be slightly different.

According to @leofang

This is a bug report associated a working fix for the hybridization solver (cc: Dr. Gull, Dr. Antipov); the ALPS library 2.2.b3 works fine.

Using gdb, it is clear that the variable "info" in line 282 of hybblasmatrix.hpp (or line 280 in the GitHub-hosted version) is declared but not properly initialized, so depending on the compiler and the environment (I tested on two different machines with different Linux distributions) a nonzero value could be assigned to this variable, causing dgesv to complain. To fix it, just initialize it with zero. Changing CMAKE_BUILD_TYPE (as I proposed earlier) does not guarantee to avoid this bug.

Fixed it now with 9427fc3