CC3/aug-cc-pVTZ linear response segfaults

[sujona]

This calculation works for CC3/aug-cc-pVDZ and for CC2/aug-cc-pVTZ but not for CC3/aug-cc-pVTZ. I have tried with Dalton2016 on one computer and with Dalton2018 on another computer., with segmentation fault in both cases. These were serial runs with the command

Code: Select all

dalton run.dal geometry.mol 

I tried increasing the memory 8 GB with the flag "-mb 8000" with the same result.

My assumption is that the CC3 linear response is the most accurate method for linear response available. If some other method is preferable then that would be an alternative. Any suggestion on this?

run.dal:

Code: Select all

**DALTON INPUT
.RUN WAVE FUNCTIONS
.DIRECT
**INTEGRALS
.CARMOM
3
**WAVE FUNCTIONS
.CC
*CC INPUT
.CC3
!
*CCLR
.OPERAT
CM010000CM010000
CM000100CM000100
CM000001CM000001
CM020000CM020000
CM010100CM010100
CM010001CM010001
CM000200CM000200
CM000101CM000101
CM000002CM000002
!
**END OF DALTON INPUT

geometry.mol:

Code: Select all

BASIS
aug-cc-pVTZ
H2O without symmetry
---
Atomtypes=2 Nosymmetry Angstrom
Charge=8.0 Atoms=1 
O       0.00000000      0.00000000      0.06539679
Charge=1.0 Atoms=2 
H      -0.75714271      0.00000000     -0.52317428
H       0.75714271      0.00000000     -0.52317428

Error message:

Code: Select all

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FCEF8CCCE08
#1  0x7FCEF8CCBF90
#2  0x7FCEF83FD4AF
#3  0x951AFD in ccrda1_
#4  0x952E0B in ccrdao_
#5  0x1632B22 in cc3_barint_
#6  0x27858D9 in cc3_ft3b_
#7  0x17831B3 in cc_fmatnew_
#8  0x178785C in cc_fmatrix_
#9  0x786A83 in cc_solrsp_
#10  0x58A929 in cc_drv_
#11  0x40CC12 in execc_
#12  0x410118 in dalton_exedrv_
#13  0x404E1C in MAIN__ at dalton.F:?
/home/j/gits/dalton/build/dalton: line 722: 14956 Segmentation fault      (core dumped) $DALTON_EXE
Error in /home/j/gits/dalton/build/dalton.x, exit code 139

SERIOUS ERROR:
DALTON finished with non-zero exit code: 139

File list in scratch directory:

total 432200
-rw-rw-r-- 1 j j 34560576 mar  9 22:48 AO2DIS00
-rw-rw-r-- 1 j j      720 mar  9 22:48 AOTWODIS
-rw-rw---- 1 j j 22101480 mar  9 22:48 CCSDT_FBMAT1
-rw-rw---- 1 j j  1270200 mar  9 22:48 CCSDT_FBMAT2
-rw-rw---- 1 j j        0 mar  9 22:48 CCSDT_FBMAT3
-rw-rw---- 1 j j        0 mar  9 22:48 CCSDT_FBMAT4
-rw-rw---- 1 j j        0 mar  9 22:48 CCSDT_FBMAT5
...

[magnus]

I'm trying to reproduce the error. At what point in the calculation did it fail? It would make it easier if you attached the output file (which btw also contains the contents of the dal and mol file).

You could consider CCSDR(3) as an alternative which is not as accurate but very close according to some benchmarks. Here are references to the original paper as well as some benchmark studies:
https://doi.org/10.1063/1.472007
https://doi.org/10.1016/0009-2614(96)00394-6
https://doi.org/10.1021/ct800256j

[kennethruud]

This error is often a symptom of too little memory in the calculation or on the compute cluster. Try increase the memory for the calculation.


Best regards,

Kenneth

[magnus]

Most likely Kenneth is correct. The calculation completes using 14 GB with Dalton2018.1. Output attached.

[sujona]

Thanks for the references Magnus!

The calculation ran for about 50 minutes on my desktop before it failed. I think the problem occurs in the response calculation, because it does not fail when computing first-order properties with .CCFOP instead of response with .CCLR, and the CC3 energies are in the output file and seem fine. I attached the output file.

