Recent Posts

11

Main Program Usage / Default choice of the starting orbitals

« Last post by chrisapo on February 10, 2020, 10:20:14 AM »

Hello. Thank you for your useful answers. I came up with a few others

I noticed that the default behavior of MCTDH-X's last version, when the GUESS='HAND' option is set, is to start from orbitals that are random functions. Is there a particular reason for this? Does the program work better with this random starting point?

Also, from this I deduce that the starting orbitals do not need to be orthogonal to each other. Am I correct?

12

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

« Last post by mctdhb 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!

13

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

« Last post by chrisapo on January 30, 2020, 11:58:43 PM »

Hello.
Regarding hybridly parallel computations, here's an excerpt from MCTDH-X's manual:

the most efficient way is usually to run MCTDH-X with at least as many MPI processes as there are orbitals. The OpenMP shared memory parallelization takes care of efficiently performing the computational task inside of each MPI process."

So, it is suggested a rule of thumb for the number of MPI processes: at least as many as there are orbitals. My question is then: is there a similar rule of thumb for the appropriate number of OpenMP threads (per MPI process)?

14

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

« Last post by mctdhb 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

15

Main Program Usage / Re: Is it possible to implement PBC?

« Last post by mctdhb 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

16

Main Program Usage / Is it possible to implement PBC?

« Last post by chrisapo on January 20, 2020, 01:31:45 PM »

Like the subject says, is there a way to implement Periodic Boundary Conditions, at least in 1D? Or is it a feature yet to come?
Just wondering.

17

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

« Last post by chrisapo on January 20, 2020, 11:55:49 AM »

Hi. I'm performing some trial simulation with MCTDH-X and I found some apparently inconsistent results.

I tried to simulate 2 bosons with 4 orbitals, trapped in a 2D parabolic well (whichpot="HO2D") and with a gaussian interaction.
I performed two relaxation simulations, the first one with Interaction_Type=2 (interaction dependent on the distance) and the second one with Interaction_Type=4 (IMEST).
Apart from the parameter Interaction_Type, the two MCTDHX.inp files were exactly the same in the two cases.

I expected to obtain the same results in the two cases, apart from rounding errors, but I didn't. The type 2 interaction gave me a ground state energy of around 2.73, while type 4 interaction gave around 3.11. I attached the two input files, so that you can try to reproduce the results.

This is in stark contrast with the results that I obtained in 1D, where type 2 and type 4 interactions gave always identical results (differences appeared only after several significant digits).

I'm struggling to understand the reason for this discrepancy. Is there something that I overlooked? Or maybe there is some bug related to dimensionality?

Any help would be greatly appreciated. Thank you in advance.

18

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

« Last post by mctdhb 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

19

Main Program Usage / Regarding delta funciton for the interaction.

« Last post by yeongjingwak on March 21, 2018, 08:38:41 AM »

HI. I'm currently delta function as an interaction.

I found that the numerical data is not identical with the analytic one.

For that reason, I wonder how the program approximates delta function.

1. How does the program approximate the Delta function?

2. Does the method have any difference between the analytic delta function?

3. How can I reduce the difference between the analytic delta function and the delta function in the MCTDH-X program?

20

Analysis Program Usage / Re: Memory errors when Phase, Gradient = .T.

« Last post by mctdhb 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.