Mechanica vs. Algor
Mechanica vs. Algor
(OP)
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
Thanks, Matt





RE: Mechanica vs. Algor
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.
www.borowskiengineering.com
RE: Mechanica vs. Algor
RE: Mechanica vs. Algor
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.
RE: Mechanica vs. Algor
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.
RE: Mechanica vs. Algor
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
RE: Mechanica vs. Algor
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
RE: Mechanica vs. Algor
RE: Mechanica vs. Algor
Here is the thread where ttoole's concerns were addressed:
thread810-142688
You may want to read it through...
RE: Mechanica vs. Algor
RE: Mechanica vs. Algor
www.calculix.de (the Linux version was developed in Germany)
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.
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.
www.borowskiengineering.com
RE: Mechanica vs. Algor
www.bconverged.com/calculix
RE: Mechanica vs. Algor
RE: Mechanica vs. Algor
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.
RE: Mechanica vs. Algor
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!
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.