Molcas Forum

wingsofephemera

Member

Registered: 2019-10-11

Posts: 10

Structure of ONEINT file

Hello everyone,

Thanks for reading this thread.
I am new to the OPENMOLCAS development. Recently I've been dealing with the one electron integral storage file ONEINT, could someone explain to me what is the general structure of this binary file, perhaps including the one electron property integrals? Any hints would be appreciated, or you can point to me where I can find documentations for this ONEINT, which I struggled to find any.

Thanks again!

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,012

Re: Structure of ONEINT file

I don't think there's any documentation, but maybe the files misc_util/rdone.f and misc_util/wrone.f can help.

wingsofephemera

Member

Registered: 2019-10-11

Posts: 10

Re: Structure of ONEINT file

I don't think there's any documentation, but maybe the files misc_util/rdone.f and misc_util/wrone.f can help.

Thanks for the reply.
I've read those files before, but some of the input parameters do not make a lot of sense to me...
For example,

      Subroutine irdone(rc,Option,InLab,Comp,Data,SymLab)
   15 ************************************************************************
   16 *                                                                      *
   17 *     Purpose: Read data from one-electron integral file               *
   18 *                                                                      *
   19 *     Calling parameters:                                              *
   20 *     rc      : Return code                                            *
   21 *     Option  : Switch to set options                                  *
   22 *     InLab   : Identifier for the data to read                        *
   23 *     Comp    : Composite identifier to select components              *
   24 *     Data    : contains on output the requested data                  *
   25 *     SymLab  : symmetry label of the requested data                   *
   26 *                                                                      *
   27 *     Global data declarations (Include file):                         *
   28 *     Parm    : Table of paramaters                                    *
   29 *     rcParm  : Table of return codes                                  *
   30 *     Switch  : Table of options                                       *
   31 *     Common  : Common block containing ToC                            *
   32 *     Data    : Data definitions                                       *

From this, I assume that the ONEINT file contains all the one electron integrals needed.
InLab is a string that is defined for each one electron operator, like (I'm just guessing) "MAGNETIC" specifies a magnetic operator integral, by using label "MAGNETIC" one can access the particular part of integrals stored in ONEINT.
Data is a RAM work array to read the requested data in the memory.
SymLab is the symmetry label.

The Option and Comp do make sense to me, my guess would be Option is for stream control, things like activating the debug mode and ways of reading data? Comp may be the components of the integrals? But what are those components...

Pls educate me if you can correct or make any of above concepts more clear.

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,012

Re: Structure of ONEINT file

Many operators are vectors or higher-order tensors that have components. For example, the position operator has x, y and z components. I don't know about the Option argument, but I don't think it matters for the file structure.

wingsofephemera

Member

Registered: 2019-10-11

Posts: 10

Re: Structure of ONEINT file

Thanks for answering, so it's like a user defined dimension to specify the components of the particular operator?
Then I assume its length could vary by different operator, which is defined by label.

Ignacio

Administrator

From: Uppsala

Registered: 2015-11-03

Posts: 1,012

Re: Structure of ONEINT file

Right, each operator has a different number of components. I don't know whether that's stored somewhere in the file or it's something the caller routine must know.