Folks, here are some comments (I use MECHANICA since '93 and we have
tested/used also MARC/MENTAT and NASTRAN):
* Accuracy in MECHANICA depends only a little on the user (SPA and
MPA gave much better results than NASTRAN, especially if you
investigate several load cases)
* NASTRAN and all other h-element calculation systems need about
3-times more degrees of freedom (DOF) to reach the same accuracy
as MECHANICA -> thus the calculation times are much longer
* The automatic meshing is quite good in MECHANICA; the size of
elements is limited to the accuracy of the geometry in both
systems, but due to the p-method you will get in MECHANICA even
at the smallest element edge much more DOF as with h-elements
(this is essential in calculating e.g. small rounds)
* All MECHANICA elements follow exactly the underlying geometry;
usually the h-elements are polygons -> this is one reason for the
better results with MECHANICA
* If you use e.g. 4-noded tetra elements in a conventional system
like MARC or NASTRAN the numerical failure in the displacements
can be up to more than 50 %; thus stresses will have failures of
more than 100 % (stresses are derived from the strains
(differences in displacements) and thus more critical); even if
you user quadratic elements and e.g. three element layers at thin
walls you can get a failure of 30 % in the stresses -> this also
influences strongly life predictions !
* Be aware of the fact, that one h-mesh can be very good for a given
load set, but can fully fail with others; MECHANICA can handle
this very good
* MECHANICA has no upper limit in elements and DOF; you can use the
64-bit version (e.g. we had a calculation with 19.5 Mio. DOF with
119.000 elements and 3 load sets: max. memory 13.3 GB, temporary
disc space 236 GB, 98.600 sec elapsed time, 199.000 sec CPU time
on a machine with 2 QuadCore processors and 16 GB physical memory)
* Learning is always necessary and needs much more time with the
h-method; but even than it lasts much longer to build up an
appropriate model in h-codes
* NASTRAN has also a limited number of functionalities (that's the
reason why msc.software bought MARC)
* NASTRAN and all h-code users do the same or more mistakes in
calculations than MECHANCA users; this results from the complex
possibilties and thus more unlogical settings.
With best regards
Stefan Reul
Hodgson, Jonathan P schrieb:
> I can't help feeling that this has been covered before, but...
>
> - Accuracy of results in both packages depends on the user. Both can
> produce reliable numbers if the model is set up correctly.
>
> - Mechanica has an upper size / complexity limit, due to memory.
> Nastran will just keep on grinding, using bigger and bigger swap files,
> no matter what (even if it takes days).
>
> - Ease of meshing: Mechanica wins hands-down. The meshing is completely
> automatic - although see the above point about accuracy, and my
> footnote.
>
> - The learning curve is shallower to begin with in Mechanica, but gets
> steep as you get into complex models, or ones where you need to start
> using mesh controls and the like to achieve the accuracy. Nastran takes
> more learning initially, but then you're more or less set up for
> everything.
>
> - Mechanica's biggest asset is seamless integration with Pro/E. Once
> you've attached loads and constraints to your model, you can alter
> parameters (and even geometry) as much as you like, and just re-run the
> analysis.
> Other than that, Mechanica is generally quicker to use, certainly for
> simple models, although for analyses with multiple load cases the
> ability to edit the load deck for Nastran is nice. On occasion I've
> imported IGES files into Pro/E to analyse using Mechanica, because it
> seemed like the easiest way.
>
>
> With either package, be aware that you really need an understanding of
> FEA principles to guarantee reliable, accurate results. The biggest
> risk with Mechanica is probably that it's too easy, and too automated -
> users can get complacent, and trust the results without checking
> carefully. Nastran is probably better for training up good users...
>
> This should probably be on the proecae list, btw - I've cross-posted to
> there, and future replies should ideally be trimmed to that list only.
>
> HTH,
> Jonathan
>
>
>
