Porting Finite Element Programs to Unix
kokody2 at hammer.me.toronto.edu
kokody2 at hammer.me.toronto.edu
Mon Jun 6 14:10:25 AEST 1988
In article <15589 at brl-adm.ARPA>, Adam Lewis asks:
> What experiences have people on the list had in porting Fin-
> ite Element Analysis programs to Unix? I'm interested in
> hearing what programs have ported, what kind of compiler was
> used, and what were some of the problems that occured in the
> porting process. Here at CECA we are in the process of
> porting a set of FEA programs and are wondering what traps
> we should watch out for. If anyone is interested in the
> stuff that we're doing please contact me.
I had the interesting experience of porting ADINA
Engineering's Inc. ADINA (Automatic Dynamic Incremental
Nonlinear Analysis) Finite Element Analysis Program to UNIX
at our site. The solution is relatively simple after the
fact, but had taken much time and effort considering I had a
total of 5 Megabytes of source code with no comment cards,
no documentation on program structure and no help from ADINA
Enginerring Inc since we were under a University License for
the code.
The program was version 1984 of ADINA-IN, ADINA, ADINAT and
ADINA-PLOT, where ADINA-IN was the pre-processor, ADINA the
main finite element program, ADINAT the thermal option of
ADINA and ADINA-PLOT was the post-processor. The original
code was written for IBM mainframes and CDC mainframes. It
appears that this code is the easiest to convert to a UNIX
based system since more standard coding was used. VMS for-
tran I understand is quite more difficult to convert due to
variations away from the standard. I would recommend obtain-
ing a IBM or CDC version of the code. I was informed that
MIPS was coming out with a VMS option on the compiler that
would allow running of the VMS code on a UNIX machine.
Modifications included such items as writing in the code
such things as file I/O maintenance with regards to opening
and closing files which had been previously taken care of in
batch files. Another area of modification was the replace-
ment of the time functions with the unix time function
"etime" which measures elapsed time. Using the unix time
functions resulted in the modification of the format state-
ments to give proper elapsed time values.
Error handling routines are no problem as long as they fol-
low the ANSI fortran standards. The IBM error handling calls
where commented out and ignored. From all the given system
verification examples given, the commenting out of these
error handling calls seemed to have no effect on the accu-
racy of the answers. ( I am refering to the ERRSET subrou-
tines on the IBM system).
In regards to file i/o I encountered problems with the max-
imum number of files that could be open at any one time
varied from system to system. On the MIPS M/1000 using a
version 1.21 compiler/linker I was limited to 17 files. I
was informed from MIPS that quirk has been corrected on the
1.31 version where 64 files could be opened simultaneously.
Another area of concern was the creation of Makefiles. I had
to vary the Makefiles from a SUN UNIX 3.4 System to a MIPS
UMIPS-BSD System due to system/compiler dependencies and the
way the system interpreted Makefiles.
In regards to fortran compilers on UNIX systems I have found
variance in performance and options. The MIPS UMIPS-BSD for-
tran compiler has 3 levels of Optimization. The second level
(O2) seemed to give the least problems in regards to compil-
ing and linking and was quite helpful in providing sugges-
tions to which options to use. The Sun UNIX 3.4 compiler
seemed to have problems with the Optimizer. The graphics
code could not be optimized at all. The numerical analysis
code would compile properly but give many wrong numerical
answers in the final output. So only the ffpa (fast floating
point accelerator) option was used which enhanced the com-
puting time on the SUN 3/180's.
Another area of concern was the graphical output. The ADINA
series of programs depended on calcomp and plot-10 graphics
drivers. The plot-10 routines where unavailable on our site
so they had to be commented out. The calcomp routines where
handled by a calcomp emulator using Peripheral Vision Incor-
porated DI3000 graphics routines. This was fine for output
to a screen via batch mode and to a plotter. A very helpful
program was used to convert the HPGL (Hewlett Packard Graph-
ics Language) to PS (PostScript format) for our Apple Laser-
writer. This program was posted to the net in
comp.sources.unix approximately 6 months ago by D. McCormick
<damc at natmlab or damc at nifty>. To accomodate these programs
(hpgl2ps and dxy2ps), one had to modify the output size of
the graphics output so as to fit the entire drawing onto the
8.5x11 inch laser printouts. Depending on how your calcomp
emulators work, one might have to change the standard output
from unit 6 to another unit number so as not to intefere
with the graphics output stream.
There are many little details but they mostly relate to how
the system interfaces with the fortran. The manuals of your
UNIX system will probably have manuals in describing how
your fortran compiler varies with the norm/standard and that
is half the battle for converting the code for use on a UNIX
system.
In regards to ADINA and UNIX, a detailed report is being
prepared to be sent to ADINA ENGINEERING INC on installation
of the ADINA series of programs on the MIPS M/1000 Computer
and the SUN 3/180S Computer in July of this year.
I hope this has helped. You may contact me for more specif-
ics.
Gerry Kokodyniak
================================================================================
--
Gerry Kokodyniak, Ph.D. Student, Dept. of Mechanical Engineering, U. of Toronto
Structural Integrity Fatigue and Fracture Research Laboratory (416) 978-6853
USENET: kokody2 at me.utoronto.edu BITNET: kokody2 at ME.UTORONTO
UUCP: {linus,ihpn4,allegra,decvax,floyd}!utcsri!me!kokody2
More information about the Comp.unix.wizards
mailing list