Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Criteria for Evaluating FEA Packages 1

Status
Not open for further replies.

shaun8567

Mechanical
Jul 22, 2010
43
I'm currently in the process of evaluating several different FEA packages and I'm trying to be as objective as possible when comparing packages against one another. I've started to put together a KTA chart to score different criteria to help in the decision process. I've come up with a couple criteria myself, but I wanted to see if anyone else had some suggestions; so far I have:

Performance
[ul]
[li]UI Ease of Use[/li]
[li]UI Customization[/li]
[li]Application Customization[/li]
[li]Mesh Time[/li]
[li]Solve Time[/li]
[li]CAD Interface[/li]
[/ul]

Cost
[ul]
[li]Purchase[/li]
[li]Maintenance[/li]
[li]Licensing (cost for additional thread, etc)[/li]
[li]Training (location, availability, etc)[/li]
[/ul]

This nice thing about using a KTA chart for this is that I can attached weighting factors to the different criteria (for example, CAD interface will have a much lower weighting factor compared to Mesh and Solve Time). Criteria can be both objective (such as mesh/solve time, were I average out the respective times for a test model with (as close as) the same number of DOF) and subjective (such as UI ease of use).
Suggestions?
 
Replies continue below

Recommended for you

Element types

Reliability

Capability (ie. Stress/Heat Transfer/Contact/Non-linearity)

Market share (ie. how well known is the package)

Mesh quality (Forget mesh time as they're all pretty quick)

 
continuity of development

helpfullness of the help desk

IMHO, pick one that seems to fit with you. i don't think that there's one "right" choice (one that'll do everything you (and everyone who uses it) asks), there are plenty "wrong" choices (that'll short serve someone affected by the selection), but i don't think there are many truly "bad" choices (that'll fail miserably for most users).

Quando Omni Flunkus Moritati
 
Hi

A first very simple evaluation is if you can get a license for say 30 days with full support. Basically, can you evaluate the future work situation?

I tried that once with a vendor and the reply was that they had no such licenses. They considered themselves so good that you could buy then without the evaluation. The demonstration with one of their own examples was enough. We bought something else.

I agree with rb1957, there are not many really bad choices. It is probably more a question of likes and dislikes in the gui and don't forget development and support. Also, if you have some type of very specialized analysis, then you might need to be more careful.

Good luck

Thomas
 
Among all the points mentioned here, I'd pay a little extra attention to one of the points mentioned by corus above: "how well known is the package?" In fact, how well known is the package in your line of work. One of my colleagues was surprised at a conference when he was the only one using a specific (well known, mind you) package. That does not mean that specific package was any less; it is just that the support staff will have less experience or you'll find relatively lesser help online.

Are you new to this forum? If so, please read these FAQ:

 
There is some fantastic suggestions in here! To provide a little more background information (which I probably should have done at the beginning):

We currently use Creo Simulate (Mechanica), which is arguably one of the best FEA packages integrated into a mid-range CAD system. We're doing a lot of linear static and dynamic analyses (the dynamic being a seismic analysis using the response spectra method) for equipment racks formed mostly out of sheet metal (up to 3.4 mm thick). As such, we have assembles usually containing ~30 or so parts and about 1900 mm x 900 mm x 550 mm (H x D x W) that are involve mostly shell elements, but sometimes we deal with assembles with almost 100 parts and up to 10 m in a single direction. This is where Mechanica starts to have both meshing and solving issues, so we've started looking at standalone FEA packages. We're currently looking at the following three:

[ul]
[li]ANSYS Mechanical NLS[/li]
[li]MSC Nastran and Patran[/li]
[li]NEi Nastran and FEMAP[/li]
[/ul]

Both ANSYS and MSC are well known packages with large market shares (ANSYS having the largest if I recall correctly), and both are very robust codes (I believe the NRC has tested both codes extensively). NEi has many whitepapers on their website comparing their package against MSCs (showing better results in less time), but I'm taking this with a grain of salt.

Both MSC and NEi have "better" licensing structures compared to ANSYS. I'm a firm believe in keeping analyses are simple as possible while still capturing the relevant physics, but having access to multiple threads to speed up run times is almost always a plus (given the very quick turnarounds that we need to do). ANSYS's limitation to two threads in Mechanical is rather annoying, and the cost of an HPC packet (allowing up to 8 threads and 1 GPU) is almost as much as the cost of the software itself.

