Problems installing unstable branch

[laurobbraz]

Dear TPRF community,

I hope this message finds you well. I've been through the task of installing TPRF from source in its unstable branch. My stable-branch installation works fine, but the unstable one returns an error during the "make" run. I hope you can help me to understand this issue.

Prerequisites

TRIQS stable version (installed fro source).
TPRF unstable version.
The error seems to be unrelated to specific versions of TRIQS.

Description

Although the stable-branch installation of TPRF works fine, the unstable one returns a series of errors during the "make" run. I am unsure if further errors will appear because the installation stops as soon as the following messages pop up.

Steps to Reproduce

Follow the documentation installation guides changing
$ git clone https://github.com/TRIQS/tprf tprf.src
to
$ git clone -b unstable https://github.com/TRIQS/tprf tprf_unstable.src

Expected behavior: Installation succeeds.

Actual behavior: Errors prevent finishing the installation.

Versions

Ubuntu 22.04.5 LTS (Jammy Jellyfish)

Additional Information

I'm attaching the errors below. What I could track down is that
"error: 'target_value_t' does not name a type" summarizes the problem.
The only file inside the build directory where 'target_value_t' appears is in
python/triqs_tprf/lattice_desc.py in the line

module.add_function ("target_value_t<chi_t_t>::regular_type triqs_tprf::chi_trapz_tau (triqs_tprf::chi_t_cvt chi_t)", doc = r"""""")

Error message:

[  1%] Building CXX object c++/triqs_tprf/CMakeFiles/triqs_tprf_c.dir/lattice/chi_imtime.cpp.o
In file included from /home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:24:
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.hpp:150:1: error: 'target_value_t' does not name a type
  150 | target_value_t<chi_t_t>::regular_type chi_trapz_tau(chi_t_cvt chi_t);
      | ^~~~~~~~~~~~~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.hpp:151:1: error: 'target_value_t' does not name a type
  151 | target_value_t<chi_t_t>::regular_type integrate_dlr_tau(chi_Dt_cvt chi_t);
      | ^~~~~~~~~~~~~~
