- Posts: 97
- Thank you received: 3
Interchanging keywords between interfaced programs
- Nike
- Topic Author
- Offline
- Premium Member
Less
More
7 years 7 months ago #366
by Nike
Replied by Nike on topic Interchanging keywords between interfaced programs
Greetings!
1) Thank you for the reply! I will continue my battle with CFOUR then
2) iface=Cfour worked !! For a small basis set, the MRCC was tricked into thinking that it should be reading integrals calculated from CFOUR, but instead it read in the integrals calculated from MRCC. For aug-cc-pCV8Z with the k- and l-functions removed, it has been reading in data all day, so I don't yet know whether this will be faster than calculating from scratch (the AO -> MO transformation originally took almost 2 days with MRCC, so tomorrow we'll know if it saved me any time).
I note that reading in an FCIDUMP file for aug-cc-pCV8Z only takes about 1 hour in other programs, and the integrals are not even stored in binary (they're in readable ascii). Has there been any thought into supporting the FCIDUMP format for 1- and 2-electron integrals in MRCC? How about using SEWARD to do the integrals? SEWARD seems to do the integrals much faster and would not require us to remove the k- and l-functions (actually SEWARD supports up to L=15 angular momentum)
3) I had "mem=490GB" and the energy after Iteration 4 was -37.84075510. I did not change the "mem" variable, in fact when I run the command: "diff MINP ../MINP" The only result I get is: "rest=1". But the output says "The number of active orbitals has been changed! It is dangerous to restart the program!" and all the iterations are giving me energies 6 Hartree higher. Is there anything else that could have caused this? Corruption of one of the files?
For a different case, it does seem that I changed 300GB to 480GB but the energy only increased from -224.80916923 to 5 Hartree higher.
4) In this case CCSDTQ completed, but during one of the spin cases for (P) the program crashed due to time limit on the cluster (maybe while in the middle of writing something in one of the fort.* files). Therefore, perhaps I should save backups of the fort.16 and fort.17 files after the CCSDTQ finishes, so that if something happens during the (P), I can do a run with rest=1 without problems. However, if the file with CC amplitudes was corrupted, wouldn't the situation be worse? CCSDTQ starting from the CCSDT(Q) calculated during the rest=2, converged in 12 cycles to: -37.44463304, but rest=1 started cycle 1 at -37.42010169. It seems it didn't use the cluster amplitudes at all and just started from scratch.
With best wishes,
And much appreciation,
Nike Dattani
1) Thank you for the reply! I will continue my battle with CFOUR then
2) iface=Cfour worked !! For a small basis set, the MRCC was tricked into thinking that it should be reading integrals calculated from CFOUR, but instead it read in the integrals calculated from MRCC. For aug-cc-pCV8Z with the k- and l-functions removed, it has been reading in data all day, so I don't yet know whether this will be faster than calculating from scratch (the AO -> MO transformation originally took almost 2 days with MRCC, so tomorrow we'll know if it saved me any time).
I note that reading in an FCIDUMP file for aug-cc-pCV8Z only takes about 1 hour in other programs, and the integrals are not even stored in binary (they're in readable ascii). Has there been any thought into supporting the FCIDUMP format for 1- and 2-electron integrals in MRCC? How about using SEWARD to do the integrals? SEWARD seems to do the integrals much faster and would not require us to remove the k- and l-functions (actually SEWARD supports up to L=15 angular momentum)
3) I had "mem=490GB" and the energy after Iteration 4 was -37.84075510. I did not change the "mem" variable, in fact when I run the command: "diff MINP ../MINP" The only result I get is: "rest=1". But the output says "The number of active orbitals has been changed! It is dangerous to restart the program!" and all the iterations are giving me energies 6 Hartree higher. Is there anything else that could have caused this? Corruption of one of the files?
For a different case, it does seem that I changed 300GB to 480GB but the energy only increased from -224.80916923 to 5 Hartree higher.
4) In this case CCSDTQ completed, but during one of the spin cases for (P) the program crashed due to time limit on the cluster (maybe while in the middle of writing something in one of the fort.* files). Therefore, perhaps I should save backups of the fort.16 and fort.17 files after the CCSDTQ finishes, so that if something happens during the (P), I can do a run with rest=1 without problems. However, if the file with CC amplitudes was corrupted, wouldn't the situation be worse? CCSDTQ starting from the CCSDT(Q) calculated during the rest=2, converged in 12 cycles to: -37.44463304, but rest=1 started cycle 1 at -37.42010169. It seems it didn't use the cluster amplitudes at all and just started from scratch.
With best wishes,
And much appreciation,
Nike Dattani
Please Log in or Create an account to join the conversation.
Time to create page: 0.036 seconds