The -qdmft option requires a NSLOTS parameter in runsp_triqs and not in run_triqs, which is confusing, The comments state that it will be used in "mpirun" later.

From my point of view NSLOTS is an enviroment variable, and there is no reason to pass it through the command line, we can use it as directly.

Dear Developer,

I got the .outband file for band structure using command "dmftproj -band".

My questions is:

1. Do you have code to read this .outband file and plot out the bandstructure.
2. The format of .outband is a bit strange. Is it correct or not. I attached the beginning lines of this file in this message.

Best regards.
Riping Wang
2016.2.14

51
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 5
 5
 5
 5
 5
 5
 5
 4
 4
 4
 4
 4
 4
 4
 4
 4
 4
 4
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 3
 4
 4
 5
 5
 5

1.44674149873175754E-016 2.77935580272659128E-017 4.95403067737840122E-017
-0.93106276428228130 -0.18220197606495514 -0.31610845816034999
3.73009308956017094E-019 -1.14176482586126798E-019 1.37127500445107240E-019
-0.15501838452288855 0.98184268981433009 -0.10933536186214952
2.31499592875144771E-017 -1.50573968307231503E-016 1.62546805103848652E-017
-0.33028989972810641 5.27954620364154484E-002 0.94240183030457436
1.58212900882303323E-017 -1.08926144281901597E-017 -2.67625988218430848E-017
-0.57735026277570278 0.20863537618172773 0.78939085791447627
8.53762703086465192E-019 1.61001954392615105E-018 -8.23105898703639534E-018
0.57735026274016787 -0.57931484840138370 0.57537896487111517
-1.45139659482505363E-017 2.46730980906218381E-017 -1.71366038683223391E-017
-0.57735026276713175 -0.78795022455915276 -0.21401189308195151
-3.27053109515291015E-017 -4.41997186990391699E-018 4.48635989137662136E-017
-0.57735027747698597 -6.54542688106497100E-002 0.81386878327430179
-5.32358274354455272E-020 8.75934620572453018E-019 -1.20354194363013509E-018
0.57735027747278789 -0.73755817607063900 0.35024933206235886
3.27320131056209219E-017 -4.03285625182469632E-017 1.99748079904787125E-017
-0.57735027747476253 -0.67210390725721414 -0.46361945121627601
-1.35684705853312224E-018 -1.20775657313360368E-017 9.41566164362413887E-018
0.57735026919335108 0.80824724159503136 -0.11577159606994628
-4.25614690703868362E-019 -1.37515330490790433E-017 -5.18968403906962856E-018

Dear developers,

I wonder what's the current status of dft_tools in the view of an upcoming transition to TRIQS libraries version 1.2? Is there a way to use the package together with either cthyb or cthyb_matrix and triqs 1.2-dev?

I found some problem using version 1.0 in LDA+DMFT calculations.
I do 2 calculations with equivalent start parameters except orbital sequence in Hamiltonian and in U matrix (density-density). In first case I use Wien2k orbital sequence in Hamiltonian and in U matrix (3z2-r2, x2-y2, xy, yz, xz). In second case LMTO orbital sequence in Hamiltonian and in U matrix (xy, yz, 3z2-r2, xz, x2-y2). These two results are different. After first iteration degenerate orbitals (yz, xz) become different in case LMTO orbital sequence. In both calculations "use_segment_picture" is true.
Why orbitals sequence affects to result?

I realised a severe design problem in sumk_lda. In put_Sigma the indices of the self energies are completely mixed up. The reason is that gf_struct_solver, gf_struct_corr and map does not fit together any more, since we changed the conventions in gf_struct_solver. The code is not usable at the moment and gives completely wrong results!!!!

...
Instead of doing one-shot run one may also perform fully self-consistent LDA+DMFT calculations, as we will do in this tutorial. We launch these calculations as follows

run_para -qdmft

where -qdmft flag turns on LDA+DMFT calculations with Wien2k. We use here the default convergence criterion in Wien2k (convergence to 0.1 mRy in energy).
.....

The script "run_para" mentioned in the LDA+DMFT tutoiral has been renamed moved to "run_triqs" in the current version.

Thanks!

Hi,

I noticed that the shell degeneracies are not computed correctly when h_field is non-zero. A small test is in

/home/leonid/dat/Iron/Fe-bcc/test_1.2/comp/1.2/check_symm

The script:

from pytriqs.archive import *
from pytriqs.applications.dft.sumk_dft import *
from pytriqs.applications.dft.converters.wien2k_converter import *
from pytriqs.applications.dft.converters import Wien2kConverter
lda_filename = 'Fe-bcc'
Converter = Wien2kConverter(filename=lda_filename, repacking=True)
Converter.convert_dft_input()
SK=SumkDFT(hdf_file=lda_filename+'.h5',use_dft_blocks=True,h_field=0.5)
print 'deg_shells: ',SK.deg_shells[0]

gives as output:

deg_shells: [['up_2', 'up_3', 'up_4', 'down_4', 'down_3', 'down_2'], ['up_0', 'up_1', 'down_1', 'down_0']]

which is obviously incorrect

Hi,
this:

from pytriqs.archive import *
ar1 = HDFArchive('SrVO3_Sigma.h5','r')
del ar1
ar2 = HDFArchive('SrVO3_Sigma.h5','a')
del ar2

causes the error:
File "test.py", line 5, in
ar2 = HDFArchive('SrVO3_Sigma.h5','a')
File "/afs/itp.tugraz.at/user/zingl/Tools/TRIQS/lib/python2.7/dist-packages/pytriqs/archive/hdf_archive.py", line 377, in init
self._init_root( LocalFileName, open_flag)
File "/afs/itp.tugraz.at/user/zingl/Tools/TRIQS/lib/python2.7/dist-packages/pytriqs/archive/hdf_archive_basic_layer_h5py.py", line 38, in _init_root
fich = h5py.File(LocalFileName, open_flag)
File "/usr/lib/python2.7/dist-packages/h5py/_hl/files.py", line 150, in init
fid = make_fid(name, mode, fapl)
File "/usr/lib/python2.7/dist-packages/h5py/_hl/files.py", line 56, in make_fid
fid = h5f.create(name, h5f.ACC_EXCL, fapl=plist)
File "h5f.pyx", line 89, in h5py.h5f.create (h5py/h5f.c:1769)
IOError: unable to create file (File accessability: Unable to open file)

