kokody2@hammer.me.toronto.edu () (06/06/88)
In article <15589@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@natmlab or damc@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@me.utoronto.edu BITNET: kokody2@ME.UTORONTO UUCP: {linus,ihpn4,allegra,decvax,floyd}!utcsri!me!kokody2