Mechanica vs. Algor

[mlarson]

I'm new to the finite element analysis world and have limited myself down to 2 products, Algor and Mechanica. I have read some on the p-method used in Mechanica and the h-method used in Algor. Both products seem nice for their ease of use, since both can be integrated into ProEngineer, which is the CAD tool I'm using. My question is which one is better? The types of things I'm trying to model are bones with muscle around them and do some simple bending. Some articles say Mechanica isn't good with complex features, but I have also read that it is good for that too. I'm an engineer in a small company and do all the design and analysis, but also spend much of my time doing other things.

Thanks, Matt

 

[GBor]

Here are a couple of threads from the Algor forum related to an analysis on an older version of Algor software on a femur.

thread810-126568

thread810-147475

I have the femur model and am confident that Algor software is capable of doing what this poster needs.

I haven't used Mechanica, but I know that it is good software.

Garland

Garland E. Borowski, PE
Borowski Engineering & Analytical Services, Inc.

http://www.borowskiengineering.com

 

[mlarson]

One thing I'm still strugling with is the p-method used in Pro/Mechanica. It converges along lines and raises the polynomail order, but in large elements I still don't know how that would help get fine enough resolution for a good answer.

 

[GBor]

Well, I'm certainly no expert, but p-element convergence allows for up to 9th order polynomials to map the edge of any elements. So, if you imagine that you have a simple line element between two nodes, an h-order element may allow "mid-side" nodes, but that only gives three integration points along the line (one on each end and the mid-side node in the middle). For a p-element with a 9th order integration, you have 9 points along the line, so with a much larger element, you still get the same resolution.

I've primarily used h-method element FEA programs, and with todays computers, the speed is not the issue that it used to be. p-element is excellent for large objects because you can spend much less time meshing the large object and still get the same results. p-element convergence is generally faster depending on the solver.

I'm fond of Algor. I've used it for about 10 years, but it boils down to cost, ease of use, and application. I don't know about the first two in comparison, but I'm confident that Algor can meet your application.

 

[mlarson]

Thanks for the help Gbor. I understand what you're saying on resolution along an element edge, that does sound nice. This is exaggerating in size, but take for example a square element that is sizes 2"x2". You can predict along the element edges quite well with the p-element but what about all the area inside the element? Wouldn't you miss what is happening in the center of that element since p-elements would only compute along the edges? Whereas h-elements are square and you can make them much smaller, so you won't miss that center point.
I have talked to Algor and had a product demonstration and think they make an excellent product. You also sound very happy with them. The major consideration is the price. To get all the options Mechanica has (static, dynamic, thermal) would be twice the price with Algor. But I'm also modeling bones and want good accuracy. That's what I'm wondering if Mechanica has.

 

[Stringmaker]

mlarson,
Before you buy anything make sure that you're comparing apples to apples. Your definition of "dynamics" between Algor and Mechanica may vary. When I think of getting "dynamics" as part of an FEA package, I think of the full suite of vibrational analysis tools. What you are referring to as being Dynamics with Algor may in fact be MES which has the capability of handling fairly complex motion/contact problems which I would guess are a part of your work. Make sure that the Mechanica package which you have been quoted as being half the price of Algor is really half the price and not half of the price for just Linear Static and Thermal. Algor is good software and typically is known as being a very cost competitive package.

Best,
-Brian

 

[GBor]

Have to agree with Brian on this one. I can't imagine Mechanica at half the price giving you near the capability of Algor. To compare to the Mechanica package, you would likely need linear static and dynamic with a vibration level II extender (if they still call it that) and thermal. If you are also getting Event Simulation (MES) from Algor, you are in a very different ballpark than just statics and dynamics.

I have been very happy with Algor. I've had my differences of opinion with them over the years as well, but overall, it has been a great decade.

Garland

 

[ttoole]

Mechanica has a great interface but PTC has done little with it over the years. The solver is limited. I think it is a solid application for designers doing preliminary design work. What is OK about Algor is the FEMPRO preprocessor but I have had some serious accuracy issues with the solver. How did you narrow it down to Algor and Mechanica? I would suggest you consider ANSYS, ABAQUS, and NASTRAN as well. These are very good products and well established. We just switched from Algor and we did not purchase Mechanica.

 

[GBor]

Matt,

Here is the thread where ttoole's concerns were addressed:

thread810-142688

You may want to read it through...

 

[mlarson]

First of all I should say I am looking for a basic linear static package for now but will need the dynamics (vibration included) package down the road. Partly why I didn't look so much at Ansys or Abaqus was their prices are a bit higher and they are a little harder to use for someone like me that won't be using the software every day. My company isn't against spending the money for one of them, but financially we will have to purchase extensions in steps. Algor seems very user-friendly and can run in the ProEngineer interface. I don't know about the others. I have looked at and used the student-edition of Ansys in the past and it wasn't as easy to use. If someone has suggestions on another product they think would be better though that is reasonable priced and a better product I will look into it. What's a good Nastran package, MSC is expensive, is NE any good?

 

[GBor]

NE does have a good product, but Algor's price is tough to beat on a linear, statics package. An alternative might be Calculix. It is actually Freeware and seems to be a bit of an Abaqus clone (calculix acknowledges Abaqus on their website). The pre- and post-processor seems pretty difficult to use, but the processor seems pretty sharp:

http://www.calculix.de

(the Linux version was developed in Germany)

http://www.beconverged.com

(this is an American that adapted the code to windows)

A Brit put together a pretty powerful Pre- and Post-processor that interfaces with Calculix. It isn't perfect, but it is probably half the cost of what you will pay for Algor or NENastran. At the moment, the Calculix interface covers Linear Statics and Natural Frequency calculations, but the full dynamics interface is apparently in development.

http://www.roshaz.com

Roshaz also has a built-in statics processor.

If cost drives you, then Roshaz may be your answer. If ease of use drives you, Algor may be the right path.

My 2 cents

Garland E. Borowski, PE
Borowski Engineering & Analytical Services, Inc.

http://www.borowskiengineering.com

 

[GBor]

Sorry, the windows calculix link should have been:

http://www.bconverged.com/calculix

 

[mlarson]

Thanks for the help Garland, I think you are right on Algor. I want something easy to use so I don't spend a bunch of time trying to figure out the software. I had an Algor WebEx demo and I'm going to get an eval copy from them to try.

 

[mloew]

mlarson,

Please see the FAQ P-Elements (FAQ828-810).


Best regards,

Matthew Ian Loew


Please see FAQ731-376 for tips on how to make the best use of Eng-Tips Fora.

 

[prost]

mlarson:
You made the statement: "Wouldn't you miss what is happening in the center of that element since p-elements would only compute along the edges?" In general this statement is not true--in p-element codes, you can compute engineering data such as stresses, etc. along the edges and in the internal regions, and there is no such intrinsic limitation in the p-element method. Not being familiar with Mechanica, I can only guess that you can also compute internal engr. data with Mechanica, but perhaps you just can't figure out how to get the post processor to do it for you (it happens to the best of us! ). I know internal stresses can be computed with StressCheck, another p-element code, and I computed internal stresses myself in two research quality p-element codes I wrote.

One point about the elements themselves--in isoparametric h-elements, the nodes and the shape functions are tied directly together, so that the shape functions are defined as value of 1.0 at the assigned node, and 0.0 as the shape function passes through all the other nodes. In p-elements, only the corner nodes have shape functions assigned directly to them; the edges do not have nodes, but there are shape functions associated to the edges. In addition, there are shape functions associated with the center region of the elements. If you restrict the polynomial level 'p' to 2 (that is, quadratic), then in principle you can have the same number of degrees of freedom (DOFs) on the p-elements as you do in the h-elements (for 2D quadratic elements, that's 16 or 18 DOFs per each element, no matter the method used, p-element or h-element). However, in the p-element method, you can keep increasing polynomial level of the shape functions to arbitrarily large value--normally you are restricted only by the size and speed of your computer. So why choose one over the other? If you care anything at all about the reliability and accuracy of the Finite element solution, then pick a p-element code, unless the p-element code does not model the physics of your problem well (which is a valid criterion for selecting any particular piece of engineering software).

One last point about integration points. The integration points are the Gauss points for the integration of all the stiffness integrals you need to compute over each of the elements; you are merely approximating the exact integration of these integrals with a finite sum of pairs of weight fcns multiplied the integral argument evaluated at the Gauss points. In principle then there is no limitation on the number of Gauss points you could use (or, for that matter, the polynomial order, p--typically the maximum 'p' is 8 or 9, but I've seen up to p=14!). It just so happens the optimal number of Gauss points is related to the polynomial order of the integral arguments, but that there is no reason other than personal preference of the code developers for restricting the number of Gauss points to say 9 along the edges.