Using Salome Meca FEA suite on Linux

[vturbine]

In another thread I began to learn computer based FEA using LISA in Wine on Linux. The purpose was to try to follow WebPilot's tutorial examples for modeling reed valves. I reached a dead-end with LISA because of the limited types of elements available for thin materials. A model of real world reed valves seemed to require too many elements in LISA for comfortable computing on my hardware. A simpler model using shell elements would have been preferable to LISA's brick elements.

One of the things I'm looking for is low cost or free software that can run on limited (32 bit =< 1 gig ram) equipment for modeling these valves. While LISA looks like it is very useful for lots of other purposes, dynamic modeling of thin materials is a specialized use that is not possible in LISA in its present form. LISA was however a very good introduction to computer FEA, with a good manual, and excellent support. Perhaps some day it will be able to model these kinds of shells. Unfortunately the recent switch to DirectX (from ActiveX) may mean it isn't possible to run LISA on Wine in the future, and therefore Linux.

Another fea platform, which unlike LISA, is also native in Linux, suggested by tufty is Code Aster. Code Aster is actually a "solver," which means that geometric modeling and creation of a mesh must be handled separately. Likewise it would need a post processor to display deflected models of the results.

However, Code Aster has been integrated into another free program called Salome Meca. This one includes the geometric modeling, mesh generation, solver and post processing components to yield a complete FEA solution.

Salome Meca itself is part of a larger Linux remastering of 2 Linux distros with a lot of additional software. The latest CAELinux 2009 is built around Ububtu 8.04. Unfortunately it requires a 64 bit processor. 2008 and earlier CAELinux distros are built around PCLinuxOS, and work with 32 bit porocessors. The CAELinux website is here:

http://www.caelinux.com

A Salome Meca binary is also available standalone for use with other Linux distros from the same source, and the 2009 version IS compatible with 32 bit processors. I've downloaded Salome-Meca 2009 from here:

http://www.caelinux.com/CMS/index.php?o ... &Itemid=40

This thread will follow my hopeful progress in trying to solve WebPilot's example reed analyses.

[vturbine]

Well, it has been 3 days since I installed the software, and all of this time has been spent trying to create a simple rectangular 2D mesh (4x8 elements) using Salome in WebPilot's analysis of the 1x2x0.1 cantilevered plate example in the Mode 1/0 thread.

Man, this is like pulling teeth! Data entry in this program suite is painful for new users -- documentation is sparse and scattered all over the place, and the terminology used is arcane. Much of the most useful information is in French -- which Babelfish translates poorly, or not at all. It fails particularly on translating the engineering and programmatic terminology, and the labels in illustrations. These are the very things that a new user actually needs to understand. Nevertheless, I've made progress.

