Restarting coupled-cluster

Hi,
I'm having trouble restarting a CCSDTQ calculation.  I copied the fort.16 file, but that seemed to have no effect.  I did a test using CCSDT, killing the job after several iterations (it did not obey ccmaxit=10).  But even copying all the files in the scratch directory, the restart jobs (rest=1) did not start with a small "Norm of residual vector" as I expected.  

I would be grateful for any hints!

Thanks,
Karl

 

Hi Karl,
You wrote that you did a test using CCSDT, when starting with a fort.16 file from CCSDTQ. Why not try to do CCSDTQ from the CCSDTQ fort.16 file? Was it an accident that you tried to do CCSDT starting with quadruple-excitation cluster amplitudes that are non-zero?

With best wishes,
Nike

Hi Nike,

Sorry, that was not clear. The expensive CCSDTQ (executed using rest=2) did not restart in the way that I expected (using only fort.16). I wondered if more files were needed, in addition to fort.16.

As a test, I did a fresh CCSDT calculation and killed it after a 10 iterations (initial norm=1.51, norm=0.0019 when killed). I then did a restart of CCSDT (rest=1) using all the files from the scratch directory for the initial CCSDT. The restarted calculation began with norm=1.52, but I expected it to begin with norm=0.0019. The output includes, "Initial cluster amplitudes are read from unit 16." I am copying files to the new scratch directory--maybe that is incorrect?

Thanks,
Karl

I think the problem only occurs when ECP is in use. I ran successful restarts on H2O and NH2- (RHF) and NH2 (UHF). But HI with ecp did not restart properly. Here is the restart input file. I would be grateful for any suggestions.

# simpler test of restarting CC
mem=8GB
cmpgrp=C2v
core=0

basis=atomtype
I:aug-cc-pVDZ-PP
H:aug-cc-pVDZ
ecp=auto

scftype=RHF
calc=CCSDT
ccmaxit=5

geom
I
H 1 R

R=1.6

I just noticed the following message:
>> The number of active orbitals has been changed!
>> It is dangerous to restart the program!

The number of active orbitals has not changed. The message seems consistent with confusion deriving from the ECP.

When it says:
>> The number of active orbitals has been changed!
>> It is dangerous to restart the program!

That almost always means that the amount of RAM available (or the number of cores available) has changed. The software runs `goldstone` then `xmrcc`, then determines if there's enough RAM to do the calculation based on the amount of cores that you want to use. If there's not enough RAM, then it will make adjustments in order to use less RAM (and more CPU time). When restarting, you need to make sure that these "adjustments" are precisely the same as they were the first time that you ran the calculation, otherwise the "change in the number of active orbitals" (as confusing as that message might be, because you didn't intend to change the number of active orbitals, nor did you instruct MRCC to do that) will cause your restart not to work properly.

Here's an example in which I got the same message about the number of inactive orbitals, but the restart worked perfectly fine because I used the same amount of RAM and the same number of cores as in the first calculation (so the "adjustments" that I mentioned, to make the calculation more memory-efficient, were precisely the same): github.com/HPQC-LABS/FeMoco/blob/master/...MRCC_out.1660024.txt