Finally, MSC Nastran (at least from my understanding) is arguably the best/industry standard when it comes to dynamics. I haven't been able to find exactly why (whether their code is better at handling dynamics, whether they have a wider range of dynamic analysis methods, etc), but this seems to be the case after reading various threads on this site and others.

Part of the reason I've suggested using Mesh and Run time is because they are very objective measures that I can give quantitative results on (and that are arguably important factors), and I'm actively trying to flesh out more quantifiable measures to include.
 
"MSC Nastran (at least from my understanding) is arguably the best/industry standard when it comes to dynamics." i thought MSC hadn't developed their aoftware since they bought MARC ?

personally i find the PATRAN a difficult interface to use, and FeMap a very easy one.

try before you buy !

Quando Omni Flunkus Moritati
 
Abaqus has been a strong nonlinear code since its very inception. They are a part of Dassault Systemes now, they should have a good future ahead of them. However, if it is not commonly used among your peers/competitors, I wouldn't recommend it.

Are you new to this forum? If so, please read these FAQ:

 
You don't have to use PATRAN with MSC.NASTRAN, we use hypermesh for almost all mesh building, then use the appropriate solver.

The recommendation for a long time on eng_tips was NEi Nastran, no pinches of salt required. Femap was the nicest preporcessor I ever used, and I'm pretty sure the pre processor is far more important productivity wise than the exact speed of the solver.



Cheers

Greg Locock


New here? Try reading these, they might help FAQ731-376
 
shaun8567:

I would perhaps not say that MSC.Nastran is the best when it comes to dynamics. Nastran was from the beginning aimed primarily on dynamics but I'm not sure that MSC is the strongest any more.

I have worked a lot with MSC before NEi and my experience is that MSC is big in some industries. But the development is more active in NEi and NX. If you look at the latest release documentation for MSC the development is primarily in nonlinear (MARC) and solver speed (hardware support).

I would make sure that the solver can solve the task required. After that, carefully check out the pre/post processor because that will be your "working environment". Things like geometry import can be an issue. There are formats that Femap can import that Patran won't and so on.

Anyone can buy a software. But using it to get meaningful results in a reasonable time, that's the trick.

Good Luck

Thomas
 
All of this information has turned out to be very useful! As I mentioned at the start of this tread, I'm using the KTA method to help in the decision making process (screenshot below; a score of '0' means I haven't evaluated it yet). I learned about this in grad school from the professor I had for precision mechanism design, and it has turned out to be an extremely useful decision making tool. After all is said and done I'll upload and provide a link to download the KTA chart I'm making in Excel in anyone is interested.

I'm starting to setup a methodology for measuring meshing and solving time, so I need to come up with a couple test geometries. So far I have:
[ul]
[li]Plate with a Hole (modeled with plane stress)[/li]
[li]Cantilever I Beam (modeled with shell elements)[/li]
[li]Tensile Strength Specimen (modeled with solid elements[/li]
[/ul]

Anyone have any other geometry suggestions?
 
 http://files.engineering.com/getfile.aspx?folder=1c3471ff-74e1-40ba-bc2b-0007e3da5056&file=Screenshot_9.png
Hi

One thing regarding your chart (perhaps you already know this). MSC Nastran and Patran does not have to be a package. Neither does NEiNastran and Femap have to be working together. You can buy Femap and after that choose between MSC, NX or NEi (Nastran) as well as several other solvers.

I would not be surprised if MSC pushes MSC Nastran and Patran as a package but that is not technically necessary. It is primarily a sales pitch in my opinion.

As for geometry suggestions. Why not use something that you will analyze when you make production runs?

Good Luck

Thomas
 
I believe that the market leaders are Abaqus and Ansys. I have used just about every solver out there and a quick search on my handle will show what is my favorite. I completely agree with ThomasH about using your actual geometry. I have always gotten some free consulting having the competitors do a proof of concept simulation. Scriptability is also a very valuable feature especially if you expect routine simulations. For the GUI the ability to handle difficult CAD geometries such as slivers is top priority. I hope this helps.

Rob Stupplebeen
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor