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.
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.
I used the following version of the Lahey compiler:
$ lf95 -version Lahey/Fujitsu Fortran 95 Compiler Release 7.10.02Note 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.
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 charactersThis 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.
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 CUNXIf 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).
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...
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 firstname.lastname@example.org
Original File created: June 16, 2006
Updated: Feb 16, 2008 to include information on the Lahey compiler