Messages

1

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!

2

Main Program Usage / Re: What's the optimal number of threads in parallel computations?

« on: February 07, 2020, 11:12:52 AM »

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!

3

Main Program Usage / Re: Difference in the results between "type 2" and IMEST interaction for a 2D system

« on: January 23, 2020, 10:28:35 AM »

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,
Axel

4

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]

DVR_X=4
DVR_Y=4
DVR_Z=4

This is actually the default setting.

Hope that helps,
Axel

5

Main Program Usage / Re: Regarding delta funciton for the interaction.

« on: May 22, 2018, 01:16:20 PM »

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) ).

Regards,
Axel

6

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?

Regards,
Axel

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

7

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.

Regards,
Axel

8

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:  http://ultracold.org/menu/

9

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.