Compile Dif3d8

From Core Physics Wiki
Jump to: navigation, search

Compiling DIF3D on the PC

Older notes from 2006

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
 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.

   C     T(2)=.01*TLEFT(DUMMY)
   !!    T(2)=.01*TLEFT()   ! remove for PC

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.

   !!    TLEFT=100.*TLEFTC()
   !!    RETURN
   !!    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!)

Original File created: June 16, 2006

Updated: Feb 16, 2008 to include information on the Lahey compiler

Updated: Apr 12, 2014 to convert to Wiki page