Spin-free X2C CI failures...

99 views
Skip to first unread message

Wibe de Jong

unread,
Mar 12, 2021, 6:52:43 PM3/12/21
to dirac...@googlegroups.com
Can anyone tell me why I end up with the failure below for the input deck (end of the email)? This works fine for X2C with spin-orbit, but it's a mess to do this without.

 (RTRACTL1) Total CPU (wall) time used :   00:03:23 (   00:03:23)

            Transformation ended Fri Mar 12 09:32:46 2021


* REAFCK: Fock matrix read from file DFFCK1

* Heading :UHp                                               Fri Mar 12 09:26:03 2021

SCR        scr.thr.    Step1    Step2  Coulomb  Exchange   WALL-time

SOfock:LL  1.00D-12    6.09%   76.87%    0.23%   16.30%  13.90900000s

 >>> CPU  time used in SO Fock is  13.91 seconds

 >>> WALL time used in SO Fock is  13.91 seconds



*** ERROR in IREAKRMC ***

Label <IBEIG   > does not exists on unit  50


  Master node : --- SEVERE ERROR, PROGRAM WILL BE ABORTED ---




The molecule is a simple diatomic. I turned off symmetry to simplify my life, as it's unclear from the documentation what is expected for symmetry without SO. I really want to do a COSCI, but the active space seems too large for memory (integrals storage). All I care about at this point is the lowest root.

Input:

**DIRAC

.TITLE

UHp

.WAVE FUNCTION

.ANALYZE

**HAMILTONIAN

.SPINFREE

.X2C

**WAVE FUNCTION

.SCF

.KR CI

*SCF

.CLOSED SHELL

86

.OPEN SHELL

1

6/28

*KRCICALC

.CI PROGRAM

GASCIP

.INACTIVE

 43

.GAS SHELLS

 1

 6 6 / 14

.CIROOTS

1 1

.MAX CI

200

.MXCIVE

36

.NOOCCN

**ANALYZE

.MULPOP

*MULPOP

.VECPOP

40..60

.LABEL

SHELL

**MOLECULE

*BASIS

.DEFAULT

dyall.3zp

*SYMMETRY

.NOSYM

**END OF


Knecht Stefan

unread,
Mar 14, 2021, 4:57:16 PM3/14/21
to dirac...@googlegroups.com
Hi,

spin free KRCI is not implemented properly and it might very well be that the experimental implementation broke at some point in the past as there is no test for it. The “IBEIG” array provides information about the distribution of the orbitals wrt 
boson irreps. I don’t know why it’s missing on the file (DFCOEF, I assume), though...
Please use LUCITA, the spin free “sister” of LUCIAREL instead, see input below. Note that in this case, your DIRAC version needs to be compiled with the “—int64=on” flag. 
Hope, this helps. 

with best regards
Stefan


=== LUCITA input ===

**DIRAC
.TITLE
UHp
.WAVE FUNCTION
.ANALYZE
.4INDEX
**HAMILTONIAN
.SPINFREE
.X2C
**WAVE FUNCTION
.SCF
.LUCITA
*SCF
.CLOSED SHELL
86
.OPEN SHELL
1
6/28
*LUCITA
.TITLE
 BLA
.INIWFC
  OSHSCF
.CITYPE
  GASCI
.NROOTS
 1
.MULTIP
  1
.NACTEL
  6
.GASSHE
 1
  14
 .GASSPC
 1
  6  6
.DENSI
 1
#################################
**MOLTRA
.SCHEME
4
.ACTIVE
87..100
#################################


=== end of LUCITA input ===


--

---------------------------------------------------------------------------
PD Dr. Stefan Knecht
---------------------------------------------------------------------------
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Abteilung SHE Chemie
Planckstr. 1
64291 Darmstadt
Germany

room: SB3 3.163
phone: +49 6159 71 2588
web: http://stefanknecht.xyz
email: s.kn...@gsi.de
---------------------------------------------------------------------------
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de

Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung:
Professor Dr. Paolo Giubellino, Dr. Ulrich Breuer, Jörg Blaurock
Chairman of the GSI Supervisory Board / Vorsitzender des GSI-Aufsichtsrats:
Ministerialdirigent Dr. Volkmar Dietz
---------------------------------------------------------------------------
ETH Zuerich
Laboratory of Physical Chemistry
Vladimir-Prelog-Weg 2
CH-8093 Zuerich
Switzerland
---------------------------------------------------------------------------

Wibe de Jong

unread,
Mar 14, 2021, 11:20:16 PM3/14/21
to dirac...@googlegroups.com
Hi Stefan,

Much thanks for your reply and the proposed solution. I will definitely give it a whirl.

Best wishes,

Bert

--
You received this message because you are subscribed to the Google Groups "dirac-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dirac-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dirac-users/1FA88665-8A31-449B-88B4-C5C60ECE6740%40ethz.ch.

Wibe de Jong

unread,
Mar 24, 2021, 8:03:17 PM3/24/21
to dirac...@googlegroups.com

