Self Energy in DMFT Code
Dear All, I have written a little DMFT code using the ALPS CTQMC impurity solver. The code accepts an arbitrary Hamiltonian (eventually with the goal of doing some form of LDA+DMFT, currently just a model tight-binding Hamiltonian). Firstly, I was wondering what might be done to address the large amount of noise in the tail of the self energy (after the first 20 or so Matsubara frequencies, the noise is a couple of orders of magnitude larger than the "signal"). I suppose it is not surprising that subtracting the inverses of two small numbers would lead to this sort of thing. Secondly, the type of lattice (a Bethe lattice by default in the ALPS dmft code) seems to enter into the picture via a set of three constants in the Fourier transforms. For the forward transform, these seem to be boundary terms in a numerical integration-by-parts method. They also appear in the backward transform, although it is less clear to me what their function might be. I was also wondering, if it does not exceed the scope of a mailing list query, if there are other places in the provided dmft code in which the Bethe lattice is tacitly assumed. Any help would be greatly appreciated. Regards, Hunter -- Hunter Sims Center for Materials for Information Technology University of Alabama Box 870209 Tuscaloosa AL 35487-0209 205-310-9369
Dear Hunter,
Firstly, I was wondering what might be done to address the large amount of noise in the tail of the self energy (after the first 20 or so Matsubara frequencies, the noise is a couple of orders of magnitude larger than the "signal"). I suppose it is not surprising that subtracting the inverses of two small numbers would lead to this sort of thing.
exactly. I assume you use the hybridization expansion? All you can do is supplement the right high frequency tails for the self-energy. You can either do that in your solver, by forcing the measured Sigma (and G) to have the right high frequency behavior, or in the Fourier transform. Eventually we will implement the methods of http://arxiv.org/abs/1104.3215 and project onto the right self-energy coefficients. But for now you're stuck with a noisy self energy, and high frequency behavior is only enforced in the Fourier transform. This is different in the interaction expansion code, where the noise in the self energy goes like 1/omega, and the signal also like 1/omega.
Secondly, the type of lattice (a Bethe lattice by default in the ALPS dmft code) seems to enter into the picture via a set of three constants in the Fourier transforms.
Bethe is default but general lattices are supported. It enters in the Hilbert transform via a density of states or an analytic form; and in the Fourier transform via those three constants.
For the forward transform, these seem to be boundary terms in a numerical integration-by-parts method. They also appear in the backward transform, although it is less clear to me what their function might be. I was also wondering, if it does not exceed the scope of a mailing list query, if there are other places in the provided dmft code in which the Bethe lattice is tacitly assumed.
There is no Bethe lattice assumption. Rather you can specify a density of states file (for a general density of states) and supplement the high frequency constants. Please have a look at Rev. Mod. Phys. 83, 349, section X.I, for the high frequency coefficients, and the FSDOSHilbertTransformer in hilberttransformer.C for the 'general' Hilbert transform with a density of states. Best, Emanuel
Dear Hunter, in your email you asked how to address the noise in the tail of the self-energy in the hybridization expansion CTQMC. We have recently addressed exactly this problem. A preprint is now available at http://arxiv.org/abs/1108.1936. We are implementing this into the code in the SVN, so that it will eventually be available in a future release of ALPS. Best regards, Hartmut Am 27.06.2011 um 19:25 schrieb Hunter Sims:
Dear All,
I have written a little DMFT code using the ALPS CTQMC impurity solver. The code accepts an arbitrary Hamiltonian (eventually with the goal of doing some form of LDA+DMFT, currently just a model tight-binding Hamiltonian).
Firstly, I was wondering what might be done to address the large amount of noise in the tail of the self energy (after the first 20 or so Matsubara frequencies, the noise is a couple of orders of magnitude larger than the "signal"). I suppose it is not surprising that subtracting the inverses of two small numbers would lead to this sort of thing.
Secondly, the type of lattice (a Bethe lattice by default in the ALPS dmft code) seems to enter into the picture via a set of three constants in the Fourier transforms. For the forward transform, these seem to be boundary terms in a numerical integration-by-parts method. They also appear in the backward transform, although it is less clear to me what their function might be. I was also wondering, if it does not exceed the scope of a mailing list query, if there are other places in the provided dmft code in which the Bethe lattice is tacitly assumed.
Any help would be greatly appreciated.
Regards,
Hunter
-- Hunter Sims Center for Materials for Information Technology University of Alabama Box 870209 Tuscaloosa AL 35487-0209
205-310-9369
-- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
Dear ALPS-community, I have written a C++ application based on ALPS. Now I would like to interface it with python via hdf5 archives. Assuming that pyalps.hdf5.archive.write is compatible with alps::make_pvp(...), everything I need is contained in test/pyalps/pyhdf5.py . However I have problems executing the script. Using alpspython or vispython, I get import errors, such as "ImportError: No module named pyhdf5_c" (or pyalea_c). I tried compiling the modules with the build shared option and setting the PYTHONPATH, without success. I'd very much appreciate any hint on how to properly install and use the ALPS python extensions. Best regards, Hartmut -- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
Dear Hartmut, A few questions: - which platform are you trying to use this on? - did you turn on building of the ALPS Python modules? - where did you try setting PYTHONPATH to? Matthias On 11 Sep 2011, at 15:54, Hartmut Hafermann wrote:
Dear ALPS-community,
I have written a C++ application based on ALPS. Now I would like to interface it with python via hdf5 archives. Assuming that pyalps.hdf5.archive.write is compatible with alps::make_pvp(...), everything I need is contained in test/pyalps/pyhdf5.py . However I have problems executing the script. Using alpspython or vispython, I get import errors, such as "ImportError: No module named pyhdf5_c" (or pyalea_c). I tried compiling the modules with the build shared option and setting the PYTHONPATH, without success.
I'd very much appreciate any hint on how to properly install and use the ALPS python extensions.
Best regards, Hartmut
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
Dear Matthias, thank you for the quick reply. I was trying this on a MacBook, however I get similar errors (pytools_c missing) on our local cluster. ALPS_BUILD_PYTHON and all PYTHON_ENABLE_MODULE_... flags are turned on. I tried setting the PYTHONPATH to /path/to/alps_installation/lib/pyalps. This directory does contain libpyhdf5_c.a (and .so as I tried the option BUILD_SHARED). Best, Hartmut Am 11.09.2011 um 15:58 schrieb Matthias Troyer:
Dear Hartmut,
A few questions:
- which platform are you trying to use this on? - did you turn on building of the ALPS Python modules? - where did you try setting PYTHONPATH to?
Matthias
On 11 Sep 2011, at 15:54, Hartmut Hafermann wrote:
Dear ALPS-community,
I have written a C++ application based on ALPS. Now I would like to interface it with python via hdf5 archives. Assuming that pyalps.hdf5.archive.write is compatible with alps::make_pvp(...), everything I need is contained in test/pyalps/pyhdf5.py . However I have problems executing the script. Using alpspython or vispython, I get import errors, such as "ImportError: No module named pyhdf5_c" (or pyalea_c). I tried compiling the modules with the build shared option and setting the PYTHONPATH, without success.
I'd very much appreciate any hint on how to properly install and use the ALPS python extensions.
Best regards, Hartmut
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
-- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
Dear Hartmut, Did you use python or alpspython? alpspython sets all paths. On the Mac the easiest is to install VisTrails and use the vispython command. Otherwise you need to install Python, numpy, scipy, matplotlib, then configure ALPS to use your installed Python. Matthias On 11 Sep 2011, at 16:14, Hartmut Hafermann wrote:
Dear Matthias,
thank you for the quick reply. I was trying this on a MacBook, however I get similar errors (pytools_c missing) on our local cluster. ALPS_BUILD_PYTHON and all PYTHON_ENABLE_MODULE_... flags are turned on. I tried setting the PYTHONPATH to /path/to/alps_installation/lib/pyalps. This directory does contain libpyhdf5_c.a (and .so as I tried the option BUILD_SHARED).
Best, Hartmut
Am 11.09.2011 um 15:58 schrieb Matthias Troyer:
Dear Hartmut,
A few questions:
- which platform are you trying to use this on? - did you turn on building of the ALPS Python modules? - where did you try setting PYTHONPATH to?
Matthias
On 11 Sep 2011, at 15:54, Hartmut Hafermann wrote:
Dear ALPS-community,
I have written a C++ application based on ALPS. Now I would like to interface it with python via hdf5 archives. Assuming that pyalps.hdf5.archive.write is compatible with alps::make_pvp(...), everything I need is contained in test/pyalps/pyhdf5.py . However I have problems executing the script. Using alpspython or vispython, I get import errors, such as "ImportError: No module named pyhdf5_c" (or pyalea_c). I tried compiling the modules with the build shared option and setting the PYTHONPATH, without success.
I'd very much appreciate any hint on how to properly install and use the ALPS python extensions.
Best regards, Hartmut
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
Dear Matthias, I used alpspython. I also have all these packages installed and I made sure ALPS is configured to use this installation of python. When using alpspython, sys.path does contain '/opt/alps_svn/lib', but not 'opt/alps_svn/lib/pyalps'. Can that be a problem? I just discovered a workaround for this problem: everything seems to work when turning on the BUILD_SHARED option for all python modules and additionally providing symbolic links such as pyhdf5_c.so -> libpyhdf5_c.so for all libraries in the subdirectory lib/pyalps of the installation. When installing ALPS, all libraries have the prefix 'lib', but python does not seem to recognize libraries with this prefix. Best, Hartmut Am 11.09.2011 um 16:22 schrieb Matthias Troyer:
Dear Hartmut,
Did you use python or alpspython? alpspython sets all paths.
On the Mac the easiest is to install VisTrails and use the vispython command. Otherwise you need to install Python, numpy, scipy, matplotlib, then configure ALPS to use your installed Python.
Matthias
On 11 Sep 2011, at 16:14, Hartmut Hafermann wrote:
Dear Matthias,
thank you for the quick reply. I was trying this on a MacBook, however I get similar errors (pytools_c missing) on our local cluster. ALPS_BUILD_PYTHON and all PYTHON_ENABLE_MODULE_... flags are turned on. I tried setting the PYTHONPATH to /path/to/alps_installation/lib/pyalps. This directory does contain libpyhdf5_c.a (and .so as I tried the option BUILD_SHARED).
Best, Hartmut
Am 11.09.2011 um 15:58 schrieb Matthias Troyer:
Dear Hartmut,
A few questions:
- which platform are you trying to use this on? - did you turn on building of the ALPS Python modules? - where did you try setting PYTHONPATH to?
Matthias
On 11 Sep 2011, at 15:54, Hartmut Hafermann wrote:
Dear ALPS-community,
I have written a C++ application based on ALPS. Now I would like to interface it with python via hdf5 archives. Assuming that pyalps.hdf5.archive.write is compatible with alps::make_pvp(...), everything I need is contained in test/pyalps/pyhdf5.py . However I have problems executing the script. Using alpspython or vispython, I get import errors, such as "ImportError: No module named pyhdf5_c" (or pyalea_c). I tried compiling the modules with the build shared option and setting the PYTHONPATH, without success.
I'd very much appreciate any hint on how to properly install and use the ALPS python extensions.
Best regards, Hartmut
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
-- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
On 11 Sep 2011, at 18:45, Hartmut Hafermann wrote:
Dear Matthias,
I used alpspython. I also have all these packages installed and I made sure ALPS is configured to use this installation of python. When using alpspython, sys.path does contain '/opt/alps_svn/lib', but not 'opt/alps_svn/lib/pyalps'. Can that be a problem?
No, since you import pyalps.hfd5
I just discovered a workaround for this problem: everything seems to work when turning on the BUILD_SHARED option for all python modules and additionally providing symbolic links such as pyhdf5_c.so -> libpyhdf5_c.so for all libraries in the subdirectory lib/pyalps of the installation. When installing ALPS, all libraries have the prefix 'lib', but python does not seem to recognize libraries with this prefix.
That prefix should not be there, and is not there when I build it. The CMake Lists.txt file states it explicitly: set_target_properties(${name} PROPERTIES PREFIX "") Which version of cmake do you use?
Am 11.09.2011 um 20:30 schrieb Matthias Troyer:
That prefix should not be there, and is not there when I build it. The CMake Lists.txt file states it explicitly:
set_target_properties(${name} PROPERTIES PREFIX "")
That's odd. I have this line as well, but the libraries are nevertheless built with this prefix. I am using cmake 2.8.4. -- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
On 11 Sep 2011, at 20:41, Hartmut Hafermann wrote:
Am 11.09.2011 um 20:30 schrieb Matthias Troyer:
That prefix should not be there, and is not there when I build it. The CMake Lists.txt file states it explicitly:
set_target_properties(${name} PROPERTIES PREFIX "")
That's odd. I have this line as well, but the libraries are nevertheless built with this prefix. I am using cmake 2.8.4.
Is the variable BUILD_SHARED_LIBS set to ON?
ok, this is why the prefix is there. The variable is set to OFF, because I need a static ALPS library for other purposes. Is there a way to make python work with the static libraries, or should one modify CMakeList.txt to create files without the prefix if the BUILD SHARED option is turned on for the individual modules? Am 11.09.2011 um 20:43 schrieb Matthias Troyer:
On 11 Sep 2011, at 20:41, Hartmut Hafermann wrote:
Am 11.09.2011 um 20:30 schrieb Matthias Troyer:
That prefix should not be there, and is not there when I build it. The CMake Lists.txt file states it explicitly:
set_target_properties(${name} PROPERTIES PREFIX "")
That's odd. I have this line as well, but the libraries are nevertheless built with this prefix. I am using cmake 2.8.4.
Is the variable BUILD_SHARED_LIBS set to ON?
-- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
You just need to build it twice in two different directories. One build tree static and one build tree shared. Matthias On 11 Sep 2011, at 20:58, Hartmut Hafermann wrote:
ok, this is why the prefix is there. The variable is set to OFF, because I need a static ALPS library for other purposes. Is there a way to make python work with the static libraries, or should one modify CMakeList.txt to create files without the prefix if the BUILD SHARED option is turned on for the individual modules?
Am 11.09.2011 um 20:43 schrieb Matthias Troyer:
On 11 Sep 2011, at 20:41, Hartmut Hafermann wrote:
Am 11.09.2011 um 20:30 schrieb Matthias Troyer:
That prefix should not be there, and is not there when I build it. The CMake Lists.txt file states it explicitly:
set_target_properties(${name} PROPERTIES PREFIX "")
That's odd. I have this line as well, but the libraries are nevertheless built with this prefix. I am using cmake 2.8.4.
Is the variable BUILD_SHARED_LIBS set to ON?
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
ok, thanks a lot for your help! Hartmut Am 11.09.2011 um 21:02 schrieb Matthias Troyer:
You just need to build it twice in two different directories. One build tree static and one build tree shared.
Matthias
On 11 Sep 2011, at 20:58, Hartmut Hafermann wrote:
ok, this is why the prefix is there. The variable is set to OFF, because I need a static ALPS library for other purposes. Is there a way to make python work with the static libraries, or should one modify CMakeList.txt to create files without the prefix if the BUILD SHARED option is turned on for the individual modules?
Am 11.09.2011 um 20:43 schrieb Matthias Troyer:
On 11 Sep 2011, at 20:41, Hartmut Hafermann wrote:
Am 11.09.2011 um 20:30 schrieb Matthias Troyer:
That prefix should not be there, and is not there when I build it. The CMake Lists.txt file states it explicitly:
set_target_properties(${name} PROPERTIES PREFIX "")
That's odd. I have this line as well, but the libraries are nevertheless built with this prefix. I am using cmake 2.8.4.
Is the variable BUILD_SHARED_LIBS set to ON?
-- Hartmut Hafermann
École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France
Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
-- Hartmut Hafermann École Polytechnique Centre de Physique Theorique (CPHT) 91128 Palaiseau Cedex, France Tel.: +33 1 69 33 42 34 Fax: +33 1 69 33 49 49
participants (4)
-
Emanuel Gull
-
Hartmut Hafermann
-
Hunter Sims
-
Matthias Troyer