× If you have problems during the execution of MRCC, please attach the output with an adequate description of your case as well as the followings:
  • the way mrcc was invoked
  • the way build.mrcc was invoked
  • the output of build.mrcc
  • compiler version (for example: ifort -V, gfortran -v)
  • blas/lapack versions
  • as well as gcc and glibc versions

This information really helps us during troubleshooting :)

Running MRCC optimizations in a stepwise fashion

More
4 years 4 months ago #109 by rayultine
Dear Mihaly & MRCC developers,
I am trying to use CFour(v2.00 beta) and MRCC-2014 to perform CCSDT (and beyond) geometry optimizations on metal-containing systems.

Here is my ZMAT:

CCSDT VCN 5D
V
C 1 RVC*
X 2 RDUM 1 DUMA
N 2 RCN* 3 DUMA 1 BANG

RVC = 2.077954734843618
RDUM = 1.000000000000000
DUMA = 90.000000000000000
RCN = 1.172593507993356
BANG = 180.000000000000000

*ACES2(CALC=CC(n),EXCITATION=3,BASIS=SPECIAL,CC_CONV=8
CC_PROG=MRCC,ORBITALS=STANDARD
LINEQ_MAXCY=225,CC_MAXCYC=200
SCF_CONV=9,LINEQ_CONV=10,DROPMO=1>11,SCF_EXPSTAR=10
SCF_DAMP=500,SCF_EXPORDER=8,SCF_MAXCYC=750,SPHERICAL=ON
UNITS=ANGSTROM,OCCUPATION=11-4-4-1/10-3-3-0,REF=ROHF,MULT=5
MEMORY=1000000000)

V:PVTZ
C:PVTZ
N:PVTZ

I have MRCC compiled to stop after 30 iterations. This specific calculation does not converge in 30 iterations:
Iteration 30 CC energy: -1035.68909003 Energy decrease: 0.00000001
======================================================================

Convergence not achieved in 30 iterations!

Final results:
Total CCSDT energy [au]: -1035.689090027173

But CFour/MRCC begins to run the LR-CC part of the calculation:
Starting left-hand LR-CC iteration for root 1 ...

then

Iteration 30 CI energy: -1035.68909003 Energy decrease: 0.0000E+00
======================================================================
Convergence not achieved in 30 iterations!
Final results:
Total CCSDT energy [au]: -1035.689090027173
Calculating reduced density-matrix for root 1...

At this point, the job hangs (unless calculating this density matrix is taking a very long time, but each CC iteration is taking only 14-20 minutes)

I would like to just run this optimization stepwise -
1) run the CFour modules necessary to set up MRCC
2) run MRCC in 30 iteration pieces until the CC energy converges
3) run MRCC in 30 iteration pieces until the left-hand CC converges, then form the density and take the derivatives
4) push back to CFour, take the optimization step
and loop manually until the geometry is converged.

An issue that I find is that when I run MRCC manually with the option dens=2, the left-hand CC and density matrix parts will run even if the MRCC energy is not converged. However, if I just get the CCSDT energy converged with dens=0, then try to take the converged amplitudes and run it with dens=2, I get the error message:

Calculation of coupling coefficients...
Former cluster amplitudes are missing!
The program is unable to restart!

When I set the file back to dens=0 and restart, then the ensuing single point calculation can pick up the converged fort.16 amplitudes with no problem:

Initial cluster amplitudes are read from unit 16.
Length of intermediate file (Mbytes): 612.6
Reading integral list from unit 55...
Sorting integrals...

CPU time [min]: 14.037 Wall time [min]: 14.036
Iteration 1 CC energy: -1035.68909002 Energy decrease: 6.3665E-12
======================================================================
Iteration has converged in 1 steps.
Final results:
Total CCSDT energy [au]: -1035.689090023307

This suggests that my TORQUE submission script is correctly copying the necessary files to the compute nodes.

Any suggestions?
Dr. Nathan DeYonker (ndyonker AT memphis.edu)
Research Scientist
Department of Chemistry
University of Memphis

Please Log in or Create an account to join the conversation.

More
4 years 4 months ago #110 by kallay
Dear Nathan,

I think you should increase the max. number of iterations. To that end you should edit file MRCCCOMMON, change the value of variable maxit, and recompile the program. In this way you can avoid the repeated restarting. Please also note that the default convergence criteria are rather conservative and can be decreased in particular cases depending on what accuracy is needed for the geometry. You should run test calculations on smaller test systems.

For restarting CC gradient calculations you need both the converged cluster and lambda amplitudes. Thus, you cannot restart a CC gradient calculation (dens=2) from the results of an energy calculation (dens=0).

What you can also try is to restart the CC gardient calculation in each iteration step of the geom. opt. from the amplitudes calculated at the previous geometry. Set INPUT_MRCC=OFF in the ZMAT file, take the fort.* scratch files generated in your previous geom. opt. attempts, edit fort.56, change the fourth integer in the first line to 1, and start the geom. opt. with xcfour.

Best regards,
Mihaly Kallay

Please Log in or Create an account to join the conversation.

More
4 years 4 months ago #111 by rayultine
Mihaly,
I was expecting this answer. It is unfortunate that the CC amplitudes and the lambda amplitudes are coupled in this way. I would prefer to actually DECREASE the max. number of iterations, especially when I will be running larger calculations. The way that our cluster is set up, there are usually multiple SMP jobs running on each of our large-disk nodes. When memory or disk space are allocated unwisely (more often by other members at my university), the fort.* files from my MRCC jobs are usually not recoverable. So I typically like to run my MRCC single point energies in batches of 10-15 iterations to be extra cautious. Some of my published MRCC results were from jobs that took more than 1 day per CC iteration. You probably understand how infuriating it can be to lose weeks/months of number crunching.

There's absolutely no way to fiddle with the logic of the code to bootstrap converged CC amplitudes to the beginning of the lambda amplitude calculation?

And thanks for the tip with restarting from the previous geometry's amplitudes. That's a good idea!

Nate

Please Log in or Create an account to join the conversation.

More
4 years 4 months ago #112 by kallay
Dear Nathan,
I see your problem. After the CC energy calculation you should copy fort.16 to fort.17 and to fort.63, then start the CC gradient calculation. In this way both the CC amplitude and the lambda equations will restart from the CC amplitudes calculated in the first step.

Best regards,
Mihaly Kallay
The following user(s) said Thank You: rayultine

Please Log in or Create an account to join the conversation.

More
4 years 4 months ago #113 by rayultine
Mihaly,
That appears to be working. Thank you so much for your help. I am going to have even more fun with MRCC now!

Please Log in or Create an account to join the conversation.

More
4 years 4 months ago #114 by rayultine
Mihaly,
One more quick question: Why does the program calculate the density matrix if the lambda equations do not converge?

======================================================================
Norm of residual vector: 0.00000001
CPU time [min]: 826.216 Wall time [min]: 826.216

Iteration 30 CI energy: -1035.68909002 Energy decrease: 0.0000E+00
======================================================================

Convergence not achieved in 30 iterations!

Final results:
Total CCSDT energy [au]: -1035.689090023320
Calculating reduced density-matrix for root 1...

Total energy from RDM [au]: -1035.689090023435

What error/success messages should the program give when the process of computing the RDM is finished? Or is the program stuck at this point?

Please Log in or Create an account to join the conversation.

Time to create page: 0.043 seconds
Powered by Kunena Forum