Hi Blazej,
..the forum does not like the extensions.
It does, but you have to gzip them as it believes that plain text files could be malware (see the 'How to use these forums' post in 'General Announcements').
Is it really that bad? For smaller timesteps i don't get such problems (although the calculations are in progress). If not, what can be the reason of such error?
Your run is far too long for me to run on 16 cores, but it looks like a perfectly ordinary population catastrophe to me (ordinary catastrophes! you don't hear that very often..).
Can you post the graphs obtained from running 'graphdmc' on the dmc.hist file so we can verify?
Although population catastrophes shouldn't occur under normal circumstances, they can be made more likely by various things - such as certain non-local pseudopotentials, non cusp-corrected Gaussian basis, too-severely truncated localized orbitals - none of these apply to you.
Another possibility is inadequate trial wave functions resulting from an optimization procedure that wasn't done properly. but even if it was done properly, note that the likelihood of population explosions can be reduced if you use unreweighted
variance minimization rather than energy minimization to optimize the wave function. The reason for this is related to the fact that energy minimisation doesn't care much about what happens near nodes, since those regions do not contribute much to the energy expectation value. However, the divergent local energies there make a big difference to the stability of the DMC algorithm.
Also, even if none of the above were true, and you had a very low probability (let's say one move in five million) of encountering a catastrophe, the fact that you're running a ten million move simulation (!) means it's extremely likely to happen almost at once (cf. Infinite Improbability Drive..). Also, catastrophes are much more likely to happen for large timesteps (and you say it doesn't happen for small timesteps). Ergo.. use smaller ones. - but that said your current value of 0.003 doesn't seem excessive..
This ought to be manageable if you turned on automatic block-resetting (which detects when a catastophe occurs and rewinds backwards to an earlier point in order to try again with a different random number sequence) but you don't appear to have done this. See the section in the manual about 'Automatic block resetting' or type 'casinohelp dmc_trip_weight' and have a go.
The compute_multiplicities error message could possibly be a bit more clear - I'll try to tidy it up..
Some minor notes:
(1) can you really only afford 16 cores? That's not normally considered enough to do a 144 electron system... No wonder you want to do 10000000 moves!
(2) Blocks are more for your convenience than the computers (except, of course, for block_resetting), and having too many of them will slow down the code considerably, as it has to write to disk at the end of every block.. You might in fact like to switch over too my new 'BLOCK TIME' system that I implemented last week, where you can specify the approximate time interval that should separate blocks rather than by saying how many moves consitutute a block as currently.. I may even remove
vmc_nblock,
dmc_equil_nblock, and
dmc_stats_nblock from the example input files in favour of
block_time.. Year Zero, or what?
M.