There are new conventions in the GUI to learn as well (like the new arrow button, which isn't a drop down menu or browse gadget, but appears to act something like copy and paste rolled into one in a sort of toggle mode) and the need to frequently change modes between "Geometry" and "Mesh" as well as switch visual interfaces. When the meshing is done, you then need to generate a set of mesh and command files for processing in CodeAster, which is a different module altogether, and fill in more data.

The nodes, edges, wires, surfaces, vectors, and solids must be defined in a complex "explorer" type visual heirarchy, and numerous characteristics for meshing called "algorithms" and "hypotheses" must be selected before meshing can occur. Even a simple rectangular mesh like the one in our problem requires a fairly extensive setup.

The reason for all of these difficulties is that the GUI isn't far removed from the program code in its overall structure. Salome was built to follow code organization, rather than a human user's intuitive requirements. Therefore there is much to learn. I would rate it as a low level program, jargon rich, which just happens to have a 3D display and functions with a mouse.

Other than that it is a far remove from the original GUI philosophy embodied in Smalltalk. As an example, the intent of the original invention of a GUI was to remove the need for "modes" in programs in order to make them easier to learn. Here in Salome we have a return to modes. Each mode acts like a new program (in fact IS a new program in Salome) and so requires that a user recognize the mode he/she is in, and respond with the inputs and conventions peculiar to that mode.

I found LISA to be far easier to learn and enter data into. Too bad it doesn't (yet) do shell elements well. It would be more than adequate for reed valve analysis if it did.

Anyway, back to Salome...I have managed to create the mesh, and now understand the steps needed to do that for simple shapes like the example problem above. I understand the program's GUI operations well enough to get by. Now to apply the mesh to Aster.

I'll be back when I know how........

[tufty]

Ouch.

Sorry, mate. Still, if you're not learning, you're not living, eh?

No way of building your meshes elsewhere (using something like gmsh, maybe) and importing them?

Simon

[vturbine]

Simon, no problem, mate, not your fault!

Bottom line, this is elective, for fun (er, uhh, more or less fun) and the software IS free. Kinda hard to justify complaining under those circumstances!No, I was just trying to describe what it feels like, in case someone else wants to try the same thing. And I hope I can be in a position to help out once I understand and can describe how to get from the start of the maze to the cheese. We really don't need all of the features of a program this complex to model some simple reed valves, and once we know the specific steps to get results, we can always follow that path as a shortcut.

To your second question, yes, we certainly can use other methods of generating a mesh, but the output will have to be in the file formats acceptable to Aster. It turns out that we can also import geometry before meshing, as the Salome component accepts STEP and IGES files. But I bet there might be even a simpler way down the road.

Harking back to the digital dinosaur days, when we and everyone else used to write 4 kilobyte strictly text-on-screen programs in interpreted ROM BASIC that would look like this:

Code: Select all

Computer: What kind of reed valve do you want to model (rectangle, petal, bent rectangle) R, P, or B?
User: R
Computer: Thank you. How thick is it (example:  1-inch, 1-mm)?
User: .006-in
Computer: Great. What's the dimension of the fixed side?
User: .375-in
Computer: Wonderful. What's the dimension of the other side?
User: .75-in
Computer: Most gratifying. I suggest  4 sided shell elements. How many do you want on the fixed side?
User: 4
Computer: Super. How many on the other side?
User: 8
Computer: Cool. That makes 32, total. Steel I assume (Y, N)?
User: Y
Computer: Fabulous. I've got the needed specs for that. Now. how many modes do you want me to get for you?
User: 3
Computer: Wicked decent. I'm contacting my buddy Aster for an answer, be right back...why don't you get a cup of coffee...
(a series of asterisks slowly meanders across the screen showing that the computer is working on it)
Computer: Okay, mate, I've got your answers they are 508 Hz, 1281 Hz and 3572 Hz. Would you like me to print out or file a detailed list of eigenvalues and eigenvectors (P,F,N)
User: N.
Computer: Faaaaascinating. See ya!

I sometimes wonder if we've progressed all that far in the modern computer age, compared to where we started.

[tufty]

Kinda hard to justify complaining under those circumstances!

Not at all. Indeed, poor UI design is the blight of *n*x desktop tools, and is largely the reason I ran away from Linux and back in to the Apple fold in 2000 - OSX might have been slower (and indeed buggier at the time), but it was faster to use compared to the Linux / Apple hardware combo I'd been using before.

These days the only UI level *n*x tools I use are OOo, gimp, and Inkscape - it's like pulling teeth (although OOo has got a load better recently, and I've migrated back to using it instead of NeoOffice, the Java-based OSX port of the OOo codebase). I was given a "slightly broken" netbook recently, and I installed Ubuntu on it for shits 'n' giggles. Not impressed. It seems the major Linux camps (KDE / Gnome / X.org) have spent the last eight years infighting and copying the most useless bits of the Mac and Windows, instead of doing something new and interesting. Still, it's free and fast, and I *could* give a hand if I had the free time, I guess, so whose fault is that?

I sometimes wonder if we've progressed all that far in the modern computer age, compared to where we started.

You're not the only one. Data entry was faster on green-screen mainframe / unix terminals (which never crashed). These days it's "mouse to here, click, type, mouse to here, click, select from dropdown, lather, rinse, repeat" and massively slower overall. But you can have translucent windows and rippling effects on your screen. Go figure.

[vturbine]

If I understood the input file format for Code Aster, and its output, and the triggers needed to run it, I could still code that last semi-joke example in good old non-visual, non object-oriented QBASIC in a few hours. And compile it standalone, too.

If you still had one on your computer, it could run off a floppy, and probably have room for fifty more programs like it.

Well.... maybe if I left the petal valve option for later.


p.s. I worked on the OO team defining OODraw graphic format dialogs and specs for 3.0. I was fed up with the coarse resolution of export formats, and what I saw as years of inaction on that, so put my (lack of) money where my mouth was and volunteered to work on it. I didn't get exactly what I wanted, but compromise is better than frustration.