Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations cowski on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!
Commerical FEA Software Code 2
- Thread starter ahad29
- Start date
-
1
- #2
Speed and size.
I routinely run half million node models of tet meshed solids through Abaqus, Lusas and Nastran on PC's with run times of less than an hour for linear analyses and models a quarter of this size non-linearily. I doubt very much whether any of the above mentioned will even come remotely close to doing this.
I routinely run half million node models of tet meshed solids through Abaqus, Lusas and Nastran on PC's with run times of less than an hour for linear analyses and models a quarter of this size non-linearily. I doubt very much whether any of the above mentioned will even come remotely close to doing this.
-
1
- #3
I think you're absolutely right John. I wrote a small FE code in Matlab some years ago now as a benchmark against a very simple 1D ABAQUS FE run. The ABAQUS model took literally fractions of a second to execute, while the Matlab model took several seconds. I think the ratio was something like 1:10 or something of that order. The Matlab run also gobbled up lots more memory I seem to remember compared to the ABAQUS model. I wouldn't even attempt to write anything like that in Matlab again (but don't get me wrong, I'm a huge fan of that software's capabilities). I'd go with ftn77/90 or a flavour of the C code to do this personally.
------------
See faq569-1083 for details on how to make best use of Eng-Tips.com
------------
See faq569-1083 for details on how to make best use of Eng-Tips.com
Hi all,
Good point, Johnhors and Drej! In effect, the "lower-level" the language, the faster the routine: if one was able to program in Assembly with the Intel datasheet of processor's registries and built-in functions, for sure his "home-made" code for FE solving would be as fast, if not faster, as the main commercial FE packages.
Programming in Matlab or Mathematica means that your program must first pass through the MatXXXX interpreter, a higher-level one:
Processor -> HardwareAbstractionLayer -> (OperatingSystem) can be bypassed -> Interpreter -> ProgramShell -> ProgramInterpreter -> Routine.
If one knows exactly how to do (I don't !!!), he can operate at OS' level, or even below the HAL.
Otherwise, his routine would be enormously slower.
Bye!
Good point, Johnhors and Drej! In effect, the "lower-level" the language, the faster the routine: if one was able to program in Assembly with the Intel datasheet of processor's registries and built-in functions, for sure his "home-made" code for FE solving would be as fast, if not faster, as the main commercial FE packages.
Programming in Matlab or Mathematica means that your program must first pass through the MatXXXX interpreter, a higher-level one:
Processor -> HardwareAbstractionLayer -> (OperatingSystem) can be bypassed -> Interpreter -> ProgramShell -> ProgramInterpreter -> Routine.
If one knows exactly how to do (I don't !!!), he can operate at OS' level, or even below the HAL.
Otherwise, his routine would be enormously slower.
Bye!
To answer to original post it is just as EricZhao stated. FEMLAB is written as an interface on MATLAB. I have no firsthand experience but have heard that it is very good when you want to simulate "odd" things or just want to bew able to poke around with the code to see "what happens". Like I said, I've never tried it but thats what I've heard.
As for the second statement, writing your own code in assembler and beeing faster than the commercial one. I'm not so sure about that. I've heard that in some commercial codes the numbercrunching the routines are programmed in assembler. Maybe somebody knows more as to "who and how" but I imagine that doing for example the matrix decomposition in assembler would be an advantage.
Regards
Thomas
As for the second statement, writing your own code in assembler and beeing faster than the commercial one. I'm not so sure about that. I've heard that in some commercial codes the numbercrunching the routines are programmed in assembler. Maybe somebody knows more as to "who and how" but I imagine that doing for example the matrix decomposition in assembler would be an advantage.
Regards
Thomas
As far as I know , Matlab comes with some C++ powerful numerical libraries and a C++ compiler, which I think could be useful for fast FEA related programming.
I agree that programming FEA by using front end Matlab, Mathematica etc. commands will be probably easier but the code will be much slower.
About FEMLAB , it probably takes advantage of some underlying compiled MATLAB numerical libraries than using interpreted front end commands.
By the way I always have had this question:
why a non object-oriented FORTRAN language (which I personally consider being obsolete and rather rigid) is preferred to an object-oriented language (e.g. C++) by the FEA software developers ???
I agree that programming FEA by using front end Matlab, Mathematica etc. commands will be probably easier but the code will be much slower.
About FEMLAB , it probably takes advantage of some underlying compiled MATLAB numerical libraries than using interpreted front end commands.
By the way I always have had this question:
why a non object-oriented FORTRAN language (which I personally consider being obsolete and rather rigid) is preferred to an object-oriented language (e.g. C++) by the FEA software developers ???
Xerf, "FORTRAN language (which I personally consider being obsolete and rather rigid)"
Wow !
Well what help is an object oriented language in solving FE problems? As for obsolete and rigid, Fortran 95 I find very flexible and easy to program in, especially the memory handling routines. Long gone are the days when arrays had to be sized by the largest problem considered practical, which made small problems also run very slowly. Nowadays a well written Fortran program will solve small problems like greased lightning and solve big problems with efficient use of available memory resources.
The front end gui's for pre and post processing may well be written in C++ or make use of off the shelf libraries like TCL/TK but Fortran can also handle standard windows gui's and OpenGL graphics just as easily as any other language.
Wow !
Well what help is an object oriented language in solving FE problems? As for obsolete and rigid, Fortran 95 I find very flexible and easy to program in, especially the memory handling routines. Long gone are the days when arrays had to be sized by the largest problem considered practical, which made small problems also run very slowly. Nowadays a well written Fortran program will solve small problems like greased lightning and solve big problems with efficient use of available memory resources.
The front end gui's for pre and post processing may well be written in C++ or make use of off the shelf libraries like TCL/TK but Fortran can also handle standard windows gui's and OpenGL graphics just as easily as any other language.
For the kind of numbercruncing that is made in FE software I don't think an objectoriented language will add a lot. Don't get me wrong, there is noting wrong with C++ etc but to rewrite the code from scratch. I don't see the point.
Note that when several of todays big commercial codes were born Fortran was king in that department and to rewrite hundreds of thousands of lines of code today just to get from Fortran to C++. Like I said, I don't se the point.
As for MATLAB, FEMLAB etc. A professor once told me that to test a new algoritm using MATLAB takes perhaps a week of codewriting and a day to run the problem. To do the same thing in Fortran would take a month to write and an hour to run. Of course these are no absolute numbers but the idea is that if you want to write your own code MATLAB might be a good platform. However, if you want to run large reallife problems you might need something else. Don't get me wrong, I like MATLAB but I'm not sure I would run a million dofs problem on it.
Regards
Thomas
Note that when several of todays big commercial codes were born Fortran was king in that department and to rewrite hundreds of thousands of lines of code today just to get from Fortran to C++. Like I said, I don't se the point.
As for MATLAB, FEMLAB etc. A professor once told me that to test a new algoritm using MATLAB takes perhaps a week of codewriting and a day to run the problem. To do the same thing in Fortran would take a month to write and an hour to run. Of course these are no absolute numbers but the idea is that if you want to write your own code MATLAB might be a good platform. However, if you want to run large reallife problems you might need something else. Don't get me wrong, I like MATLAB but I'm not sure I would run a million dofs problem on it.
Regards
Thomas
- Thread starter
- #11
Thank you all. This is what I understood from your comments:
Since Matlab does not interact with the hardware like other low-level languages it takes longer to run the code. And when the dofs involved is large that makes it even more painful. Hope I got it right. Thanks
ahad
Since Matlab does not interact with the hardware like other low-level languages it takes longer to run the code. And when the dofs involved is large that makes it even more painful. Hope I got it right. Thanks
ahad
Johnhors,
don't take me wrong. I don't think FORTRAN code could not do its task as well as any other compiled code...
But..
...I was only thinking from a developer point of view. An object oriented language is much more flexible and allow the developing of more complex, maintainable and easy-to-update code.
don't take me wrong. I don't think FORTRAN code could not do its task as well as any other compiled code...
But..
...I was only thinking from a developer point of view. An object oriented language is much more flexible and allow the developing of more complex, maintainable and easy-to-update code.
- Status
Similar threads
- Question
- Question