Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mctdhb

Pages: [1]
Hi Asaad Sakhel!

The accuracy of MCTDH-B is dependent on the physical situation that is considered.
The size of the configuration space is N+M-1 choose N ; so for N=2000 particles you can work at most with M=3 orbitals.

If these 2003001 configurations would be a sufficiently large configuration space for the system you have in mind, then yes.

For instance, I think you could get a very accurate representation for harmonically, double-well, and triple-well trapped particles.
There exist many examples where MCTDH-B has been applied for N>200, for instance:


Main Program Usage / Re: Default choice of the starting orbitals
« on: February 28, 2020, 02:02:48 PM »
Hi chrisapo!

Questions are always appreciated! Sorry for the delayed reply.

Regarding: the random choice of initial conditions
The algorithm to compute ground states via imaginary time propagation of the MCTDH-X working equations is generally very insensitive to the choice of initial conditions.

However, there are some pitfalls. For instance, when initial state (determined by coefficients and orbitals) has exactly zero overlap with the ground state that is sought.

The motivation for the random choice of initial conditions is to guarantee that the overlap with any possible state is finite. This random choice typically makes the initial steps of the integration a bit slower.

Regarding orthonormality: the orbitals (working as well as natural) should always be strictly orthonormal. For hand-given-orbitals, this is ensured by a Gram-Schmidt orthonormalization.

During real-time evolution, orthonormality is a property that follows from the projection operator in the equations of motion and the unitarity of the Hamiltonian.

During imaginary-time evolution, the orthonormality is guaranteed by a Gram-Schmidt orthonormalization at every integration step.

Hope that helps!

Hi Chrisapo,

generally, the parallel performance is computation- and environment dependent. You will just have to test out what works best.

Judging from your previously posted examples, I checked the following:
For a 2D example with 128x128 grid points, N=100 particles and M=4 orbitals, I get reasonable performance using just OpenMP threads with a single MPI process on my desktop computer. In that case, using more than 4 threads didn't add much performance.

Hope that helps!

Hi Chrisapo,

thanks for pointing out that there's an issue.

Please stick with
Code: [Select]
Interaction_Type=4, these results are correct and by
far the most efficient.

Interaction_Type=2 is intended for 1D computations only. Doing checks with the other settings (Interaction_Type=1 and 3), I found and rectified a bug with Interaction_Type=1 (the width was set to pi, irrespective of the user input).

The fix that should give the same result for Interaction_Type=1,3, and 4 is now in the repository, please get it via
Code: [Select]
hg pull.

Hope this helps,

Main Program Usage / Re: Is it possible to implement PBC?
« on: January 23, 2020, 10:20:31 AM »
Hi chrisapo,

the boundary conditions in our code depend on the discrete variable representation  (Inputs
Code: [Select]
DVR_X,DVR_Y,DVR_Z) that you select in the
Code: [Select]
MCTDHX.inp .

The most efficient choice to have periodic boundary conditions is to set these inputs to "4", i.e.,
Code: [Select]

This is actually the default setting.

Hope that helps,

Hi there,

It's of importance for what specific problem you ask this question.

For contact interactions, we usually directly evaluate the W_sl integrals analytically and work with this.
There's thus no difference with the analytical delta distribution. In more than one spatial dimension, however, issues do arise with contact potentials.

Then, in >1D, one needs either renormalization or just to consider a short-ranged interaction with the same scattering properties (see for instance: Phys. Rev. A 87, 033631 (2013) ).


Analysis Program Usage / Re: Memory errors when Phase, Gradient = .T.
« on: December 27, 2017, 08:58:53 PM »
Hi there,

Sorry for the late reply. Can you please provide the analysis.inp file which you have used and tell us what kind of computation you are trying to analyze?

The error looks like a problem with the FFTs. If I remember correctly, we only implemented the Phase analysis for two-dimensional problems. Did you try to run it on a one-dimensional computation?


P.S.: If you need a faster answer, please send email to in the future.

Main Program Usage / Re: Estimation of Memory in Relaxation.
« on: December 04, 2017, 09:18:03 AM »
Hi there!

The memory needed for a computation with MCTDH-B for the coefficients is (N+M-1 over N)*(16 bytes [double precision complex])*(Dimension of Krylov subspace used for the integrator). The size of the Krylov subspace is adaptive, i.e., it depends on the particular problem studied; but it can be controlled using the "Minimal_Krylov" and "Maximal_Krylov" inputs in the MCTDHX.inp file.