Not sure what this error message means for LUCITA?!


 Problem in transf_dirac.

 ICT(ISM)/2 for ISM =                    1  is                    14

  NISH_L(ISM) is                     0

  NOCC_L(ISM) is                    14

  NORB_L(ISM) is                    28

Knecht Stefan

unread,
Mar 26, 2021, 6:54:43 PM3/26/21
to <dirac-users@googlegroups.com>
Dear Bert,

looks like LUCITA somehow thinks that there are secondary orbitals outside of your CAS. Admittedly, the error message is cryptic. 
NORB_L(ISM) is defined as sum of NOCC_L(ISM) + NSSH_L(ISM) where  NOCC_L(ISM) is the sum of inactive (NISH_L) + active orbitals per irrep ISM. 
Could you break down the input for UH to some simpler system for testing, or, alternatively post the input files? 
I am not sure why you get the error message as the input looks OK. I haven’t used LUCITA in a while, though. My memory might be a bit rusty when it comes to details of LUCITA. 

with best regards
Stefan

Wibe de Jong

unread,
Mar 26, 2021, 11:44:48 PM3/26/21
to dirac...@googlegroups.com
Dear Stefan,

The input was pretty much what you gave me. Based on the info you gave me in your response, I figured out that the issue was with the MOLTRA block. The input files at the end work...mostly. Dirac is compiled with int64 and a 64 bit openmpi library, but it runs into memory errors in lucita that are not decipherable. This is pretty much the same independent of the memory size and number of procs.

  ** interface to 64-bit integer MPI enabled **


DIRAC serial starts by allocating 268000000 words (   2044.68 MB -      1.997 GB)

 of memory    out of the allowed maximum of 2147483648 words (  16384.00 MB -     16.000 GB)


.

.

.

.

.

.

.

.

.

      Raised  print level for External blocks       =   0


  Memory problem for :

    Level (IL)                     1

    IHOSTL       5682518134182        OKAY       -

 Current task : ADDS   IHOSTL

  NS, NL, NSNLI                    1                    0                    1

   Sorry to say it , but memory is CORRUPTED

   Memory map :

   Identifier    Offset     Pad1 okay Pad2 okay

   ========== ============  ========= =========

    IHOSTL           1        OKAY       -


 =======

  Marks

 =======


  Identifier  Start of free memory

  =================================

   -INI--               5682518134181


  Master node : --- SEVERE ERROR, PROGRAM WILL BE ABORTED ---


 Date and time (Linux) : Fri Mar 26 20:10:23 2021

 *** error in MEMMAN: memory corrupted. ***


 Traceback from this point (memman_+0x1141): 8 frames.


  7   function name:                   memman_+0x1141

  6   function name:                     pamlu_+0x251

  5   function name:                  pamlucita_+0x5a

  4   function name:                    pampsi_+0x4b7

  3   function name:                        +0x12e02e

  2   function name:                     dirac_+0x1aa

  1   function name:                        +0x129ff8

  0   function name:                        main+0x1f


DIRAC pam run in /home/wadejong/DIRAC-19.0-New/UH/X2C-SF-Symm8


 

uh.inp

**DIRAC

.TITLE

UHp

.WAVE FUNCTION

.ANALYZE

.4INDEX

**HAMILTONIAN

.SPINFREE

.X2C

**WAVE FUNCTION

.SCF

.LUCITA

*SCF

.CLOSED SHELL

86

.OPEN SHELL

1

6/28

*LUCITA

.INIWFC

  OSHSCF

.CITYPE

  GASCI

.NROOTS

 1

.MULTIP

  5

.NACTEL

  6

.GASSHE

 1

  14

.GASSPC

 1

  6  6

.DENSI

 1

**MOLTRA

.SCHEME

4

.ACTIVE

44..57

.CORE

1..43

**ANALYZE

.MULPOP

*MULPOP

.VECPOP

40..60

.LABEL

SHELL

**MOLECULE

*BASIS

.DEFAULT

dyall.3zp

*SYMMETRY

.NOSYM

**END OF


uh.xyz

2

UH molecule

U 0 0 0 

H 0 0 1.950


To view this discussion on the web visit https://groups.google.com/d/msgid/dirac-users/08D9687D-68D4-48D4-B0D8-62B4C21F969B%40ethz.ch.

Peterson, Kirk

unread,
Mar 27, 2021, 11:14:58 AM3/27/21
to dirac...@googlegroups.com

Dear Bert,

 

I have these exact same memory errors in Lucita if I use Dirac19 that's been built with the gnu compilers.  My only workaround was to revert back to Dirac17.

 

best,

 

-Kirk

Bert de Jong

unread,
Mar 27, 2021, 11:25:17 AM3/27/21
to dirac...@googlegroups.com
Thanks Kirk, let me try that.

Bert

On Mar 27, 2021, at 8:14 AM, Peterson, Kirk <kipe...@wsu.edu> wrote:



Wibe de Jong

unread,
Mar 27, 2021, 5:55:16 PM3/27/21
to dirac...@googlegroups.com
Ha, but getting DIRAC 17 is another challenge.

