Interchanging keywords between interfaced programs

Dear all!
One MRCC keyword I like very much is: rest=2
which allows me to get the CCSD, CCSDT, CCSDTQ, CCSDTQP ..
energies all with one input file and one job submission.

However, CFOUR doesn't seem to have anything similar, so if I want to use X2C or Dirac-Coulomb Hamiltonians, I (think I) need to make a separate folder for each CC level, and run each job individually, often having to manually go in and copy the relevant cluster amplitudes from the previous CC level for better convergence at the higher CC level.

Is there a way to use rest=2 from inside CFOUR or X2C Hamiltonian from inside MRCC ?

Similarly, for calculations requiring very large amounts of memory, the MRCC called from CFOUR says "Allocation of 0.0 Mbytes of Memory" and the program doesn't run. The exact same high-memory calculation runs perfectly if I run it in MRCC as a stand-alone, but not when I run MRCC from CFOUR. Therefore, I wonder if there's a way to use the X2C or Dirac-Coulomb Hamiltonian from within the standalone MRCC code?

Finally, I wonder about using rest=1 in MRCC from a fort.16 file produced from the MRCC within CFOUR. I calculated CCSDTQ in an uncontracted aug-cc-pCVQZ basis set with the MRCC called within CFOUR and it took: 11565.408 minutes. I now want to add the (P) correction, but cannot do it from the MRCC called within CFOUR, because I get "Allocation of 0.0 Mbytes" when asking for 450GB of RAM. When using "standalone" MRCC, the program successfully allocates 450GB of RAM, and runs fine, but even with rest=1 and the fort.16 file copied into the directory, the CCSDTQ starts from the very beginning (iteration 1), rather than just doing the (P) on top of the fully converged CCSDTQ. For this reason, I wonder about the possibility of using "rest=1", or something similar, from within CFOUR?

With very best wishes,
Nike Dattani

Dear Nike,
To use rest=2 with cfour you should turn off the automatic writing of the mrcc input file. That is, your ZMAT should include INPUT_MRCC=OFF. Then you have to write a MINP file including iface=cfour and any mrcc keywords you would like, such as rest=2.
X2c calculations are not possible with mrcc in standalone mode, but your problem may be resolved if you write a MINP file as explained above and give the memory (mem=...) available to mrcc.
If you restart a CCSDTQ(P) calculation from a CCSDTQ amplitudes at least one CCSDTQ iteration step will be performed.

Greetings!
Thank you very much for explaining to me how to use MRCC"s brilliant rest=2 from CFOUR!
I anticipate finding this very useful !!

However, I keep getting :


in MRCC. I tried various things, including specifying the occupation numbers in CFOUR's D2h specification, and in MRCC's D2h specification. For example below I have a ZMAT using CFOUR's D2h specification, and a MINP using MRCC's D2h specification, but when I run the job, even in a clean folder, I get the symmetry error:

However, this works perfectly fine if I just run the ZMAT in the absence of INPUT_MRCC=OFF and the MINP file.

I also wonder about the memory specification:
In the above examples, I'm using a node with 128GB of RAM, so I've specified 110GB in CFOUR and in MRCC. Would this need 220GB of RAM? I wondder if the programs collectively smart enough to know that I want 110GB when CFOUR is running, and 110GB when MRCC is running. Do you have a recommendation if I want MRCC to be doing the heavy lifting?

Dear Nike,
If INPUT_MRCC=OFF is set in the ZMAT file, no information is passed over to mrcc other than the integral list. So you should set everything in the MINP file.
The occ keyword does not work in this case, but you should set the reference determinant using the refdet keyword. The follow MINP file is an input for a high-spin triplet calculation for Li₂. The first two orbitals are doubly occupied, while the third and fourth ones are singly occupied and are of Ag and B1u symmetry. That is, the symmetry of the state is B1u, which is the 5th irrep according to cfour's convention, this is why symm=5 is set.

iface=cfour
calc=CCSDT(Q)
rest=2
refdet=serialno
1,2
3,4

mult=3
symm=5
mem=110GB
rest=2

Greetings!
Thank you for the advice !!
rest=2 is working now with CFOUR integrals !!

However, I have been having trouble with x2c.
For aug-cc-pCV6Z-uncontracted, MRCC standalone gives exactly the same non-relativistic ROHF energy as MOLPRO. However, CFOUR cannot get the SCF to converge for this basis set (whether non-relativistic or x2c), so I wasn't able to do x2c, even though the integrals and Fock matrix construction were calculated fairly quickly. Is there any undocumented feature in MRCC that would allow us to do the SCF iterations on the x2c Fock matrix generated by CFOUR?

Similarly, for non-relativistic calculations, is it possible in MRCC to read in the transformed integrals and go straight to the coupled cluster? I ask because the integrals and the AO -> MO transformation for one of my big basis sets took 21 days, and the cluster has a 30-day limit, so each time I use rest=1 I'm only able to do 9 days worth of work rather than 30 days.

The rest=1 is also giving some strange results. In the first run the energies (correctly) reached -37.84075510 after 4 iterations, but when I used rest=1 to restart, the energies were now 6 Hartree higher! I noticed the error: "The number of active orbitals has been changed! It is dangerous to restart the program!". Do you know what we can do to prevent that?

Finally in the first reply of Kallay, it is suggested that when using rest=1 to do (P) on top of CCSDTQ, at least one iteration of CCSDTQ will be done, even if the CCSDTQ was already converged in the previous run. However, I have a CCSDTQ that converged in 12 iterations to -37.44463304. It crashed during "Spin case 4 Alpha: 3 Beta: 2" and when I did ran with rest=1, it took 17 iterations to converge! I was curious why it could take MORE cycles, and indeed it seems to be because the energy at iteration 1 was already -37.44462257 in the first case (thanks to using rest=2 and starting form a converged CCSDT(Q) calculation), when I used rest=1 the energy after iteration 1 was much higher: -37.42010169, so it took 17 iterations instead of 12. This was all done in the same folder, so all the fort.* files were there. I've also started with a new folder and copied over the fort.17 and fort.16 but the same thing happened. So I wonder what's the best way to use rest=1 to minimize duplication of work?

So in summary my questions are:
1) Can we use MRCC to do the SCF iterations when CFOUR calculates the x2c integrals and x2c Fock matrix?
2) Can MRCC read in it's own transformed integrals which were generated by MRCC?
3) How do we prevent "The number of active orbitals has been changed! It is dangerous to restart the program!" when using rest=1 ?
4) When using rest=1 to do (P) on top of a converged CCSDTQ, why does the the CCSDTQ take 17 iterations the second time, when it only took 12 iterations in the case that it's restarting from?

With best wishes!!
Nike Dattani

Dear Nike,
1) Unfortunately not. You should persuade Cfour's SCF to converge.
2) Yes, it can, in principle. You should set iface=Cfour in the input, then the program will suppose that the transformed integrals are generated by Cfour and start the CC calculation.
3) You should not change the working memory assigned to the program.
4) I think the file containing the cluster amplitudes got damaged when the program crashed. A converged CC calculation should converge in one cycle if restarted with rest=1.