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