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 :)

Restarting coupled-cluster

  • irikura
  • Topic Author
  • Offline
  • New Member
  • New Member
More
11 months 1 week ago #1370 by irikura
Restarting coupled-cluster was created by irikura
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

 

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

More
11 months 1 week ago #1371 by Nike
Replied by Nike on topic Restarting coupled-cluster
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

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

  • irikura
  • Topic Author
  • Offline
  • New Member
  • New Member
More
11 months 1 week ago #1372 by irikura
Replied by irikura on topic Restarting coupled-cluster
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

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

  • irikura
  • Topic Author
  • Offline
  • New Member
  • New Member
More
11 months 6 days ago #1373 by irikura
Replied by irikura on topic Restarting coupled-cluster
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

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

  • irikura
  • Topic Author
  • Offline
  • New Member
  • New Member
More
8 months 3 weeks ago #1394 by irikura
Replied by irikura on topic Restarting coupled-cluster
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.

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

More
8 months 3 weeks ago #1397 by Nike
Replied by Nike on topic Restarting coupled-cluster
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

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

Time to create page: 0.050 seconds
Powered by Kunena Forum