Introduction
The codes SIC3359.F, sph3359.f and REDUCE.F simulate the evolution of a galaxy. They are currently being run by using f2c to make C code that is compiled and run a PC with a Linux operating system. The code runs rather slowly. The users are requesting an RCI account.
Two questions are relevant. The first; why convert the codes to C? The second; will the codes run faster on the main frame machines?
2. #Step 2 first attempt at running the code
3. #Linux/UNIX
4. #Nersp The code runs slower than on a PC when run interactively.
5. #MVS
Preliminaries
I do my testing using the Fortran Power Station IDE
PowerStation.gif gives full scale version of the above.
This is currently available as Compaq Visual Fortran.
Linux: Etime is not acceptable to f77
#Maxwell Compiles in f77
#Ligo Compiles in f90
#Nersp Etime is not acceptable to f77
Step 1 startup code
I compiled and tried to execute SIC3359.F
This did not work owing to the presence of older files. I wrote the file clean0.bat
del datinm
This file set up for running the code. It is important to note that the dat files
3359COEF.DAT
OMEGA.DAT
SPHINF.DAT
are in the folder with the executable.
-58347.300000286.672000160.73400051.824200-31.687100
13.608700-8.661651
9206.440000-2835.720000-1405.110000-339.817000-22.608300
-57.44900017.680500
-744.4050001111.3900002752.210000263.496000180.842000
1.024570-13.298800
-10.226900139.965000-1613.190000-101.593000-130.417000
29.41170016.760800
22.959300-143.479000431.97800023.67490037.075400
-12.911100-8.162001
-5.46774030.196100-61.831700-3.442040-5.360790
2.3490201.758830
.616975-2.9518504.920860.299742.421990
-.215489-.187857
-.033601.140965-.205992-.014105-.017325
.009875.009799
.000709-.002660.003544.000274.000292
-.000180-.000200
___________________________________________
Stop - Program terminated.
The code sph3359.exe was made both by the IDE above with the name sph and with the bat file csph.bat containing the command
FL32 /Ox /G5 /W0 sph3359.f
The parameter file NBPARM was
test1
1.66
25
1.0
2.0
0.01
0.00000000001
500 This line tells how many steps to take.
2000
2000
0.4
0.31
--------------------Configuration: sph - Win32 Debug--------------------
Compiling Fortran...
D:\RCI\sph3359.f
D:\RCI\sph3359.f(168): warning FOR4265: symbol CTIME referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol F21 referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol F11 referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol FI01 referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol DDAEM1 referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol AEM1 referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol FI referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol ATI1 referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbol ALR referenced but not set
D:\RCI\sph3359.f(168): warning FOR4265: symbolOM referenced but not set
D:\RCI\sph3359.f(498): warning FOR4269: unused dummy argument N1
Linking...
sph.exe - 0 error(s), 11 warning(s)
Nobody likes to hear this, but warnings about variables
referenced, but not set are usually serious.
The good news is the code runs in windows in full debug
mode at about 5-10 sec/ step on a 1 gigahertz machine with 512 M of RAM. With full optimization, the code requires
between 3 and 5 sec per step.
D:\RCI>sph
step1 completed1.493558E-04129938.200000
step2 completed2.987100E-04129938.200000
step3 completed4.480741E-04129938.200000
step4 completed5.974595E-04129938.200000
Start
time
Linux/UNIX
On Linux
f77 sic3359.f
sic3359.f: In program `sic3359':
sic3359.f:29:
idum=-etime(dum)
^
Reference to
intrinsic `ETIME' at (^) invalid -- one or more arguments
have incorrect type
The problem with etime is potentially serious
The etime call
comes with
idum=-etime(dum)
dum is never
defined which makes it real*4 by default.
..\Class02\UNIX FORTRAN
Timing.htm gives the form expected by g77.
It needs a dum(2) array
This means that the startup routine may be putting the dum(2). Information into the memory address of a different variable or even into a part of the program. This is usually hamless … but. The definition for ETIME given by the Power Station is almost identical to this. I changed the dimension and reran the startup code with no detectable differences at this point.
Correcting the ETIME gave a code that
worked, but not one that worked correctly.
The file dattinm produced by
Linux had too many 0’s and a host of NAN’s. I believe that
the problem could be g77’s poor implementation of character reads ../Class02/LSUnix.htm#_Reading_variable_length_character_s. I zipped the file datinm produced by the Power Station and placed it
on the Linux system.
I then compiled f77 sph3359. I was able to run this. Each step required about 15 seconds which is approximately three times the time of the Power Station. The Power Station, however, is on a Gigahertz machine, while the Linux is on a 360 Megahertz machine.
maxwell[~/rci] f77 sic3359.f
sic3359.f:
Ligo
ligo[~/rci] f77 sic3359.f
sic3359.f:
MAIN sic3359:
subr1:
gasdev:
ran1:
ligo[~/rci] f90 sic3359.f
ligo[~/rci]
Nersp
rci003@spnode43$ f77 sic3359.f
** sic3359 === End of Compilation 1 ===
** subr1 === End of Compilation 2 ===
** gasdev === End of Compilation 3 ===
** ran1 === End of Compilation 4 ===
1501-510 Compilation successful for file sic3359.f.
ld: 0711-317 ERROR: Undefined symbol: .etime
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
rci003@spnode43$
The f77
sph3350.f command produced a host of errors complaining
"sph3359.f", line 541.25: 1515-018 (S) Incorrect character found in source
at line 541 in column 25. Hexadecimal value of character is 0D.
This indicates that
the nersp f77 definition of hexadecimal is slightly different than that of
g77. I used
g77 sph3350
This produced a workable code. As before I imported the power station datinm
file
The speed was ~20 sec / step. This is partly owing to the fact that g77 does not produce the fastest code for the nersp. With optimization and other fixes, this can undoubtedly be lowered to ~3 to 10 seconds per step. This is disappointing. The evidence indicates that the nersp is much slower than a modern PC.
MVS
The submission method is given in rciftp.html. The job would be controlled by JCL. There would be three steps, the setup, the running and the final evaluation. The easiest way to use MVS is to have all file definitions in the JCL. This will require some minor code modification. The biggest problem is the binary file for the output data. This can easily be made a permanent data set. Then the plot codes and such can be run as separate short jobs. In fact by signing on to TSO they can be run interactively. The overhead is about a month of code modification and gaining familiarity with what is commonly considered to be an obsolete way of doing things. My experience with the two systems leads me to believe that the final timing will be ~1-3 seconds per step. Thus a gain of a factor of 3 over the use of a PC is possible while it is also possible that the final code will be slower than that on a PC.
Conclusions/Suggestions
- The code appears to work under the Fortran Power Station. This implies the Compaq Visual Fortran will compile and run the code on almost any platform with almost no modifications.
- The reason the code has been run with f2c followed by C compilation is probably the character reads in the setup code #fortran_problems. These should be tracked down. Continuing to use f2c on this code only is the fastest way to produce incorrect results.
- The code ran on a laptop with only 32 Meg of Ram with no detectable slowdown beyond the CPU ratio. This implies that there is no need for extra RAM to run the code. – option 1 is to simply request funds for a cheap computer ~$1000 and a good FORTRAN compiler ~1000 and let it run. Least work and aggravation – most opportunity for good research.
- When compiled under Linux, there was a complaint about the form of one of the system calls. #Efind This is a potential problem in that a random word may be overwritten without notice. It is the better compilers that refused to allow this to run.
- With a bit of work the code can be made to run on the MVS part of the NERDC rciftp.html -- you will need to learn some JCL for this. The beauty of this method is that the job can be submitted as a single JCL stream that will run without bothering anyone at all for a week or so at a time. The drawback is that OPENS will need to be replaced with JCL lines that open the files external to the code. This requires a bit of searching through the code for all of these lines. – I also wonder what the reduce step returns. This method will simply return a file that you download from MVS. This allows you to submit the job and do something else while it runs. This has the least system overhead for the staff. A drawback is that you will need to learn an almost completely obsolete way of doing fortran.
- Alternatively, the code can be made to work on the NERSP system. Here it will run almost identical to what you are used to. I suspect that there will need to be some adjustments along the lines of the LINUX external function error before it will run in a straightforward manner. The nersp will run the code in the same way that you do now. It appears to be even slower than your corrent methd. Your code is small and should not seriously impact the system. Submission to batch (which is essential for running the sph code) from the nersp has never worked well and is constantly changing. I will be happy to help try to keep it working, but it will delay you a bit.