Kenneth: I thought of this and tried with 8GB. But looking at some previous attempt, the segfault occurs at the same point with 2.4 GB and with 5.7GB (the attached file). But if both those numbers are too small for the specific task I guess this could be the result anyway. I'll try with more memory.

[sujona]

Hi again, apparently you posted your answer while I was writing mine. I didn't realize it would require that much RAM, sorry for the hassle! But this is great, thanks a lot!

[magnus]

Not sure if you need 14 GB though. I just chose a rather high amount.

[hjaaj]

It seemed strange that it should need so much memory, so I investigated further. It turns out that because of a programming error, it only worked if all 2-electron integrals fitted in memory (and maybe it gave wrong results even in this case). This explained the amount of memory needed for the calculation to complete.

I have fixed the error, and if you update your dalton clone to the newest version (master or release/2018 branch), your CC3 calculation should work without asking for a lot of memory.

[xiongyan21]

I use sequencially compiled Dalton 2018.1 on Ubuntu18.04 with a smaller memery(12GB) than that used by Prof. Olsen and find the calculation, i.e., CC3/aug-cc-pVTZ, surely can be successful. The log file is attached,

[xiongyan21]

Dear Prof. Olsen
Can we use the new CC methods to run this example, and what are the corresponding operators?
I cannot find the manual of Dalton2018.1.

Very Best Regards!
Thanks a lot.

[magnus]

I'm not exactly sure which new CC method you are referring to but Hans Jørgen fixed the memory issue in the latest version (Dalton2018.2). You can find the manual for the latest version here: http://daltonprogram.org/manuals/dalton2018manual.pdf

FYI I'm not a prof

[xiongyan21]

Dear Dr. Olsen
I mean the new methods in Dalton2018.1, e.g.,
488 - benchmark_eri_adz
490 - benchmark_eri_atzs
492 - benchmark_eri_r12xl
493 - benchmark_her_adz
495 - benchmark_her_atzs

Very Best Regards!
Thanks a lot!

[magnus]

I see. Those are really old test cases meant to be used only for performance benchmarks.

[hjaaj]

In addition, these benchmark* tests will on many systems give timeout with the default 20 min max time for a test (esp. if run in sequential mode).

[xiongyan21]

I mean I wish to use CCSD(T) to calculate the same properties.
The input is
**DALTON INPUT
.RUN WAVE FUNCTIONS
.DIRECT
**INTEGRALS
.CARMOM
3
**WAVE FUNCTIONS
.CC
*CC INPUT
.CC(T)
!
*CCLR
.OPERAT
CM010000CM010000
CM000100CM000100
CM000001CM000001
CM020000CM020000
CM010100CM010100
CM010001CM010001
CM000200CM000200
CM000101CM000101
CM000002CM000002
!
**END OF DALTON INPUT
but it fails with the following
+----------------------------------+
! Coupled Cluster model is CCSD(T) !
+----------------------------------+

RPA: call cceq_str
I/O ERROR IN GETWA2:
FILE:PTFOP2
UNIT: 9
IADR: 1
LEN : 40020
IERR: -5

--- SEVERE ERROR, PROGRAM WILL BE ABORTED ---
Date and time (Linux) : Sun Apr 7 09:53:19 2019
Host name : ...

Reason: I/O ERROR IN GETWA2.
...
QTRACE dump of internal trace stack

========================
level module
========================
10 CCSDPT_ETA
9 CC_ETA
8 CC_GETGD
7 CCEQ_STR
6 CC_SOLDRV
5 CC_FOP
4 CC_DRV
3 CC
2 DALTON
1 DALTON main
========================

[hjaaj]

Check stderr output, there should be more information about the I/O problem.

[xiongyan21]

Dear Prof. Jensen
There is no file called that in the related tar.gz file.
Very Best Regards!

[hjaaj]

No, the stderr output is usually in your log file from the job.

[xiongyan21]

Dear Prof. Jensen
It seems there is no stderr in the log file.
I think the error is caused by the fact that no such operators match CCSD(T).
Very Best Regards!