In file included from /home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:23:
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/../mpi.hpp: In instantiation of 'auto triqs_tprf::mpi_view(const T&, mpi::communicator) [with T = triqs::mesh::cyclat]':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:57:22:   required from here
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/../mpi.hpp:42:15: warning: unused variable 'idx' [-Wunused-variable]
   42 |     for (auto idx : range(0, size)) {
      |               ^~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: In function 'triqs_tprf::chi_wr_t triqs_tprf::chi0_w0r_from_grt_PH(g_Dtr_cvt, g_Dtr_cvt, bool)':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:139:14: error: 'integrate_dlr_tau' was not declared in this scope
  139 |     auto I = integrate_dlr_tau(chi0_t);
      |              ^~~~~~~~~~~~~~~~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: At global scope:
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:154:1: error: 'target_value_t' does not name a type
  154 | target_value_t<chi_t_t>::regular_type integrate_dlr_tau(chi_Dt_cvt chi_t) {
      | ^~~~~~~~~~~~~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: In function 'triqs_tprf::chi_wr_t triqs_tprf::chi0_w0r_from_grt_PH(g_tr_cvt, g_tr_cvt)':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:321:21: error: 'chi_trapz_tau' was not declared in this scope; did you mean 'chi_tr_t'?
  321 |     auto int_chi0 = chi_trapz_tau(chi0_t);
      |                     ^~~~~~~~~~~~~
      |                     chi_tr_t
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: At global scope:
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:335:1: error: 'target_value_t' does not name a type
  335 | target_value_t<chi_t_t>::regular_type chi_trapz_tau(chi_t_cvt chi_t) {
      | ^~~~~~~~~~~~~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: In function 'triqs_tprf::chi_wr_t triqs_tprf::chi_w0r_from_chi_tr(chi_tr_cvt)':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:374:14: error: 'chi_trapz_tau' was not declared in this scope; did you mean 'chi_tr_t'?
  374 |     auto I = chi_trapz_tau(chi_tr[_, r]);
      |              ^~~~~~~~~~~~~
      |              chi_tr_t
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/../mpi.hpp: In instantiation of 'auto triqs_tprf::mpi_view(const T&, mpi::communicator) [with T = triqs::mesh::imfreq]':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/fourier.hpp:214:24:   required from 'auto triqs_tprf::fourier_wr_to_wk_general_target(Gf_type) [with Gf_type = triqs::gfs::gf_const_view<triqs::mesh::prod<triqs::mesh::imfreq, triqs::mesh::cyclat>, triqs::gfs::tensor_valued<4>, nda::C_stride_layout>]'
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:395:48:   required from here
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/../mpi.hpp:42:15: warning: unused variable 'idx' [-Wunused-variable]
   42 |     for (auto idx : range(0, size)) {
      |               ^~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: In function 'triqs_tprf::chi_Dwr_t triqs_tprf::chi_wr_from_chi_tr(chi_Dtr_cvt, int)':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:406:54: warning: unused parameter 'nw' [-Wunused-parameter]
  406 | chi_Dwr_t chi_wr_from_chi_tr(chi_Dtr_cvt chi_tr, int nw) {
      |                                                  ~~~~^~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp: In function 'triqs_tprf::chi_Dtr_t triqs_tprf::chi_tr_from_chi_wr(chi_Dwr_cvt, int)':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:411:54: warning: unused parameter 'ntau' [-Wunused-parameter]
  411 | chi_Dtr_t chi_tr_from_chi_wr(chi_Dwr_cvt chi_wr, int ntau) {
      |                                                  ~~~~^~~~
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/../mpi.hpp: In instantiation of 'auto triqs_tprf::mpi_view(const T&, mpi::communicator) [with T = triqs::mesh::dlr_imfreq]':
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/fourier.hpp:214:24:   required from 'auto triqs_tprf::fourier_wr_to_wk_general_target(Gf_type) [with Gf_type = triqs::gfs::gf_const_view<triqs::mesh::prod<triqs::mesh::dlr_imfreq, triqs::mesh::cyclat>, triqs::gfs::tensor_valued<4>, nda::C_stride_layout>]'
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/chi_imtime.cpp:417:48:   required from here
/home/lauro/packages/triqs/tprf_unstable.src/c++/triqs_tprf/lattice/../mpi.hpp:42:15: warning: unused variable 'idx' [-Wunused-variable]
   42 |     for (auto idx : range(0, size)) {
      |               ^~~
make[2]: *** [c++/triqs_tprf/CMakeFiles/triqs_tprf_c.dir/build.make:177: c++/triqs_tprf/CMakeFiles/triqs_tprf_c.dir/lattice/chi_imtime.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:526: c++/triqs_tprf/CMakeFiles/triqs_tprf_c.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

Best regards,

Lauro.

[Thoemi09]

Dear @laurobbraz,

I think you need to use the unstable branch in TRIQS if you want to use the unstable branch in TPRF. Using both unstable branches works for me.

Best,
Thomas

[laurobbraz]

Dear @Thoemi09 ,

Thank you for your lightspeed answer! You were completely right and now the compilation works for me! For future users: The Python environment will change the main installation to the newer one automatically, but I needed to restart my computer in order to apply such changes.

Now, I thought that installing the unstable branch I would solve another problem: I cannot run the save_memory=True flag in the function imtime_bubble_chi0_wk. The following error pops up in both, stable and unstable branches. All other functions work fine so I do not believe I missed installation of the Cpp2py converter.

File ~/packages/unstable/install/lib/python3.10/site-packages/triqs_tprf/lattice_utils.py:270, in imtime_bubble_chi0_wk(***failed resolving arguments***)
    268         del chi0_tr
    269     elif save_memory:
--> [270](https://file+.vscode-resource.vscode-cdn.net/home/lauro/Documentos/Projects/TRIQS/SqrLat/~/packages/unstable/install/lib/python3.10/site-packages/triqs_tprf/lattice_utils.py:270)         chi0_wr = chi0_wr_from_grt_PH(g_tr, nw=nw)
    273 if verbose: mpi.report('--> chi_wk_from_chi_wr (r->k)')
    274 chi0_wk = chi_wk_from_chi_wr(chi0_wr)

TypeError: Error: no suitable C++ overload found in implementation of function lattice.chi0_wr_from_grt_PH

chi0_wr_from_grt_PH(triqs_tprf::g_tr_cvt g_tr, int nw) -> triqs_tprf::chi_wr_t 
 failed with the error : 
  Cpp2py converter: Python to C++ :
  ... Conversion of a Gf from Python to C++ triqs::gfs::gf_view<triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>, triqs::gfs::matrix_valued, nda::C_stride_layout>
  ... Cannot convert the mesh of Gf from Python type :  MeshProduct to the C++ type triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>

chi0_wr_from_grt_PH(triqs_tprf::g_tr_cvt g_tr, triqs_tprf::g_tr_cvt g_bwd_tr, int nw) -> triqs_tprf::chi_wr_t 
 failed with the error : 
  Cpp2py converter: Python to C++ :
  ... Conversion of a Gf from Python to C++ triqs::gfs::gf_view<triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>, triqs::gfs::matrix_valued, nda::C_stride_layout>
  ... Cannot convert the mesh of Gf from Python type :  MeshProduct to the C++ type triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>

Thanks again,

Lauro.

[Thoemi09]

Hi @laurobbraz,

When does this happen? When running the tests? Maybe you could share a minimal example where it fails?

Best,
Thomas

[laurobbraz]

Dear @Thoemi09 ,

It happens when the function imtime_bubble_chi0_wk is called in a usual code. I sure have a minimal example. The code below is fully based on this tutorial. The only difference is that I use DLR frequencies instead of usual Matsubara. DLR is quite essential to make calculations feasible.

Best regards,

Lauro.

import numpy as np
from triqs_tprf.tight_binding import TBLattice

t = 1.0
H = TBLattice(
    units = [(1, 0, 0), (0, 1, 0)],
    hopping = {
        # nearest neighbour hopping -t
        ( 0,+1): -t * np.eye(2),
        ( 0,-1): -t * np.eye(2),
        (+1, 0): -t * np.eye(2),
        (-1, 0): -t * np.eye(2),
        },
    orbital_positions = [(0,0,0)]*2,
    orbital_names = ['up', 'do'],
    )
kmesh = H.get_kmesh(n_k=(32, 32, 1))

e_k = H.fourier(kmesh)

from triqs_tprf.lattice import lattice_dyson_g0_wk
from triqs.gf import MeshDLRImFreq, Idx

beta = 5.; wmax = 30.
wmesh = MeshDLRImFreq(beta=beta, statistic='Fermion', w_max=wmax, eps=1e-12, symmetrize=True)
g0_wk = lattice_dyson_g0_wk(mu=0., e_k=e_k, mesh=wmesh)

from triqs_tprf.lattice_utils import imtime_bubble_chi0_wk
chi00_wk = imtime_bubble_chi0_wk(g0_wk, nw=len(wmesh), save_memory=True)

The full error is listed below:

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Cell In[2], [line 29](vscode-notebook-cell:?execution_count=2&line=29)
     26 g0_wk = lattice_dyson_g0_wk(mu=0., e_k=e_k, mesh=wmesh)
     28 from triqs_tprf.lattice_utils import imtime_bubble_chi0_wk
---> [29](vscode-notebook-cell:?execution_count=2&line=29) chi00_wk = imtime_bubble_chi0_wk(g0_wk, nw=len(wmesh), save_memory=True)

File ~/packages/unstable/install/lib/python3.10/site-packages/triqs_tprf/lattice_utils.py:270, in imtime_bubble_chi0_wk(***failed resolving arguments***)
    268         del chi0_tr
    269     elif save_memory:
--> [270](https://file+.vscode-resource.vscode-cdn.net/home/lauro/Documentos/Projects/~/packages/unstable/install/lib/python3.10/site-packages/triqs_tprf/lattice_utils.py:270)         chi0_wr = chi0_wr_from_grt_PH(g_tr, nw=nw)
    273 if verbose: mpi.report('--> chi_wk_from_chi_wr (r->k)')
    274 chi0_wk = chi_wk_from_chi_wr(chi0_wr)

TypeError: Error: no suitable C++ overload found in implementation of function lattice.chi0_wr_from_grt_PH

chi0_wr_from_grt_PH(triqs_tprf::g_tr_cvt g_tr, int nw) -> triqs_tprf::chi_wr_t 
 failed with the error : 
  Cpp2py converter: Python to C++ :
  ... Conversion of a Gf from Python to C++ triqs::gfs::gf_view<triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>, triqs::gfs::matrix_valued, nda::C_stride_layout>
  ... Cannot convert the mesh of Gf from Python type :  MeshProduct to the C++ type triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>

chi0_wr_from_grt_PH(triqs_tprf::g_tr_cvt g_tr, triqs_tprf::g_tr_cvt g_bwd_tr, int nw) -> triqs_tprf::chi_wr_t 
 failed with the error : 
  Cpp2py converter: Python to C++ :
  ... Conversion of a Gf from Python to C++ triqs::gfs::gf_view<triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>, triqs::gfs::matrix_valued, nda::C_stride_layout>
  ... Cannot convert the mesh of Gf from Python type :  MeshProduct to the C++ type triqs::mesh::prod<triqs::mesh::imtime, triqs::mesh::cyclat>

[Thoemi09]

Hi @laurobbraz,

Thanks for the example. I get the same error. So your compilation seems fine. There simply is no suitable overload of chi_wk_from_chi_wr for DLR meshes.

Unfortunately, I don't know enough about the implementation details of TPRF and if this is intentional or if one could provide an appropriate overload. Maybe @HugoStrand or @Wentzell can help us?

[the-hampel]

Hi @laurobbraz @Thoemi09 ,

Let me add that if you change this line:

chi00_wk = imtime_bubble_chi0_wk(g0_wk, nw=len(wmesh), save_memory=True)

to:

chi00_wk = imtime_bubble_chi0_wk(g0_wk, nw=len(wmesh), save_memory=False)

it works. These functions should work with DLR, but I do not know why the save_memory branch is not working with DLR, or better why there is no protection for this. Certainly what @Thoemi09 writes is correct, that for chi0_wr_from_grt_PH(g_tr, nw=nw) there is no overload, but there is for chi0_wr_from_grt_PH(g_tr, is_symmetrized). This is the relevant python code:

if not save_memory:
            if verbose: mpi.report('--> chi0_tr_from_grt_PH (bubble in tau & r)')
            if is_dlr_mesh:
                chi0_tr = chi0_tr_from_grt_PH(g_tr, is_symmetrized)
            else:
                chi0_tr = chi0_tr_from_grt_PH(g_tr)
            del g_tr
            
            if verbose: mpi.report('--> chi_wr_from_chi_tr')
            chi0_wr = chi_wr_from_chi_tr(chi0_tr, nw=nw)
            del chi0_tr
        elif save_memory:
            chi0_wr = chi0_wr_from_grt_PH(g_tr, nw=nw)

But I would say if save_memory is not an option with DLR (which saves anyway a lot of memory) this should be cought.

Best,
Alex

[Thoemi09]

Thanks @the-hampel, it's the chi0_wr_from_grt_PH which lacks a DLR overload (not chi_wk_from_chi_wr as stated in my previous comment).

I agree, if the save_memory option should not be used with DLR meshes, it would be good to either throw an exception or simply fall back to not saving memory (maybe DLR is already memory efficient enough as Alex mentioned).

[laurobbraz]

Dear @the-hampel and @Thoemi09,

Thanks for investigating the issue. I believe we now agree that the problem is with the chi0_wr_from_grt_PH function, which does not supports DLR meshes. The mentions to this function I could find in the code base were in files python/triqs_tprf/lattice_wrap.cxx, python/triqs_tprf/lattice_desc.py, and python/triqs_tprf/lattice_utils.py. The function imtime_bubble_chi0_wk is located at the last path.

I do agree that DLR meshes are essential for optimizing memory usage, however, my interest is on performing simulations in a dense 3D k-points grid, where the memory problem comes with the k grid instead of the frequency grid. Thus, the save_memory option is very important to avoid usage of several tens of Gb of memory, which is the case for a 4-orbital, 75 DLR frequencies and 64x64x64 k-points grid (my system). Is it too hard implementing such overloads? I should study these things better. :P

Btw, my application may be of @the-hampel interest, for I managed to integrate VASP and TRIQS TPRF k-point meshes so that I'm using DFT data with TPRF.

Best regards,

Lauro.

[the-hampel]

Ah, so how did you manage in the end to export / import the data? Maybe I can use this information. But we can also do this separately. I guess on your original question regarding the save_memory option only @HugoStrand can answer appropriately.

Best,
Alex