Changing both open flags to 'a' or 'r' works. Maybe the file isn't closed properly. Using ar1._close() before del ar1 also resolves the issue.

For now I'll push a commit where I change all 'r' in dft_tools to 'a' as a work around.

Regards,
Manuel

Dear All,
By comparing rotational matrix T for l=2 in U_matrix.py and
tutorial materials from workshop which I have attended some time ago I observed some discrepancy.

Here is a link to tutorial:
http://www.cond-mat.de/events/correl11/manuscripts/correl11.pdf

Please look at page 206, there is T matrix I have compared (it is called M there).

I am not sure if by mistake xy is swapped with x^2-y^2 in rotational matrix in U_matrix.py, or maybe in that tutorial there is a typo ?

How can I increase the number of Matsubara frequencies when I used the cthyb_matrix solver? In some old version of the interface, there was omega_max. But I cannot seem to find this option any more.

Thanks,
Alaska

This is an issue to discuss small API changes in the dft_tools.

Dear Seth.

I and doing a single DFT-DFMT calculations, following the steps in the web http://ipht.cea.fr/triqs/applications/dft_tools/guide/dftdmft_singleshot.html#a-full-dft-dmft-calculation

Because I am now testing whether the pytriqs command can find the python module, I simply copied the following lines from that web to a python script and run it with pytriqs command:

from pytriqs.applications.dft.sumk_dft import *
from pytriqs.applications.impurity_solvers.cthyb import *
from pytriqs.gf.local import *
from pytriqs.archive import HDFArchive
from pytriqs.operators.util import *

It complains that it can not fined module pytriqs.applications.dft.sumk_dft and pytriqs.applications.impurity_solvers.cthyb . It can find the modules in other three lines.

I then modified the corresponding two lines to be by removing the "pytriqs" within the lines, to be:
from applications.dft.sumk_dft import *
from applications.impurity_solvers.cthyb import *

It becomes able to find these two modules.

My questions now are:

1. Does it mean that the dfttools and cthyb are installed in "applications" directory rather than the "pytriqs/applications" directory?
2. Because the lines I copied is from the tutorial web, there must be some reason to find modules in the "pytriqs/applications" directory. For the consistency of future use, should I copy all the data in the "applications" directory to the "pytriqs/applications" directory by using the command line:
   cp -rf applications/ .. /pytriqs/

Best regards.
Riping Wang
2015/2/10

Dear all, while testing my installation two tests fail (the rest is fine):

Start 3: sumkdft_basic
3/5 Test #3: sumkdft_basic ...................._Failed 1.14 sec
Start 4: srvo3_Gloc
4/5 Test #4: srvo3_Gloc ......................._Failed 0.61 sec
Start 5: U_mat

here is what I found in build/test/sumkdft_basic_output.err

Starting on 1 Nodes at : 2014-12-09 13:59:52.632454
Traceback (most recent call last):
File "", line 30, in
File "/home/dymkowsk/Work/TRIQS/NEWEST_TRIQS/DFT_TOOLS/build/pytriqs/applications/dft/sumk_dft_tools.py", line 537, in partial_charges
Gproj[ish] << mpi.all_reduce(mpi.world, Gproj[ish], lambda x,y : x+y)
File "/home/dymkowsk/Work/TRIQS/NEWEST_TRIQS/DFT_TOOLS/build/pytriqs/utility/mpi_mpi4py.py", line 64, in all_reduce
return world.allreduce(x)
File "Comm.pyx", line 1244, in mpi4py.MPI.Comm.allreduce (src/mpi4py.MPI.c:93062)
File "msgpickle.pxi", line 935, in mpi4py.MPI.PyMPI_allreduce (src/mpi4py.MPI.c:42167)
File "msgpickle.pxi", line 788, in mpi4py.MPI.PyMPI_allgather (src/mpi4py.MPI.c:40439)
File "msgpickle.pxi", line 163, in mpi4py.MPI._p_Pickle.loadv (src/mpi4py.MPI.c:33434)
File "msgpickle.pxi", line 116, in mpi4py.MPI._p_Pickle.load (src/mpi4py.MPI.c:32813)
TypeError: ('call_factory_from_dict() takes exactly 2 arguments (3 given)', <function call_factory_from_dict at 0x2aba5fb25758>, (<class 'pytriqs.gf.local.block_gf.BlockGf'>, 'G', {'down': gf_view, 'block_names': array(['up', 'down'],
dtype='|S4'), 'up': gf_view}))

The error for srvo3_Gloc is basically the same. I have Ubuntu 14.04 LTS. How to fix it?

I'm trying to run Ce-gamma_DOS.py in the doc folder of the git repository.

First, it crashes, because solver does not exist:

from pytriqs.applications.impurity_solvers.hubbard_I.solver import Solver

So I changed it to use the new hubbard solver:

from pytriqs.applications.impurity_solvers.hubbard_I.hubbard_solver import Solver

Next, it crashes, because of the line:

Converter.convert_par_proj_input()

The script continues after removing the underscore between par and proj:

Converter.convert_parproj_input()

The script again crashes, because it tries to call the old solver (old_solver.py):

S = Solver(Beta = Beta, Uint = Uint, JHund = JHund, l = l)

I changed it so that it calls the new hubbard solver (hubbard_solver.py) with

S = Solver(beta = Beta, l = l)

but it crashes with the error:

