Compiling DIF3D on the PC

Note that these instructions are fairly old and may not refer to modern 64-bit operating systems. Moving to 64-bit memory addresses inherently broke how older computer codes did ad-hoc memory allocation. To run the older codes, you may have to revert to 32-bin systems, or upgrade to DIF3D 11.

DIF3D is a computer program to solve the neutron diffusion equation. The code is developed by Argonne National Laboratory. The program abstract can be viewed at DIF3D

The code can be obtained from the Radiation Safety Information Computation Center (RSICC). Request code package C649: DIF3D8-VARIANT8.

DIF3D is written mainly in Fortran with a few auxilary C routines. The code is distributed for use on the SUN and IBM workstations. This document shows how it can be compiled on a PC using the G95 Fortran compiler or the Lahey Fortran compiler.

These changes should also apply to other compilers and to Fortran compilers on the Linux operating system. (The one exception is that I could not easily get the code to work with the CVF compiler.)

With the following changes, the code successfully ran all of the installation test cases with either the G95 or Lahey Fortran compilers.

G95 Fortran Compiler Information

DIF3D8 can be compiled on the PC using the G95 and GCC compilers. I used the gcc compiler that came with the CYGWIN package and the G95 Fortran compiler that I downloaded and installed separately.

The exact compiler versions that I used are:

$ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexec dir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --wi thout-included-gettext --enable-libgcj --with-system-zlib --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enabl e-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-registry Thread model: posix gcc version 3.3.3 (cygwin special)

$ g95 -v Reading specs from /usr/local/bin/../lib/gcc-lib/i686-pc-cygwin/4.0.2//specs Reading specs from /usr/local/lib/gcc-lib/i686-pc-cygwin/4.0.2/specs Target: Configured with: /src/G95/gcc/configure --enable-languages=c --disable-nls Thread model: single gcc version 4.0.2 (g95!) Nov 12 2005

The Fortran routines were compiled with the following options:

g95 -O -ftrace=full -fsloppy-char -Wno=155 -Wline-truncation -Wunused-label
  -Wunused-vars -Wunset-vars

The C routines were compiled with the default options.

Lahey Fortran Compiler Information

In addition to G95, I also compiled the code with the Lahey compiler for Windows.

I used the following version of the Lahey compiler:

$ lf95 -version
Lahey/Fujitsu Fortran 95 Compiler Release 7.10.02

Note that this is not the most current version of the Lahey compiler. I have not upgraded in a while.

The Lahey compiler does not include a C compiler, so the code was modified to remove the C routines. These changes are listed below in the second set of code changes.

First Set of Code Changes

These are the mandatory code changes that I had to make to get the code to compile and run the sample problems. Whenever possible, I always tried to change the code to use standard Fortran syntax.

File error.f line 154
Comment out the call to ABORT. A STOP occurs about 6 lines down.

File lunref.f line 270
Commented out the line with "FILEOPT='EOF' and uncommented out the line containing "POSITION='APPEND'. Note that the POSITION=APPEND is now part of the Fortran standard.

File dif3d.f line 93
Removed the reference to the external VSSTOU. This is never used and causes a compiler error.

File dred.f line 492
Change "DDNAME(NREF)(:LNBLNK(DDNAME(NREF)))" to "TRIM(DDNAME(NREF))".
LNBLNK is a common language extension that is not supported in g95. (This change is not nessary for the Lahey compiler).

Do not include the files "prepl1.f" or "preplt.f".
These are plotting routines that require an external plotting package. Dummy routines are provided in other files.

Do not include the file "etime.c" or "getpid.c".
These functions are supported extensions to most Fortran compilers and the external C routines are not necessary.
(Note that a standard Fortran solution would use CPU_TIME instead of ETIME).

File bcdinp.f line 108
Change clear statement (call to INTSET) to be size 100 instead of NUMCRD. Alternatively, the constant NUMCRD should be increased from 11 to at least 12. With the original code, ICARD(12) was used but was never initialized and was being set to a very large value with the g95 compiler. The error caused a read past end-of-record in routine space.f.

File fgeods.f line 296 and 608 (two changes)
In the following lines, change the 8 to a 7:

!!   BLK(LFREC1+I2)=BLK(LFREC1+8)  ! original line
     BLK(LFREC1+I2)=BLK(LFREC1+7)  ! change 8 to 7 to fix null characters

This line occurs in two places, on line 296 and line 608. This fix will remove the NULL characters from being inserted in the file identifiers.

Second Set of Code Changes

These changes were made to remove the ".c" code and additional changes for the Lahey compiler. These changes are optional for the G95 compiler, but are required for the Lahey compiler.

File timer.f line 352
Comment out the line below marked with two exclamation characters.

          T(2)=DEF2
    CANL-IBM
    C     T(2)=.01*TLEFT(DUMMY)
    CANL-IBM
    CUNX
    !!    T(2)=.01*TLEFT()   ! remove for PC
    CUNX

