Find answers or ask questions regarding Dalton calculations.
Please upload an output file showing the problem, if applicable.
(It is not necessary to upload input files, they can be found in the output file.)
-
sujona
- Posts: 9
- Joined: 17 Sep 2018, 13:22
- First name(s): Jonatan
- Last name(s): Öström
- Affiliation: SU
- Country: Sweden
Post
by sujona » 10 Mar 2019, 21:36
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
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
- Posts: 478
- Joined: 27 Jun 2013, 16:32
- First name(s): Jógvan Magnus
- Middle name(s): Haugaard
- Last name(s): Olsen
- Affiliation: Hylleraas Centre, UiT The Arctic University of Norway
- Country: Norway
Post
by magnus » 11 Mar 2019, 09:40
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
- Posts: 252
- Joined: 27 Aug 2013, 16:42
- First name(s): Kenneth
- Last name(s): Ruud
- Affiliation: UiT The Arctic University of Norway
- Country: Norway
Post
by kennethruud » 11 Mar 2019, 09:41
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
- Posts: 478
- Joined: 27 Jun 2013, 16:32
- First name(s): Jógvan Magnus
- Middle name(s): Haugaard
- Last name(s): Olsen
- Affiliation: Hylleraas Centre, UiT The Arctic University of Norway
- Country: Norway
Post
by magnus » 11 Mar 2019, 11:29
Most likely Kenneth is correct. The calculation completes using 14 GB with Dalton2018.1. Output attached.
-
Attachments
-
- cc3_h2o.out
- (56.01 KiB) Downloaded 56 times
-
sujona
- Posts: 9
- Joined: 17 Sep 2018, 13:22
- First name(s): Jonatan
- Last name(s): Öström
- Affiliation: SU
- Country: Sweden
Post
by sujona » 11 Mar 2019, 11:31
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.
-
Attachments
-
- run_geo.out
- (51.1 KiB) Downloaded 44 times
-
sujona
- Posts: 9
- Joined: 17 Sep 2018, 13:22
- First name(s): Jonatan
- Last name(s): Öström
- Affiliation: SU
- Country: Sweden
Post
by sujona » 11 Mar 2019, 13:11
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
- Posts: 478
- Joined: 27 Jun 2013, 16:32
- First name(s): Jógvan Magnus
- Middle name(s): Haugaard
- Last name(s): Olsen
- Affiliation: Hylleraas Centre, UiT The Arctic University of Norway
- Country: Norway
Post
by magnus » 11 Mar 2019, 13:12
Not sure if you need 14 GB though. I just chose a rather high amount.
-
hjaaj
- Posts: 334
- Joined: 27 Jun 2013, 18:44
- First name(s): Hans Jørgen
- Middle name(s): Aagaard
- Last name(s): Jensen
- Affiliation: Universith of Southern Denmark
- Country: Denmark
Post
by hjaaj » 18 Mar 2019, 12:24
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
- Posts: 184
- Joined: 24 Sep 2014, 08:36
- First name(s): yan
- Last name(s): xiong
- Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
- Country: China
Post
by xiongyan21 » 02 Apr 2019, 12:24
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,
-
Attachments
-
- 1.log
- (55.88 KiB) Downloaded 47 times
-
xiongyan21
- Posts: 184
- Joined: 24 Sep 2014, 08:36
- First name(s): yan
- Last name(s): xiong
- Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
- Country: China
Post
by xiongyan21 » 03 Apr 2019, 02:23
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.
Last edited by
xiongyan21 on 15 Nov 2019, 16:00, edited 1 time in total.
-
magnus
- Posts: 478
- Joined: 27 Jun 2013, 16:32
- First name(s): Jógvan Magnus
- Middle name(s): Haugaard
- Last name(s): Olsen
- Affiliation: Hylleraas Centre, UiT The Arctic University of Norway
- Country: Norway
Post
by magnus » 03 Apr 2019, 08:53
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
- Posts: 184
- Joined: 24 Sep 2014, 08:36
- First name(s): yan
- Last name(s): xiong
- Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
- Country: China
Post
by xiongyan21 » 03 Apr 2019, 13:11
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
- Posts: 478
- Joined: 27 Jun 2013, 16:32
- First name(s): Jógvan Magnus
- Middle name(s): Haugaard
- Last name(s): Olsen
- Affiliation: Hylleraas Centre, UiT The Arctic University of Norway
- Country: Norway
Post
by magnus » 03 Apr 2019, 13:15
I see. Those are really old test cases meant to be used only for performance benchmarks.
-
hjaaj
- Posts: 334
- Joined: 27 Jun 2013, 18:44
- First name(s): Hans Jørgen
- Middle name(s): Aagaard
- Last name(s): Jensen
- Affiliation: Universith of Southern Denmark
- Country: Denmark
Post
by hjaaj » 03 Apr 2019, 15:35
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
- Posts: 184
- Joined: 24 Sep 2014, 08:36
- First name(s): yan
- Last name(s): xiong
- Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
- Country: China
Post
by xiongyan21 » 07 Apr 2019, 02:58
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
- Posts: 334
- Joined: 27 Jun 2013, 18:44
- First name(s): Hans Jørgen
- Middle name(s): Aagaard
- Last name(s): Jensen
- Affiliation: Universith of Southern Denmark
- Country: Denmark
Post
by hjaaj » 07 Apr 2019, 19:28
Check stderr output, there should be more information about the I/O problem.
-
xiongyan21
- Posts: 184
- Joined: 24 Sep 2014, 08:36
- First name(s): yan
- Last name(s): xiong
- Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
- Country: China
Post
by xiongyan21 » 08 Apr 2019, 01:51
Dear Prof. Jensen
There is no file called that in the related tar.gz file.
Very Best Regards!
-
hjaaj
- Posts: 334
- Joined: 27 Jun 2013, 18:44
- First name(s): Hans Jørgen
- Middle name(s): Aagaard
- Last name(s): Jensen
- Affiliation: Universith of Southern Denmark
- Country: Denmark
Post
by hjaaj » 08 Apr 2019, 08:15
No, the stderr output is usually in your log file from the job.
-
xiongyan21
- Posts: 184
- Joined: 24 Sep 2014, 08:36
- First name(s): yan
- Last name(s): xiong
- Affiliation: CENTRAL CHINA NORMAL UNIVERSITY
- Country: China
Post
by xiongyan21 » 08 Apr 2019, 12:57
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!
Who is online
Users browsing this forum: No registered users and 4 guests