In addition, M*N_g*[O(10)]*(16 bytes [double precision complex]) of memory is needed for the solution of the orbital equation.


General Questions and Discussion / MCTDH-X Synopsis
« on: May 09, 2017, 11:49:36 AM »
What MCTDH-X is and what it can do

MCTDH-X is a unique method that -- roughly speaking -- allows one to describe the way little particles behave according to quantum physics. The MCTDH-X software is an implementation of that theory that allows to compute and visualize these quantum dynamics. Specifically, it is a way compute some fundamental properties of ensembles of indistinguishable particles, that is gases of atoms, that are constrained in a box or container at extremely low temperatures or electrons in atoms or molecules.

These properties can be collective, i.e., followed by all (or almost all) particles of the system or not. In the former case one is talking about a Bose-Einstein condensate if the considered particles are indistinguishable bosons or uncorrelated fermions if the considered particles are indistinguishable fermions; in the latter case, the we speak about something more complicated, a so-called fragmented many-boson or a correlated many-fermion state. Indistinguishable bosons at low temperature or indistinguishable electrons in atoms or molecules behave quantum-mechanically: they are wave-like in nature and, hence, totally different than ordinary matter. In a Bose-Einstein condensate (BEC), for instance, all the indistinguishable particles of the gas behave as if they were single effective particle.

Quantum fluctuations and correlations are negligible -- such a behavior is referred to as coherent for bosons and single-configurational for fermions. However, there are many cases in which this not true, even at ultracold temperatures. Phenomena like fragmentation and  correlations become very important. In such cases MCTDH-X is applicable, but conventional mean-field descriptions fail. MCTDH-X is designed to solve many-body dynamics of small and intermediate systems of ultracold particles (bosons or fermions) and shed light at phenomena where correlations emerge and mean-field approaches break down.     

The fundamental physical equation that governs the evolution of atomic and quantum systems is the Schrödinger equation. MCTDH-X is a method that can, in principle, describe these quantum dynamics exactly, i.e., to any desired given numerical accuracy, for a wide range of scenarios. To see more details about the MCTDH-X method and software, just click here:

Main Program Usage / Re: RungeKutta Error
« on: December 09, 2014, 09:51:48 AM »
Hello Andr?,

The problem you quote is with the integrator Runge Kutta of order 8 that you chose for the solution of the orbitals equations of motion. The energy and occupations seem to be undefined (NaN). In the future, please also post the input file "MCTDHB.inp" to make the analysis easier.

I think you specified the wrong file to read from, right? Anyways, I think we resolved this problem by renaming your *orbs.dat and *coefs.dat files?

I will take your post as a request to revise the input handling, especially, I would like to deprecate the restart from ASCII files with GUESS='DATA' in the near future.

Could you specify, what fixed the issue?


Main Program Usage / Re: Full CI
« on: June 20, 2014, 04:36:12 PM »
Dear Shachar,

FCI is basically operative, yes. If the Job_Type is set to 'FCI', either standard "Full CI" or Bose-Hubbard Hamiltonians can be treated.

What orbitals will be taken, depends on the input variable "Guess". If you set Guess to 'HAND', then the routine source/ini_guess_pot/Get_Initial_Orbitals.F will be executed to specify the orbitals of the initial guess, if Guess='BINR' ('DATA'), the program will restart with the orbitals in the PSI_bin file ( ASCII file with the filename you specified by Restart_Orbital_FileName) in the working directory.

After the initial guess' orbitals and coefficients are determined, a full CI computation is done -- that is, the coefficients are propagated in real or imaginary time.

Did that resolve your question?


Analysis Program Usage / R-MCTDHB Synopsis
« on: October 17, 2013, 11:50:07 PM »
The Recursive implementation of the multiconfigurational time-dependent Hartree for bosons

What is it?
A collection of programs and scripts to solve exactly the time-dependent many-boson Schr?dinger equation and visualize the obtained solutions. The numerical solution of the problem is obtained with an efficient, shared and distributed memory-parallelized Fortran program that can be used with bash scripts or through a graphical user interface. From the simulation's output, graphs and videos are generated by invoking bash scripts that use mencoder and gnuplot for the task.

How it is documented?
The usage of the program is documented in a user manual and the code is documented in doxygen-generated html pages containing call- and caller-graphs.

How is it managed?
The code is version managed by mercurial (hg).

What does it need?
The program package can be installed on any Linux/Unix-based system that has a bash-shell, GCC or Intel Fortran compilers, and LAPACK, FFTW, and/or Intel MKL.

Pages: [1]