If you comment out the line above, the value of T(2) will be set to DEF2 (a large number) and the program will run.

TLEFTC is an out-dated concept that allowed the user to specify the maximum run time that the program can use. This was to prevent run-away programs and run-away costs when users were charged by the minute on mainframes.

File timer.f line 722
Remove the entire subroutine TLEFT. This is no longer needed with the changes above.

    !!    FUNCTION TLEFT()
    !!    DOUBLE PRECISION TLEFTC
    !!    TLEFT=100.*TLEFTC()
    !!    RETURN
    CUNX
    !!    END

File igtlcm.f lines 416 and 417
Change two calls to "MYLCM" to calls to "MALLOC". MALLOC is a common Fortran compiler extension that allows the use of the C MALLOC function to allocate memory.

File igtlcm.f lines 757 and 758
Change two calls to "FREELC" to calls to "FREE". FREE is a common Fortran compiler extension that allows the use of the C FREE function to deallocate memory.

File timer.f call to SDATE
The call to subroutine SDATE returns the date and time in a Unix-style string. The same functionality can be performed with standard Fortran using the DATE_AND_TIME routine. The changes necessary are listed below in a "diff" format:

    Line 166
    <       CHARACTER*26 HTEMP     ! add
    Line 168
    < !!    CHARACTER*36 MONTH(2)  ! remove
    ---
    >       CHARACTER*36 MONTH(2)
    Lines 176,177
    < !!    DATA MONTH/'JanFebMarAprMayJunJulAugSepOctNovDec',   ! remove
    < !!   .           '01 02 03 04 05 06 07 08 09 10 11 12 '/   ! remove
    ---
    >       DATA MONTH/'JanFebMarAprMayJunJulAugSepOctNovDec',
    >      .           '01 02 03 04 05 06 07 08 09 10 11 12 '/
    Lines 447,449
    < !!    CALL SDATE(DATE26)
    < !!    J=INDEX( MONTH(1), DATE26(5:7) )
    < !!    HT=MONTH(2)(J:J+1) // '/' // DATE26(9:10) // '/' // DATE26(23:24)
    <       call date_and_time(date26)
    <       ht=date26(5:6) // '/' // date26(7:8) // '/' // date26(3:4)
    ---
    >       CALL SDATE(DATE26)
    >       J=INDEX( MONTH(1), DATE26(5:7) )
    >       HT=MONTH(2)(J:J+1) // '/' // DATE26(9:10) // '/' // DATE26(23:24)
    Lines 572,573
    < !!    CALL SDATE(DATE26)
    < !!    CALL FLTCHR(T(8),DATE26(12:19),1)
    <       call date_and_time(time=htemp)
    <       date26=htemp(1:2)//':'//htemp(3:4)//':'//htemp(5:6)
    <       call fltchr(t(8),date26,1)
    ---
    >       CALL SDATE(DATE26)
    >       CALL FLTCHR(T(8),DATE26(12:19),1)
    Lines 605,606
    < !!    CALL SDATE(DATE26)
    < !!    CALL FLTCHR(T(10),DATE26(12:19),1)
    <       call date_and_time(time=htemp)
    <       date26=htemp(1:2)//':'//htemp(3:4)//':'//htemp(5:6)
    <       call fltchr(t(10),date26,1)
    ---
    >       CALL SDATE(DATE26)
    >       CALL FLTCHR(T(10),DATE26(12:19),1)

File error and many others
Unfortunately, the subroutine ERROR used in DIF3D conflicts with the internal subroutine ERROR in the Lahey compiler. To get around this, SUBROUTINE ERROR was changed to SUBROUTINE D3D_ERROR and all calls were changed appropriately. These calls occur in many places. (This change is not necessary for the G95 compiler).

Test Cases

The 10 installation test cases were run with the G95 and Lahey compilers and the results agreed (within reason) to the SUN output files provided.

Note that the Lahey compiler automatically interprets the control characters in the first column of the output. This makes comparisons to the SUN output difficult. I believe the new Lahey compilers fixed this...

ENDIAN Problems

If you are only running cases on the PC, you don't have to worry about BIG_ENDIAN and LITTLE_ENDIAN problems. However, if you are transferring binary files (e.g. ISOTXS files) to/from a Unix workstation, you need to be aware of ENDIAN differences between the platforms. More to come

You can set the G95 compiler to use BIG_ENDIAN at runtime by setting the environment variable G95_ENDIAN=BIG. (Remember to EXPORT the variable if necessary!)

Was this document useful? Please let me know at owner@corephysics.com

Original File created: June 16, 2006
Updated: Feb 16, 2008 to include information on the Lahey compiler