Traceback (most recent call last):
File "Ce-gamma_DOS.py", line 67, in
S.GF_realomega(ommin=ommin, ommax = ommax, N_om=N_om)
File "/home/username/TRIQS/build/INSTALL_DIR/lib/python2.7/dist-packages/pytriqs/applications/impurity_solvers/hubbard_I/hubbard_solver.py", line 185, in GF_realomega
gf,tail,self.atocc,self.atmag = gf_hi_fullu(e0f=self.ealmat, ur=self.ur, umn=self.umn, ujmn=self.ujmn,
AttributeError: Solver instance has no attribute 'ur'

To workaround this error, the following line was added to the script just before the S.GF_realomega function line:

S.solve(U_int = Uint, J_hund = JHund, verbosity = 1)

The script then crashed again, but after removing the line:

S.Sigma.save('S.Sigma')

and changing

SK.put_Sigma(Sigmaimp = [S.Sigma])

to

SK.put_Sigma([S.Sigma])

the script finally completes without an error.

Can a developer please verify what changes are needed and update the git repository accordingly? Thanks in advance.

Dear Seth,

I have passed the single DFT-DMFT calculations.
I am now going to plot band structure following the instruction on this web:
https://triqs.ipht.cnrs.fr/applications/dft_tools/guide/conversion.html

I following the instruction :
Converter.convert_parproj_input()
This reads and converts the files case.parproj and case.sympar.
If you want to plot band structures, one has to do the following. First, one has to do the Wien2k calculation on the given -path, and run dmftproj on that path:
x lapw1 -band
x lapw2 -band -almd
dmftproj -band

However, when I run “x lapw2 -band –almd”, it complains that:

FERMI - Error
0.092u 0.009s 0:00.10 90.0% 0+0k 0+128io 0pf+0w

When I run “dmftproj -band”, it complains that:
Reading of the file SrVO3.almblm
51
nlab = 9
1 1 R
2 10 LAMBDA
3 21 GAMMA
4 26 DELTA
5 31 X
6 36 Z
7 41 M
8 46 SIGMA
9 51 GAMMA
At line 524 of file /home/riping/software/triqs_dfttools.src/fortran/dmftproj/dmftproj.f (unit = 7, file = 'SrVO3.indmftpr')

Can you give me suggestion?
Thank you very much.

Riping Wang
2016.2.14

Dear Seth,

I am now run a simple python line:
from pytriqs.applications.impurity_solvers.cthyb import *

It is copied from the web: http://ipht.cea.fr/triqs/applications/dft_tools/guide/dftdmft_singleshot.html#a-full-dft-dmft-calculation

I run it with pytriqs, it complains as the following.

[riping@fermi SrVO3]$ pytriqs single_dftdmft_2.py
Traceback (most recent call last):
File "single_dftdmft_2.py", line 5, in
from pytriqs.applications.impurity_solvers.cthyb import *
File "/home/riping/software/triqs/lib/python2.7/site-packages/pytriqs/applications/impurity_solvers/cthyb/init.py", line 26, in
from cthyb_solver import Solver
File "/home/riping/software/triqs/lib/python2.7/site-packages/pytriqs/applications/impurity_solvers/cthyb/cthyb_solver.py", line 1, in
from cthyb import SolverCore
File "/home/riping/software/triqs/lib/python2.7/site-packages/applications/impurity_solvers/cthyb/init.py", line 26, in
from cthyb_solver import Solver
File "/home/riping/software/triqs/lib/python2.7/site-packages/applications/impurity_solvers/cthyb/cthyb_solver.py", line 1, in
from cthyb import SolverCore
ImportError: cannot import name SolverCore

I am checking that there two files including "from cthyb import SolverCore"
applications/impurity_solvers/cthyb/cthyb_solver.py
applications/impurity_solvers/cthyb/init.py

More details of searching is:
applications/impurity_solvers/cthyb/cthyb_solver.py:1:from cthyb import SolverCore
applications/impurity_solvers/cthyb/cthyb_solver.py:6:class Solver(SolverCore):
applications/impurity_solvers/cthyb/cthyb_solver.py:30: SolverCore.init(self, beta, gf_struct, n_iw=n_iw, n_tau=n_tau, n_l=n_l)
applications/impurity_solvers/cthyb/cthyb_solver.py:95: solve_status = SolverCore.solve(self, **params_kw)
applications/impurity_solvers/cthyb/init.py:27:from cthyb import SolverCore, AtomDiag, quantum_number_eigenvalues, trace_rho_op
applications/impurity_solvers/cthyb/init.py:29:all = ['Solver', 'SolverCore', 'AtomDiag', 'quantum_number_eigenvalues', 'trace_rho_op']
applications/impurity_solvers/cthyb/cthyb_desc.py:30: py_type = "SolverCore", # name of the python class

Could you please tell how to make it able to import SolverCore ?

Best regards.
Riping Wang
2016.2.10

Hello,

I am getting the following error for conversion from wien2k, in particular when converting band input. I have not seen this before, and was wondering if anyone else has had it before.

I realise that I am not giving much debug info here -- my main purpose is to find out if this is a common error others have seen (perhaps as a result of recent changes?) or if it points to a mistake in my dmftproj.

Thanks,
Pri

[8x64pcweiss mydft] pytriqs converter.py
Starting on 1 Nodes at : 2015-08-23 15:56:04.513676
Reading input from mydft.ctqmcout...
Reading input from mydft.symqmc...
Reading input from mydft.oubwin...
Reading input from mydft.struct...
Reading input from mydft.outputs...
Reading input from mydft.parproj...
Reading input from mydft.sympar...
Reading input from mydft.outband...
Traceback (most recent call last):
  File "converter.py", line 11, in <module>
    Converter.convert_bands_input()
  File "/home/pseth/SOURCES/TRIQS/install/lib/python2.7/site-packages/pytriqs/applications/dft/converters/wien2k_converter.py", line 428, in convert_bands_input
    for it in things_to_save: ar[self.bands_subgrp][it] = locals()[it]
  File "/home/pseth/SOURCES/TRIQS/install/lib/python2.7/site-packages/pytriqs/archive/hdf_archive.py", line 200, in __setitem__
    self._write_array( key, numpy.array(val,copy=1,order='C') )
  File "/home/pseth/SOURCES/TRIQS/install/lib/python2.7/site-packages/pytriqs/archive/hdf_archive_basic_layer_h5py.py", line 102, in _write_array
    self._group[key] = numpy.array(val,copy=1,order='C')
  File "build/bdist.linux-x86_64/egg/h5py/_hl/group.py", line 244, in __setitem__
  File "build/bdist.linux-x86_64/egg/h5py/_hl/group.py", line 71, in create_dataset
  File "build/bdist.linux-x86_64/egg/h5py/_hl/dataset.py", line 88, in make_new_dset
  File "h5s.pyx", line 100, in h5py.h5s.create_simple (h5py/h5s.c:1317)
ValueError: zero sized dimension for non-unlimited dimension (Invalid arguments to routine: Bad value)

As it follows from this code fragment

 # Transform from spherical basis if needed
if basis == "cubic": T = spherical_to_cubic(l)
if basis == "other" and T == None:
raise ValueError("U_matrix: provide T for other bases.")
if T != None: transform_U_matrix(U_matrix, T)

a return value of transform_U_matrix() is ignored, and thus no basis transformation is actually made.

Hi!
I was going through "Introduction to dmftproj by M.Aichhorn". I have following problem in undestanding the tourial. I will be gratefull if anybody can help me.

1. why hubbard energy $$ in equation 3.22 of the above tutorial was added in LDA+DMFT total energy expression, whereas Hubbard interaction is already taken care through $\rho_{DMFT}$ (derived from $G_{imp}$). What would be the expression the for $$?

Thanks,

Dear Developer,

I got h5 file after a single DFT-DMFT calculations, and I am try to the results, to see using the tools of analysis. I follow the instruction on the web: https://triqs.ipht.cnrs.fr/1.4/applications/dft_tools/guide/analysis.html#analysis

There are many errors.

There first error is occurs when I run:
ar = HDFArchive('case.h5', 'a')
SigmaReFreq = ar['dmft_output']['Sigma_w']

It complains that:
KeyError: 'Key Sigma_w does not exist.'

I think that this is only one of the errors.

Can any one provide a full python script as an example of data analysis?
So that I can pass the first example, from which I can learn more.
It is 1.4 version.
May be many things has been updated.

Thank you very much.
Riping Wang
2016.2.14

Dear dft_tools developers,
Could you explain me, what happened to the real-frequency self energy routines mentioned in doc/analysis.rst?
Where is constr_Sigma_real_axis()?
How can I use python/build_sigma_from_txt.py in my scripts?

This issue serves as a collector and reminder for suggested user guide improvements.
Following issue # 49 we have:

• Emphasize that parameters are material specific (e.g. tail fit, cycles, set up of DMFT cycle). Point out which quantities should be checked by the user before/after the DMFT part and after the first cycle.
• Tail fit and cthyb related settings.
• SrVO3 settings and e.g. the self energy after the first iteration as a benchmark for the user.

Dear developers,

Making the triqs I get this error. I don't have any idea how to solve it. May you guide me?

/usr/bin/ld: /usr/bin/liblapack.a(dgelss.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/liblapack.a: could not read symbols: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [triqs/libtriqs.so] Error 1
make[1]: *** [triqs/CMakeFiles/triqs.dir/all] Error 2
make: *** [all] Error 2

I am trying to follow the Ce tutorial for an LDA+DMFT calculation using

TRIQS_RELEASE "1.0.0"
HUBBARD1_RELEASE "1.0.0"
DFT_TOOLS_RELEASE "1.0.0"

on Debian Sid and Wien2k13 and the "Ce-gamma.py" provided in the tutorial. This are my first tests to see if things are working, all "make tests" completed.

But the Tutorial ends for me with the "Solver" import failing:

Traceback (most recent call last):
File "Ce-gamma_org.py", line 3, in
from pytriqs.applications.impurity_solvers.hubbard_I.solver import Solver
ImportError: No module named solver

=> Reason seems obvious: the names of the modules have changed

=> I tried switching to the "old Solver":

from pytriqs.applications.impurity_solvers.hubbard_I.old_solver import SolverOld

which uses the init variables given in the Ce-gamma.py but this then fails with:

File "Ce-gamma.py", line 67, in
SK.put_Sigma(Sigmaimp = [ S.Sigma ])
TypeError: put_Sigma() got an unexpected keyword argument 'Sigmaimp'

I could not get the init line in Ce-gamma.py changed in a way which would initialize the "hubbard_solver.py" solver successfully.

Please advice and thanks in advance!

FindBuildF2pyModule.cmake module contains the following fragment, which generates f2py execution script:

 FILE(WRITE ${filename} "import sys\n")
 FILE(APPEND ${filename} "from numpy.f2py import main\n")
 FILE(APPEND ${filename} "sys.argv = [''] +'-c --f77exec=${CMAKE_Fortran_COMPILER} --f90exec=${CMAKE_Fortran_COMPILER} -m ${modulename} ${modulename}.pyf ${filelist} -llapack'.split()\n")
 FILE(APPEND ${filename} "main()\n")

Putting just -llapack on the command line does not respect ${TRIQS_LIBRARY_LAPACK} and may not work for some distributions/implementations of LAPACK.

This issue was in triqs with a fix proposed by Igor:

TRIQS/triqs#16

Assigned to me.

I compared the density-density vertex for the same U=F0=4.3 and J=1.0 with old 0.8 version. It seems that the default order of harmonics has been changed compared to the Wien2k convention (which is quite reasonable: first one lists the eg states, then the t2g ones). What should one do now to fix the order in U-matrix in agreement with the input from Wien2k? Do we have some function for it or one should do it oneself?

I construct the dens-dens U matrix in the new version as follows:

U_sph = U_matrix(l=2, U_int=U_int, J_hund=J_hund)
U_cubic = transform_U_matrix(U_sph,spherical_to_cubic(l=2))
U,Up = reduce_4index_to_2index(U_cubic)

This is related to some changes in the main libs of triqs, but I post it here. For some reason, the fortran compiler is invoked with c++ flags on mac osx:

faepnb44:~/work/Codes/build/W2T $ make
Scanning dependencies of target dmftproj
[ 5%] Building Fortran object fortran/dmftproj/CMakeFiles/dmftproj.dir/modules.f.o
gfortran: error: unrecognized command line option '-stdlib=libc++'
make[3]: *** [fortran/dmftproj/CMakeFiles/dmftproj.dir/modules.f.o] Error 1
make[2]: *** [fortran/dmftproj/CMakeFiles/dmftproj.dir/modules.f.o.provides] Error 2
make[1]: *** [fortran/dmftproj/CMakeFiles/dmftproj.dir/all] Error 2
make: *** [all] Error 2

This is new, this problem was not there until a few weeks ago. I use 1.2dev branch and c++14 support, since I want to build the doc also.

I test self-consistent calculation for 1.2-dev using one band model.
I do 1 dmft loop and try to start from it. Second loop is not calculated. The problem is related to gf_struct_solver and other.

For illustrate this problem, I print gf_struct_solver, sumk_to_solver, solver_to_sumk, solver_to_sumk_block and other before saving h5 file. It is normal:
[{'up_0': [0], 'down_0': [0]}]
[{('down', 0): ('down_0', 0), ('up', 0): ('up_0', 0)}]
[{('up_0', 0): ('up', 0), ('down_0', 0): ('down', 0)}]
[{'up_0': 'up', 'down_0': 'down'}]
[{'down': array([[ 0.]]), 'up': array([[ 0.]])}]

At second loop after read the h5 archive I print the same:
[{u'up_0': [0], u'down_0': [0]}]
[{u"('up', 0)": ('up_0', 0), u"('down', 0)": ('down_0', 0)}]
[{u"('down_0', 0)": ('down', 0), u"('up_0', 0)": ('up', 0)}]
[{u'up_0': 'up', u'down_0': 'down'}]
[{u'down': array([[ 0.]]), u'up': array([[ 0.]])}]
Symbol u is appeared. I didn't find the reason for it.
My hdf5 version is 1.8.11.
I viewed h5 file by vitables and didn't find the symbol u.

Error when repack is called in wien2k_converter (line 63).

  62         if (os.path.exists(self.hdf_file) and repacking):

---> 63 ConverterTools.__repack(self)

AttributeError: class ConverterTools has no attribute
'_Wien2kConverter__repack'

Hi!
I got DFT+DMFT converged energy value for Ce diffent from what was mentioned in we tutorial.
I stated DFT calculation with the structure file (no of symmetry=0)mentioned in the web tutorial. But at the end it calculated with symmetry. After LDA+DMFT energy comming to be

:ENE : ********** TOTAL ENERGY IN Ry = -17730.87948820
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87663309
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87523305
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87243746
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87727413
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87834269
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87895017
:ENE : ********** TOTAL ENERGY IN Ry = -17730.87741727
:ENE : ********** TOTAL ENERGY IN Ry = -17730.88594246

:ENE : ********** TOTAL ENERGY IN Ry = -17730.88391215

instead of ~17717.77

Any help will be appreciated.
Thanks

Dear Developers,

I am now able to run the single DFT-DMFT calculations using the script dft_dmft_cthyb.py provide on the web: https://triqs.ipht.cnrs.fr/applications/dft_tools/guide/dftdmft_singleshot.html#a-full-dft-dmft-calculation

I am now continue to run the self-consistent DFT-DMFT calculations using the command:
run_lapw -qdmft 1 -NI

However, at the very beginning, it complains as follows.

Creation of the projectors...
Evaluation of the density matrices...

TOTAL CHARGE = 40.00000

Computation of the Occupancies and Density Matrices in the desired energy window [ -0.11000; 0.14000]

Creation of the projectors...
Orthonormalization of the projectors...

Evaluation of the density matrices...

Density Matrices for the Correlated States :

Sort = 2 Atom = 2 and Orbital l = 2

0.000307    0.000000    0.000000   -0.000000    0.000000   -0.000000   -0.000000   -0.000000    0.000000    0.000000
0.000000    0.000000    0.000307   -0.000000   -0.000000    0.000000    0.000000    0.000000   -0.000000    0.000000
0.000000    0.000000   -0.000000   -0.000000    0.333303   -0.000000    0.000000   -0.000000   -0.000000    0.000000

-0.000000 0.000000 0.000000 -0.000000 0.000000 0.000000 0.333303 -0.000000 -0.000000 -0.000000
0.000000 -0.000000 -0.000000 -0.000000 -0.000000 -0.000000 -0.000000 0.000000 0.333303 -0.000000

The charge of the orbital is : 1.00052
Writing the file case.ctqmcout...
Writing the file case.symqmc...
Writing the file case.parproj...
Writing the file case.sympar...
Writing the file case.outbwin...

END OF THE PRGM
python_with_DMFT: Command not found.
forrtl: severe (24): end-of-file during read, unit 32, file /home/riping/TRIQS_data/SrVO3/SrVO3.qdmft
Image PC Routine Line Source
lapw2 00000000004CE4D9 Unknown Unknown Unknown
lapw2 00000000004107C3 qdmft_mp_readdata 56 qdmft_tmp_.F
lapw2 000000000047D125 MAIN__ 233 lapw2_tmp_.F
lapw2 0000000000404406 Unknown Unknown Unknown
libc.so.6 00000034AF41ECDD Unknown Unknown Unknown
lapw2 00000000004042F9 Unknown Unknown Unknown

stop error

Best regards.
Riping Wang

The example provided in dft_tools/src/lda_dmft_cthyb.py contains the following line
S.G_iw << SK.extract_G_loc()

This line looks rather dangerous for a simple reason: operator "<<" copies the GF block by block but there is no guarantee that the blocks are ordered consistently. Indeed, the GF in the solver is constructed from a dictionary SK.gf_struct_solver and dictionaries are not ordered data structures in Python, which implies that the blocks of S.GF might be ordered in a completely arbitrary fashion, different from that in SumK.
I beleive this copy operation must be performed with the help of maps 'solver_to_sumk' or 'sumk_to_solver'.

Dear All,

I need an article in the field of Electronic structure, magnetic properties and electric field gradients in bulks and nano thin films of rare earth compounds (RAl2,,(R=Nd,Sm,Eu,Gd,Tb)
with the TRIQS code in order to compare it to my data and feel confident about my data analysis and results applying this code.
I was wondering if you'd mind introducing a related article to me ( in case of having of course ). I sincerely appreciate all your previous comments and guides.

Best regards

I had tried to following the tutorial "http://ipht.cea.fr/triqs/applications/dft_tools/advanced.html" with LDA+DMFT on SrVO3. However I got the following error. Could you help to solve this? Thank you.

..........-------------------------------------------------
0.064294 < chemical_potential < 0.500000
18.999937 < Total Density < 20.005036
chemical_potential found in 12 iterations :
Total Density = 18.999937;chemical_potential = 0.064294
Total charge of Gloc : 1.445843
DC for shell 0 and block up = 2.553777
DC for shell 0 and block down = 2.553777
DC energy for shell 0 = 0.87023646223
Traceback (most recent call last):
File "SrVO3.py", line 78, in
ar['DeltaF'] = S.G0.delta()
File "binary/triqs/lib/python2.7/site-packages/pytriqs/gf/local/block_gf.py", line 359, in delta
self.__check_attr("delta")
File "/binary/triqs/lib/python2.7/site-packages/pytriqs/gf/local/block_gf.py", line 350, in __check_attr
raise RuntimeError, "The blocks of this Green Function do not possess the %s method"%ATTR
RuntimeError: The blocks of this Green Function do not possess the delta method

Dear Developers,

I am going to using a python script. The first line is:
from pytriqs.applications.dft.sumk_dft import *
but it complains that
No module named applications.dft.sumk_dft

In my /home/riping/software/triqs/lib/python2.7/site-packages/pytriqs/applications/dft directory,
there is sumk_dft.

when I "echo $PYTHONPATH", there is
/home/riping/software/triqs/lib/python2.7/site-packages

Why it can not find the python module?

Thank you very much.

Joser
2015.2.10

Hi,

I noticed that reading of the struct files in convert_misc_input fails in the case of hcp structures. The reason is that in this case there is no space between the unit cell angles 90 and 120 in case.struct:

Title
H LATTICE,NONEQUIV.ATOMS: 1
MODE OF CALC=RELA unit=ang
4.095012 4.095012 6.552019 90.000000 90.000000120.000000
....

and str.split() apparently does not work correctly in this case.

Dear Developer,

I am now going to make transport calculations with version 1.4 of triqs/dfttools.
I follow the instruction on this web: https://triqs.ipht.cnrs.fr/applications/dft_tools/guide/transport.html

I first made .pmat file by optic calculations, and then run the command line on that web.
I copied all the commands onto a python script dft_dmft_transport.py, and run it.

It complains the following.

[riping@fermi SrVO3]$ pytriqs dft_dmft_transport.py
Starting on 1 Nodes at : 2016-02-14 22:05:51.946968
Repacking the file SrVO3.h5
Reading input from SrVO3.pmat...
Traceback (most recent call last):
File "dft_dmft_transport.py", line 9, in
Converter.convert_transport_input()
File "/home/riping/software/triqs/lib/python2.7/site-packages/pytriqs/applications/dft/converters/wien2k_converter.py", line 590, in convert_transport_input
R.next()
StopIteration

Can any one give a example python file for transport calculations?

Best regards.
Riping Wang
2016.2.14

Dear Seth,

I installed the software " triqs, triqs/dfttools, trqis/cthyb, triqs/hubbardI" in the following way. After describing my installation procedure, I have three questions.

I make build directories separately for each of the follow software: triqs, triqs/dfttools, trqis/cthyb, triqs/hubbardI. And then I installed all these softwares in the one directory called triqs whose location is in parallel with the build directories.

In each build directory, I run the following command before run "make; make install"
The cmake command for triqs is:
cmake -DCMAKE_INSTALL_PREFIX=/home/joser/software/triqs ../triqs.src

The cmake command for triqs/cthyb is:
cmake -DTRIQS_PATH=/home/joser/software/triqs ../triqs_cthyb.src

The cmake command for triqs/dfttools is:
cmake -DTRIQS_PATH=/home/joser/software/triqs ../triqs_dfttools.src

The cmake command for triqs/hubbardI is:
cmake -DTRIQS_PATH=/home/joser/software/triqs ../triqs_hubbardI.src

There two questions:

1. Can "triqs" directory used for all these for software with their build directories independent?
2. Is the DTRIQS_PATH correctly set?
3. Should the cthyb be installed before dfttools for after it? Does the order of intallating different codes matter?

Best regards.
Riping Wang
2016.2.10

I calculate real material LiFeAs (only 2 orbitals are degenerate, there are 4 different G0_iw)
Sequence of orbitals in the Hamiltonian of hopping is written in this way:
{'up_0': [0], 'up_1': [0], 'up_2': [0], 'up_3': [0], 'up_4': [0], 'down_0': [0], 'down_1 ': [0],' down_2 ': [0],' down_3 ': [0],' down_4 ': [0]}

A Green's function G0_iw is calculated in orbital sequence in which goes gf_struct, ie .:
{'up_2': [0], 'up_3': [0], 'up_0': [0], 'up_1': [0], 'up_4': [0], 'down_4': [0], 'down_3 ': [0],' down_2 ': [0],' down_1 ': [0],' down_0 ': [0]}

and it turns out that the orbitals in the Green's functions are reversed:
name of the block 'up_2' contains 'up_0',
'up_3' - 'up_1'
'up_0' - 'up_2'
etc.

Accordingly incorrect results of LDA+DMFT calculation.

Nikita

Hi!
I was using the same exactly same python script for DMFT as is given in source. I am getting following error.

https://gist.github.com/Soumeniisc/2bf374de807a497a066e

Chemical Potential = 61.864286
Total Density = -0.727171
11.364286 < Chemical Potential < 61.864286
-1.141574 < Total Density < -0.727171
FAILURE to adjust Chemical Potential to the value 1.000000 after 101 iterations.
Traceback (most recent call last):
File "SRVO-DMFT.py", line 77, in
S.G_iw << SK.extract_G_loc()[0] # calc the local Green function
File "/home/soumen/INSTALLPACKAGES/23_10_15/lib/python2.7/dist-packages/pytriqs/applications/dft/sumk_dft.py", line 370, in extract_G_loc
G_latt_iw = self.lattice_gf(ik=ik, mu=mu, iw_or_w="iw", with_Sigma=with_Sigma, with_dc=with_dc, beta=beta)
File "/home/soumen/INSTALLPACKAGES/23_10_15/lib/python2.7/dist-packages/pytriqs/applications/dft/sumk_dft.py", line 304, in lattice_gf
M[ibl] = self.hopping[ik,ind,0:n_orb,0:n_orb] - (idmat[ibl]_mu) - (idmat[ibl] * self.h_field * (1-2_ibl))
TypeError: unsupported operand type(s) for *: 'complex' and 'NoneType'

Dear Developer,

I am practicing the SrVO3 example provided by the web:
http://ipht.cea.fr/triqs/applications/dft_tools/guide/dftdmft_singleshot.html

I have generated the hdf5 file,
and now I am running the dft_dmft_cthyb.py provided by that web.
I complains as the following.

Could you please have a check?

Chemical Potential = 51.516730
Total Density = -0.869745
Chemical Potential = 52.016730
Total Density = -0.882625
Chemical Potential = 52.516730
Total Density = -0.895715
Chemical Potential = 53.016730
Total Density = -0.909017
Chemical Potential = 53.516730
Total Density = -0.922537
Chemical Potential = 54.016730
Total Density = -0.936278
3.516730 < Chemical Potential < 54.016730
-0.264036 < Total Density < -0.936278
FAILURE to adjust Chemical Potential to the value 1.000000 after 101 iterations.
Traceback (most recent call last):
File "dft_dmft_cthyb_Kanamori.py", line 90, in
S.G_iw << SK.extract_G_loc()[0] # calc the local Green function
File "/home/riping/software/triqs/lib/python2.7/site-packages/pytriqs/applications/dft/sumk_dft.py", line 593, in extract_G_loc
G_latt_iw = self.lattice_gf(ik=ik, mu=mu, iw_or_w="iw", with_Sigma=with_Sigma, with_dc=with_dc, beta=beta)
File "/home/riping/software/triqs/lib/python2.7/site-packages/pytriqs/applications/dft/sumk_dft.py", line 503, in lattice_gf
M[ibl] = self.hopping[ik,ind,0:n_orb,0:n_orb] - (idmat[ibl]_mu) - (idmat[ibl] * self.h_field * (1-2_ibl))
TypeError: unsupported operand type(s) for *: 'complex' and 'NoneType'

The formula for the cell volume

vol_c = a * b * c * numpy.sqrt(1 + 2 * c_al * c_be * c_ga - c_al ** 2 - c_be * 82 - c_ga ** 2)

contains an obvious typo (should be 'c_be ** 2') which I have taken liberty to fix.

Hi,
I am using triqs1.0. I got the following problem during LDA+DMFT calcualtion for SrVO3
File "SRVO-DMFT.py", line 83, in
ar['DeltaF'] = S.G0.delta()
File "/home/soumen/INSTALLPACKAGES/triqs/lib/python2.7/dist-packages/pytriqs/gf/local/block_gf.py", line 359, in delta
self.__check_attr("delta")
File "/home/soumen/INSTALLPACKAGES/triqs/lib/python2.7/dist-packages/pytriqs/gf/local/block_gf.py", line 350, in __check_attr
raise RuntimeError, "The blocks of this Green Function do not possess the %s method"%ATTR
RuntimeError: The blocks of this Green Function do not possess the delta method

link for SRVO-DMFT.py is https://gist.github.com/Soumeniisc/0eeb9a4a103b0947d9e0
Is the current version of DFT_tool_1.2.0 beta version??
Thanks
Soumen

Dear all,

I just managed to install successfully the base set of TRIQS modules
and run the easiest examples. Now I want to move on to installing the
dft-tools but the cmake command renders this error message:

CMake Error at test/CMakeLists.txt:5 (triqs_add_test_hdf):
Unknown CMake command "triqs_add_test_hdf".

I'm using ubuntu 14.04 with gcc/gfortran 4.8.2 and TRIQS 1.2

cmake command line and output: https://gist.github.com/yesenia97/1f8c12bd5afd94c94eb0#
CMakeCache.txt: https://gist.github.com/yesenia97/1ff37d340f30d1167486#

Thanks for any hint on this issue,
Yesenia

I am getting the following error message in SK.calc_density_correction in a LDA+Hub1 calculation close to the one given as example in the doc, but with spin-orbit 👍

Traceback (most recent call last):
File "EuVO4.py", line 161, in
dN,d = SK.calc_density_correction(filename = lda_filename+'.qdmft')
File "/home/delange/sources/TRIQS_1.2/install/lib/python2.7/site-packages/pytriqs/applications/dft/sumk_dft.py", line 842, in calc_density_correction
fout.write("%.14f %.14f "%(deltaN[bn][ik][inu,imu].real,deltaN[bn][ik][inu,imu].imag))
NameError: global name 'bn' is not defined

the same without spin-orbit (and without spin-polarization) seems to work fine.

Hello everyone,

Today one of our students encountered an issue, which was reported before as TRIQS/triqs_0.x#148.
dmftproj does not want to read in symmetry information from a .dmftsym file.

 ocrijano@asterix01:~/TRIQS/CrCl3$ dmftproj
Welcome in DMFTPROJ: PROJECTION TO LOCALIZED BASIS


This prgm will build the Wannier projectors to the
localized orbitals of an atom onto which DMFT will be applied.


You are performing a computation
without Spin-Orbit.
using Paramagnetic Wien2k input files.
=======================================
Sorts of atoms =   2
Equivalent sites per each sort: 1 3


-------------------------------------
For the sort  1 :
The orbital l= 0 is included.
The orbital l= 1 is included.
The orbital l= 2 is included.

-------------------------------------
For the sort  2 :
The orbital l= 0 is included.
The orbital l= 1 is included.


The Eigenstates are projected in an energy window from   -0.40000 Ry  to     0.40000 Ry around the Fermi level.


=======================================
Basis representation for each sort.


-------------------------------------
For the sort  1 :
The atomic sort 1 is studied in the cubic basis representation.

The basis for s-orbital is still    1.000000
The basis for orbital l= 1 has the following properties :
 - number of ireps :  1
 - degree of each ireps :  3
The transformation matrix is block diagonal in the spin-space. The up/up and down/down blocks are the same and defined as :
    0.707107    0.000000    0.000000    0.707107    0.000000    0.000000
    0.000000    0.000000    0.000000    0.000000    1.000000    0.000000
   -0.707107    0.000000    0.000000    0.707107    0.000000    0.000000

The basis for orbital l= 2 has the following properties :
 - number of ireps :  2
 - degree of each ireps :  2  3
The transformation matrix is block diagonal in the spin-space. The up/up and down/down blocks are the same and defined as :
    0.000000    0.000000    0.707107    0.000000   -0.707107    0.000000    0.000000    0.000000    0.000000    0.000000
    0.000000    0.000000    0.000000    0.000000    0.000000    0.000000    0.707107    0.000000    0.707107    0.000000
    1.000000    0.000000    0.000000    0.000000    0.000000    0.000000    0.000000    0.000000    0.000000    0.000000
    0.000000    0.000000    0.000000    0.000000    0.000000    0.000000   -0.707107    0.000000    0.707107    0.000000
    0.000000    0.000000    0.707107    0.000000    0.707107    0.000000    0.000000    0.000000    0.000000    0.000000



-------------------------------------
For the sort  2 :
The atomic sort 2 is studied in the cubic basis representation.

The basis for s-orbital is still    1.000000
The basis for orbital l= 1 has the following properties :
 - number of ireps :  1
 - degree of each ireps :  3
The transformation matrix is block diagonal in the spin-space. The up/up and down/down blocks are the same and defined as :
    0.707107    0.000000    0.000000    0.707107    0.000000    0.000000
    0.000000    0.000000    0.000000    0.000000    1.000000    0.000000
   -0.707107    0.000000    0.000000    0.707107    0.000000    0.000000




=======================================
Precisions about correlated orbitals.

-------------------------------------
For the sort  1 :
The irep  2 of orbital l=  2 is considered as correlated.
-------------------------------------
For the sort  2 :
No orbital is included as correlated.

=======================================
Symmetry operations of the system


Number of Symmetries =    1

Properties of the symmetry operations :
   alpha, beta, gamma are their Euler angles.
   iprop is the value of their determinant.

 SYM.OP.  alpha      beta     gamma     iprop
At line 95 of file /afs/physnet.uni-hamburg.de/users/th1_li/ikrivenk/TRIQS_build/dft_tools.git/fortran/dmftproj/setsym.f (unit = 8, file = 'CrCl3.dmftsym')
Fortran runtime error: Bad value during floating point read

CrCl3.dmftsym:

           1
           1           2           3           4           5           6
           7           8

Sym. op. :  1
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000 -3.308722450212111E-024   1.00000000000000     
 Global->local coordinates rotation matrices
           1
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           2
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           3
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           4
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           5
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           6
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           7
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 
           8
   1.00000000000000       0.000000000000000E+000  0.000000000000000E+000
  0.000000000000000E+000   1.00000000000000       0.000000000000000E+000
  0.000000000000000E+000  0.000000000000000E+000   1.00000000000000     
   0.0   0.0   0.0  1       - euler angles: a,b,c; iprop 

Could it be an installation/WIEN2k integration problem?
We are using WIEN2k 14.

(Resubmitting the issue at the correct place.)

Hi Leonid and Markus,

I think using U+2J as the intraorbital interaction is confusing, and it is also not a standard convention.

Could you please change the interaction parameters to U, U-2J, U-3J?

Thanks,
Alaska

Hello,

I get two warnings from U_matrix.py when I try to use it:

/home/igor/Physics/TRIQS/installed/lib64/python2.7/site-packages/pytriqs/applications/dft/U_matrix.py:22: FutureWarning: comparison to `None` will result in an elementwise object comparison in the future.
  if radial_integrals != None and (U_int != None and J_hund != None):
/home/igor/Physics/TRIQS/installed/lib64/python2.7/site-packages/pytriqs/applications/dft/U_matrix.py:43: FutureWarning: comparison to `None` will result in an elementwise object comparison in the future.
  if T != None: U_matrix = transform_U_matrix(U_matrix, T)

Indeed, it is in general recommended to write is None instead of == None. The latter comparison can be overloaded by a user-defined class, and acquire an unexpected meaning.

Hi,
I have installed triqs, dft_tools, cthyb and hubbardI. When i test multi-band solver by 'from pytriqs.applications.dft.solver_multiband import *', there is ImportError: No module named solver_multiband. How to get the solver_multiband? -.-