Troubleshooting
The ERROR messages of QUNATICS are sometimes a bit cryptic. This page is intended to help you interpreting them.
Please remember that you do have all the code. If an error occurs, you may inspect the code to understand in detail what has caused the program to stop. The scripts mcg and mcb are very helpful for finding the way through the code. The script phelp explains the meaning of the variables.
***** End of file found! ***** last line no.: ...
This error message occurs if the program tries to read beyond
the end of an input file, because the input file is buggy. A common
cause is that the end-input (or end-operator)
line is missing or misspelled. A curios error occurred once when
sending input files via ftp. Somehow the last newline
"character" -- this character terminates a line -- got lost and the
end-input line could not be read. The solution is simple,
just add a blank line after end-input.
Cannot open file <....> message appears, although the file exist.
First check by running "ls <....>" whether the file <....> exist. One may have given a wrong path. Note that in MCTDH relative paths are always relative to the location of the input file. If the file exist, the problem is likely due to the fact that FORTRAN cannot open a file twice. Hence it may become necessary to copy a file such that the same information can be read via two different file-paths. Such problems may arise when using block-SPF and block-A, or when using orthogonalise.
Stack size problems / mysterious segmentation faults
A few of the older analyse programs allocate big arrays of memory statically. Since such memory gets allocated on the stack, you can run into problems if the maximum stack size is limited (this can be checked with "ulimit -a"). This problem manifests itself in segmentation violations that occur immediately after program startup. To work around this problem, you can disable the limit on the stack size by "ulimit -s unlimited". However, you might not be allowed to do this on your system. In this case, try talking to your system administrator. If that doesn't help, you can decrease the needed stack size by changing the appropriate parameters in the affected programs.
Redundant configuration
To avoid redundant configurations the numbers of SPFs, nk, must satisfy the relation
nk2 ≤ Product (l=1,f)
nl
If there are only two particles (f=2), this implies that the (two) numbers of SPFs must be identical. In almost all other cases the relation above does not impose a restriction.
"nodiag" and "usediag"
If a unit-operator appears in the product form of a Hamiltonian, it will simply be ignored if the Hamiltonian is build with usediag. However, if the bra and ket wavefunctions of an matrix element are different and have different sets of SPFs, the unit operator is turned into an non-unit overlap matrix and cannot be ignored. In such a case nodiag must be set. Note:
usediag is used for the system Hamiltonian, eigenf, meigenf, expect, pexpect, and for separable operators for flux.
nodiag is used for operate, fmat, and flux.
The MCTDH program tries to determine the usediag/nodiag type automatically. If one needs a usediag operator for some analyse routine, usediag has to be explicitly specified. nodiag is default, except MCTDH recognizes that the operator should be usediag (i.e. for system, eigenf, meigenf, and expect).
In rare cases one may have to define an operator twice, once as nodiag and once as usediag. Such a situation occurs if one wants to use the same operator for, say, operate and eigenf.
Slow propagation. The integrators take very small step sizes
This problem occurs if the Hamiltonian has very large eigenvalues. These very large (absolute) eigenvalues are almost always due to large potential values. One has to cut the potential at some reasonable value. This is legitimate, because the wavepacket avoids regions of high potential energy.
The cutting of the potential most conveniently done by setting vcut < ... in the Operator-Section of the potfit input file. (Note that the v < ... statement of the Correlated-Weights-Section must refer to a lower value as the cut). In case of an "exact" calculation, a cut may be applied in the Operator-Section of the MCTDH input. In the general case, a sensible cut may be difficult to implement. The step-functions step and rstep may be used in the Hamiltonian section to serve this purpose.
Time, fs, time-not-fs, and energy-not-ev
The MCTDH package uses atomic units (au) throughout. To simplify life, the user may use other units when specifying parameters. In this case, the unit has to be added to the value, e. g. eshift = 1.5,ev. With times, the situation is more subtly. (This is because units were introduced after we had chosen to use fs for times). In the input file (*.inp) all times are assumed to be in fs and a unit must not be given. In the operator file (*.op), however, all variables are in au and if one wants to input a time in fs, one has to add the unit fs. This also holds for a Parameter-Section or an alter-parameter block of the input file.
When studying a model problem in dimensionless coordinates an automatic conversion, fs -> au, may not be wanted. In such a case one may give the keyword "time-not-fs" in the Run-Section. This keyword inhibits the conversion and all times in in- and output are in atomic units (or in the dimensionless units one has adopted).
Similarly there is the keyword "energy-not-ev" which inhibits the conversion to eV of the energies printed to the output file. The energies printed to the output file still carry the label "eV", but − when "energy-not-ev" is given − they actually are in au (or in the dimensionless units one has adopted).
Some pl-scripts, like plgpop, plnat, plqdq, and plstate, require that the option -n is set when "time-not-fs" was set during the MCTDH run. For plspec (and autospec84) one must give no as unit argument.
Parameter already
assigned :..
Label already assigned : ...
Parameters and operator labels cannot be re-assigned. When one tries to assign a value to an already existing parameter the message:
Parameter already assigned : <parameter name >
is printed to the log file. The re-assignment is simply ignored. A similar rule applies to labels. This is a very sensible rule as it allows us to overwrite parameters or labels which are predefined in an operator file. The MCTDH program first evaluates the command line options, then a Parameter-Section in the input file (if such section exist), then an alter-parameter block in the Operator-Section of the input file and finally the Parameter-Section of the operator file. Because of the "first come, first served" rule, one may define a parameter in e.g. an alter-parameter block, and the definition of this parameter done in the operator file is ignored (and similarly for labels). However, this behaviour may lead to strange results, if one erroneously defines a parameter (or label) twice. The second definition will simply be ignored (except for a message printed to the log file). For example, if there is an alter-labels block like:
alter-labels
CAP_x = CAP [ −9.0 0.03 3 −1 ]
CAP_x = CAP [ 9.0 0.03 3 +1 ]
end-alter-labels
then the second (right hand) CAP will simply be ignored. The solution is simple, just assign different labels to the CAPs, e.g. CAP1_x and CAP2_x, or CAPleft_x and CAPright_x.