Bert

Peterson, Kirk

unread,
Mar 28, 2021, 12:55:43 AM3/28/21
to dirac...@googlegroups.com

Fortunately I had it from a previous build.  I could put it on dropbox for you if you're still stuck.

Bert de Jong

unread,
Mar 28, 2021, 1:01:14 AM3/28/21
to dirac...@googlegroups.com
Yeah, still stuck. Tried to get access, but it doesn’t look like the older versions are accessible anymore.


On Mar 27, 2021, at 9:55 PM, Peterson, Kirk <kipe...@wsu.edu> wrote:



Wibe de Jong

unread,
Mar 29, 2021, 1:39:08 AM3/29/21
to dirac...@googlegroups.com
Thanks Kirk for getting me access to the Dirac-17 version. Compiling with Gnu 9.3 compilers and openmpi I get the same errors on the input deck posted earlier in this chain. Either it is the input that has an issue or compiling Dirac creates a problem that is not very obvious. My bet is on the former, but I'm not sure.

Bert

Peterson, Kirk

unread,
Aug 27, 2021, 8:32:03 PM8/27/21
to dirac...@googlegroups.com

Hi all,

 

this is resurrecting a previous thread (under a new subject title), but now for Dirac21.  Does anyone have a functioning version of Lucita? Both lucita_large and lucita_short test jobs give me a familiar error:

 

  Identifier  Start of free memory

  =================================

   -INI--               5885249840561

 

  Master node : --- SEVERE ERROR, PROGRAM WILL BE ABORTED ---

 

Date and time (Linux) : Fri Aug 27 17:26:20 2021

*** error in MEMMAN: memory corrupted. ***

 

I've had this issue since moving to Dirac19 and got around it by using an old build of Dirac17.  Unfortunately I accidentally deleted that build the other day doing some housekeeping....

 

For Dirac21, I'm compiling a 64-bit integer version with Gnu 10.2.1 and OpenMPI 4.0.2 .  Perhaps it's just a matter of building a i*4 version?

 

thanks in advance,

 

-Kirk

Peterson, Kirk

unread,
Aug 31, 2021, 4:49:49 PM8/31/21
to dirac...@googlegroups.com

Dear Dirac experts,

 

so I built a integer*4 version of Dirac17 to see if this would give me a functioning Lucita code.  Now when I run the lucita_short test job I get:

 

Information about the restricted kinetic balance scheme:

* Default RKB projection:

   1: Pre-projection in scalar basis

   2: Removal of unphysical solutions (via diagonalization of free particle Hamiltonian)

controlled stop: only int64

 

FATAL ERROR in test_lucita_wrk_space_offset: memory offset (dynamic memory - static memory) is too big for i*4

K_OFFSET and KBASE_LUCITA:       5889449601119          1049438303

 

I don't think it's actually a memory issue - here is the top of the output:

 

  ** interface to 32-bit integer MPI enabled **

 

DIRAC serial starts by allocating 100000000 words (    762.94 MB -  0.745 GB)

of memory    out of the allowed maximum of 200000000 words (   1525.88 MB -  1.490 GB)

 

 

Can anyone shed some light on this?

 

regards,  -Kirk

 

From: "'Peterson, Kirk' via dirac-users" <dirac...@googlegroups.com>


Reply-To: "dirac...@googlegroups.com" <dirac...@googlegroups.com>
Date: Friday, August 27, 2021 at 5:32 PM
To: "dirac...@googlegroups.com" <dirac...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "dirac-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dirac-users...@googlegroups.com.

Hans Jørgen Aagaard Jensen

unread,
Sep 1, 2021, 4:06:41 AM9/1/21
to dirac...@googlegroups.com

Dear Kirk,

 

On many current computers you need int64 to run LUCITA and LUCIAREL (incl. when called from KRCI), even for small tests.  The reason is that in the original pre-Dirac versions all memory allocations for arrays were from a WORK array in a common block. In order not to have this static common block allocation making a lot of memory not usable for the rest of Dirac, we made an ad hoc solution. We calculated the off-set in memory between the two work arrays, allocated WORK(1) in the common block and added this off-set to all WORK(Ksomething) use in LUCI*. Nowadays this off-set is often bigger than 2**31, the largest number in integer*4, this is why one usually needs int64 to run LUCITA or LUCIAREL.

 

The clean solution would be to rewrite the memory allocation in the LUCITA and LUCIAREL, but that is a lot of work which has so far not been the top priority for any of the developers.

 

Regards, Hans Jørgen.

Peterson, Kirk

unread,
Sep 1, 2021, 10:04:55 AM9/1/21
to dirac...@googlegroups.com

Dear Hans Jørgen,

 

thanks, this makes a lot of sense and explains my current error message for the i*4 version I was trying.  I guess the original question remains. Is it possible to get a functioning Lucita with the gnu compiler suite (with int64 which is my normal build)?

 

best regards,

 

-Kirk

Reply all
Reply to author
Forward
0 new messages