<div dir="ltr"><div>From $COLUMBUS/docs/fulldocs/sifs.txt:<br>info(6) contains information on the format of the packed integral labels read from the header in the integral file. <br>0 = 8 bits/label. 1 = 10 bits/label<br></div><div>ifmt is the format of the packed integral labels in the buffer.<br></div><div><br></div><div>Systems with basis functions >256 require >8 bits to encode a basis function label.<br></div><div>It's
 essential a consistency check to ensure you are assigning integrals the
 appropriate basis function labels. This is at least my understanding.<br><br></div>Best<div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div><br>Christopher L Malbon<br>Yarkony Group<br></div>Department of Chemistry<br></div>The Johns Hopkins University<br><a href="mailto:cmalbon1@jhu.edu" target="_blank">cmalbon1@jhu.edu</a><br></div></div></div>
<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Christopher Malbon</b> <span dir="ltr"><<a href="mailto:clmalbon@gmail.com">clmalbon@gmail.com</a>></span><br>Date: Wed, Jul 20, 2016 at 3:28 PM<br>Subject: Re: [Columbus] mcscf.x MO integral read error<br>To: Scott Brozell <<a href="mailto:srb@osc.edu">srb@osc.edu</a>>, Christopher Malbon <<a href="mailto:clmalbon@gmail.com">clmalbon@gmail.com</a>>, <a href="mailto:columbus@osc.edu">columbus@osc.edu</a><br><br><br><div dir="ltr"><div>From $COLUMBUS/docs/fulldocs/sifs.txt:<br>info(6) contains information on the format of the packed integral labels read from the header in the integral file. <br>0 = 8 bits/label. 1 = 10 bits/label<br></div><div>ifmt is the format of the packed integral labels in the buffer.<br></div><div><br></div><div>Systems with basis functions >256 require >8 bits to encode a basis function label.<br></div><div>It's essential a consistency check to ensure you are assigning integrals the appropriate basis function labels. This is at least my understanding.<br><br></div><div>Best<br></div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div><br>Christopher L Malbon<br>Yarkony Group<br></div>Department of Chemistry<br></div>The Johns Hopkins University<br><a href="mailto:cmalbon1@jhu.edu" target="_blank">cmalbon1@jhu.edu</a><br></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">On Wed, Jul 20, 2016 at 2:24 PM, Scott Brozell <span dir="ltr"><<a href="mailto:srb@osc.edu" target="_blank">srb@osc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
The error message is new code in file colib8 subroutine sifd1 of<br>
columbus version 7 that is not in older columbus versions:<br>
<br>
      call ulab16( buffer(1), unpack, 4 )<br>
      num    = unpack(1)<br>
      lab1   = unpack(2)<br>
      last   = mod(unpack(4),         4)<br>
      ifmt   = mod(unpack(4)/2**2,    8)<br>
      itypeb = mod(unpack(3),      1024)<br>
      itypea = mod(unpack(3)/2**10,   8)<br>
      ibvtyp = mod(unpack(3)/2**13,   8)<br>
c<br>
c     ifmt is now double checked<br>
c<br>
       if (<a href="http://ifmt.ne.info" rel="noreferrer" target="_blank">ifmt.ne.info</a>(6)) then<br>
        call bummer(' sifd1: <a href="http://ifmt.ne.info" rel="noreferrer" target="_blank">ifmt.ne.info</a>(6)',0,2)<br>
       endif<br>
<br>
The comment does not indicate why this check is useful.  Perhaps the<br>
author of the new code can describe its purpose.<br>
<span><font color="#888888"><br>
scott<br>
</font></span><div><div><br>
On Tue, Jul 19, 2016 at 05:16:47PM -0400, Christopher Malbon wrote:<br>
> mcscf.x routine fails with the following error message:<br>
> end of hernew<br>
>  IGNORING BNDCHK<br>
> *** End of DALTON calculation ***<br>
> end of mcdrt<br>
> end of mcuft<br>
>  bummer (fatal): sifd1: <a href="http://ifmt.ne.info" rel="noreferrer" target="_blank">ifmt.ne.info</a>(6)0<br>
> bummer<br>
><br>
> This bummer error is called during the read of the integral records after<br>
> ulab16 unpacks the buffer.<br>
><br>
> I am using the Col7.0_2015_01_15 release, building from source.<br>
> I am using the cray intel fortran wrappers on the NERSC cori machine.<br>
> I had to change the cpp flags omitting the -C option. (In gcc 4.8.x, cpp -C<br>
> includes the header file stdc-predef.h which prints the GNU license at the<br>
> top of each preprocessed file commented C-style, which fortran compilers do<br>
> not handle.) Other than this change, no other changes were made - with the<br>
> exception of 'ftn' and 'cc' for 'ifort' and 'icc', respectively.<br>
><br>
> I am installing using machine.cfg/linux64.ifc.byterecl.<br>
</div></div></blockquote></div><br></div></div></div>
</div><br></div>