More on DMP vs SMP

To paraphrase one of my professors at  UC Davis, once you understand a problem well enough to formulate an elegant question about what it is you don't understand, you're halfway to figuring it out.  It was with this in mind that I was contacted by one of my readers with some questions about some of the differences between SMP and DMP.  Paraphrasing and obfuscating a bit, our conversation went something like this:

Reader

Could you explain a bit more about the difference between DMP and SMP?  I understand your card sorting analogy, but what does that mean for hardware?  Multi-cores?  Dual CPUS?  Both?

AppliedFEA

The answer depends a bit on your solver and solution type. The executive summary is that SMP makes most things much faster, but DMP makes some things much much faster, so long as you have enough memory to spare. What solver (Abaqus/Nastran/optistruct) And solution type (statics/frequency/transient etc) are you targeting? Depending on the answer to the previous questions DMP may not be available at all, such as if you're running Nastran SOL 106.

Reader

We run a lot of static stress analysis and modes.  We use implicit solvers such as ABAQUS/Standard, Optistruct, or MSC/MARC.  We run some ABAQUS/Explicit.

AppliedFEA

To break outside the card analogy, an FEA solution requires the solution of a sparse stiffness matrix. Depending on the solution type, there are several levels at which the solution can be broken up and solved on more than one processor at a time, given that the system solving the problem has more than one CPU core. At the lowest level, SMP/parallel, only the vector operations are parallelized. Essentially every solution type in Nastran and Optistruct can make use of this low level parallelization.

You're in luck, however, as some of your solution types have the ability to be parallelized at a higher level.
For statics:
In Nastran, the domainsolver card allows a statics (sol 101) job to split with the stat method, which can assign each processor a certain number of grids or degrees of freedom. Abaqus does it's DMP split similarly, albeit solely at the element level.
For modes (eigensolver):
In Nastran SOL 103 you can use the MODES dmp method, which can split the job up at the grids, DOF, or frequency level (ie each process finds modes in a portion of the total frequency range). Abaqus can, again, split things up over the Element level.

If you're finding modes of models with large numbers of degrees of freedom, consider using an an automated multi level substructuring eigen solver instead of the more typical lanczos. Both Optistruct and MSC Nastran can use the university of Texas developed AMLS eigen solver, which can be purchased separately. All three solvers have also developed their own similar solvers, in Optistruct they call it AMSES, in Nastran they call it ACMS, and in Abaqus AMS. Speed increases of 10x or more are not unknown.

So to tie back to my typical advice, just make sure you are off the hard drive, DMP (split the level up at a high level, with each split requiring more memory) until you run out of memory or CPUs, and if there are any CPUs left after you run out of memory, use parallel/SMP to use those to split up the split at a low level.

The need for speed - Part 7 of 7: Optimizing model detail and solution type

This entry will be less specific than other entries, as the number of techniques to reduce the amount of work required of an FEA solver are extraordinarily numerous. 

There are roughly three ways to change a model such that it runs faster

• reduce the detail level of the model
• make use of modeling abstractions
• use aggressive techniques to arrive more quickly at nearly the correct solution

Reduce Detail Level

The typical guidance for how much detail a model needs is to run a convergence study, increasing detail until the result that an analyst cares about is no longer changing as more detail is introduced.  I generally agree, although a smart analyst should still build up a feel for about how much is necessary for certain features that are commonly modeled in their work.  A few other tips:

• If an analyst is comfortable working with second order elements, they will typically achieve more accurate results with less run time than simply adding more elements
• If only a portion of the model is of interest, then Abaqus Surface-Surface ties can allow for a faster transition to the less detailed global model

Many situations do not converge to a solution, and will continue to change their result no matter how fine the level of detail, as the elasticity solution is undefined at a point of interest.  These situations are:

• A perfectly sharp corner
• A point in space that can see three material models, with empty space counting as one material model.  These are commonly encountered in soldered joints, composite layups, and other situations where bonding unites two dissimilar materials.  For these situations correlation studies using physical test specimens are usually used, and they will indicate the level of detail one should use in a corresponding FEA model
• A point constraint or point load

Frequency based solutions should aim to have at least 4 elements per half wavelength for standing waves on structure or in air.  The Abaqus documentation provides good guidance for how to do this for acoustic FEA

Modeling Abstractions

Superelements
If a portion of the model is fixed and will not vary throughout the design process, you can create a superelement (or DMIG as they are sometimes referred to in Nastran) to find the structural response at the interface to that portion of the model
   
Submodeling
If the portion of interest in an Abaqus model is much smaller than the global model which determines the loads that go into it, and design changes in a submodel will not effect the global model, a submodel can provide insight into the behavior of the small portion of the model without having to compute the global solution

Modal Techniques
If the modal density of a model is not too high, modal transients or dynamics can save significant run time. This is particularly with the advanced eigensolvers that are becoming more common in solvers such as Abaqus, Nastran, and Optistruct.  Note that modal density refers to how many modes lie within a frequency range of interest, relative to how many degrees of freedom there are in the model. 

Aggressive Techniques

Some of these are a little wild and could lead to inaccurate results.  Be careful.

• Use the unsymmetric solver in Abaqus when dealing with models which have strong nonlinear behavior.  Certain nonlinearities absolutely require it, others just converge faster with an unsymmetric solver, with fewer steps, even though each step will require slightly more work
• Use an iterative solver for large compact models, such as engine blocks
• Reduce convergence criteria for nonlinear analyses.  If a model is nearly converged but not quite you can just call it good enough and move on with these tricks
• For models where a body is positioned only by contact with friction, try lightly constraining the body with a spring or constraint while converging the contact solution, then removing the constraint at the last step.  It will change the final result, as contact is path dependent
• Use variable mass scaling in Abaqus explicit to set a minimum stable time increment when there are a few small elements controlling the minimum stable time increment.  The size of the scaling and the number of small elements may effect the accuracy of this technique

The need for speed: Part 6 of 7 - Reducing output requests

In order to find a solution to a structural FEA model, an FEA solver must find the displacements that result from the applied loads and displacements.  What an analyst does with this solution for the model, which is now held in memory,will affect how much extra effort the FEA solver must put into finding other solution variables, and to saving all the requested output to disk.  The typical guidance is that excess output requests is a bigger impact on hard drive space than on solution times, but certain solution sequences can generate output so frequently that it can severely slow the solution speed, such as explicit, which will typically have time steps so small (maybe a millionth of a second) that even for short duration events an analyst may only care about the solution result every thousandth step. 

There are two types of output from an FEA solution: primary field variables and calculated variables.  Primary field variables are the actual solution, such as displacements for a structural simulation or temperatures in a heat transfer simulation.  As such, when they are requested they only require writing data to the disk and have a small impact on simulation speed.  The other type of variable, calculated variables, are found by using the solution variables and the properties of elements to back calculate other variables, such as stress and strain in a structural simulation or heat flux in a thermal simulation.  These require actual computation, and as such will have a much bigger impact on simulation speed.

Some practical tips for particular solvers:

Abaqus
Abaqus will only output the output variables that you request.  The most important thing in Abaqus is typically to reduce the frequency of output in a nonlinear analysis and explicit dynamic analysis.  Both of these solutions will find a converged result over and over again, and unless a model is new and being diagnosed these intermediate results typically do not need to be output very frequently.  Make use of the '*output, TIME INTERVAL=' or '*output, Frequency=' keywords to limit the frequency of these outputs.
  
There are two typical types of output in Abaqus: Field and History.  Field is usually used less frequently to output the complete solution, and history is more typicall used for global measures of model condition, such as total kinetic or elastic energy.

While using "*output, variable=preselect" will provide the most typically used variables in most cases, being more specific about which variables, and even which elements or nodes you wish to find solutions at, will provide even more savings

Do not use *restart unless you are fairly certian you need to use, as it will generate an ENORMOUS restart file.

Optistruct
Optistruct has an interesting behavior in that if no output is requested, it will generate the default outputs for you, similar to Abaqus' preselect.  Outside of not requesting things you dont' care about, the most important thing to do in Optistruct is to be careful how frequently a full result from an optimization is output.  This can be set on the card, 'OUTPUT,(OUTPUT TYPE),(FREQUENCY)'.  The best result is usually FL for the frequency, as this will generate the full results for the initial and final design.


Nastran
Similar to Optistruct, take care to request only the results you care about, using both selective choices of output requests in the case control and use of sets to only requests results for regions you care about.

The need for speed: Part 3 of 7 - Performance Tuning Parameters: Abaqus and Optistruct Linear

Previously we've discussed the three main priorities when trying to use the optimal settings for an FEA solver.

• Get off the hard drive
• DMP until you run out of RAM
• SMP until you run out of processors

We also discussed an analogy that we will continue to make use of.  Essentially, solving an FEA solution is analogous to sorting a deck of cards on a table.  In this analogy, SMP is equivalent to using the same amount of table space (table space being equivalent to memory), but using more people to help sort, with people being equivalent processors.  DMP, on the other hand, involves breaking up the table space into seperate parts, either on one table or on a separate table in a different room.

So given what we now know, how do we accomplish the optimal use of computer resources using specific commercial FEA software?

A Note on system limitations
The following blog post assumes a user is already knowledgeable about the limits of the system they are running their FEA simulations on.  Techniques for checking available system resources vary considerably between windows and Unix/Linux based environments, and identical hardware may have different limitations based on 32-bit vs. 64-bit operating system limits, among other things.  I plan to cover this topic in more detail in a later post.

ABAQUS
Of the three codes I typically cover, Abaqus is the easiest to properly configure for speed.  All Abaqus needs to know is how much memory is free on a computer, how many processors are free on a computer, and what machines it can use.  There is almost nothing else to set.

To begin, start by doing a datacheck.  Assuming you know how much memory and how many cpus are in your computer or server, and that you know how to execute using the command line, start with the command:
abq6101.bat memory="1 gb" datacheck job=jobfile.inp
 note that abq6101.bat is what I use on my local machine.  On linux servers it will typically be /opt/abaqus/Commands/abq61... depending on version.

Hopefully your job has been carefully prepared and the Abaqus pre-processor will finish without any errors.  On linux machines, or windows machines running cygwin, you can monitor the progress of the datacheck run with the tail command.  Ex:
tail -n 100 -f jobfile.dat
The important data will be held in a section that reads:

 PROCESS      FLOATING PT       MINIMUM MEMORY        MEMORY TO
              OPERATIONS           REQUIRED          MINIMIZE I/O
             PER ITERATION         (MBYTES)           (MBYTES)
 
     1         1.86E+012              691               5623

For this run, at least 691 mb must be available to the abaqus solver, and no more than 5623 mb needs to be used by it.

As an aside, Abaqus handles DMP in a very different way than Nastran or Optistruct.  Whereas Nastran and Optistruct multiply their memory usage by a factor of memory requestedxDMP, Abaqus will report the total memory needed by all the DMP processes.  This is because Abaqus has put significant development effort on a style of DMP that's not quite full DMP, one that is not akin to a full box of cards being sorted independently on different tables or in different rooms, but is more like several people at one table, but with significant effort being put into sorting out who gets what chunk of cards ahead of time.  In this way, with some effort by the first person to grab the deck of cards, many people can be kept busy on a smaller table, and a single deck of cards can even still be worked on a great deal of tables.  When there are several decks of cards to sort this becomes less efficient than the Nastran/Optistruct style, but Abaqus' approach is the best for attacking one deck.

Returning to the memory settings, because the memory total is the true memory total, one need only set it to whatever is the maximum actually available on a computer and Abaqus will handle the rest.  Abaqus is even smart enough to only use as much memory as it needs, as long as that is less than what you allocate it.

So what happens if we have a desktop computer with 8GB of ram and a 64-bit operating system with virtual memory, and we try running it with memory ranging from the bare minimum to the maximum?

So what happened?  Wasn't adding memory the most important thing?  Well here's the big surprise: a modern operating system helps a great deal when you do one of two suboptimal things:

• Using less memory than you actually have
• Using more memory than you actually have

If you ask for less than you have, the operating system will be smart enough to use the virtual memory of your computer, which is where memory can substitute as ram and vice-versa, to keep your FEA program from using the hard drive as much as it can.  If you try to use more memory than your computer has, it will still use the virtual memory, only this time in the other direction.  As I've mentioned before, you're still better off using the FEA softwares' own out-of-core scratch memory management, but even if you do something wrong your operating system will usually be there to minimize the damage.

So let's say you now have enough memory, how do I use more cpus?  Again, the syntax is simple
abq6101.bat memory="6 gb" cpus=2 job=jobfile.inp
In this case we are requesting 6 GB of memory and 2 cpus.  What are the performance benefits from additional cpus?  Typically, the first cpu nearly doubles performance, 4 cpus is a little more than triple speed, and so on as the returns diminish.  More detail can be found here.

How about Gpus?  Although I don't have a system that can take advantage of it, in the latest abaqus 6.12 release it is selected with the syntax
abq6121 memory="6 gb" cpus=2 gpus=1 job=jobfile.inp
The above will use two cpus, 6GB of memory, and 1 GPU (1 video card).  Note that there are significant limits on the solvers that gpus can be used on, specifically only the sparse symmetrix solver in implicit solutions.  This rules out explicit and extremely nonlinear problems, such as those with coefficients of friction higher than 0.2

Finally, the use of more than one host is enabled in the abaqus_v6.env file.  HP-MPI or some other interconnect must be enabled, and infiniband will yield measureably higher performance than 1GBit ethernet.  When using extra hosts, check to make sure that rsh commands are enabled on ssh through the use of key based logins. To enable additional hosts, include in the abaqus_v6.env file the following line:
mp_host_list=[['host1',4],['host2',4]]
The first entry is the name of the host on the network, the second the number of cpus that can be used on that host.  Any run that uses more than one cpu and has extra hosts available in the abaqus_v6.env file will take advantage of them. 

One final thing to remember is that many of the previous memory and cpu settings where originally only set in the abaqus_v6.env file.  It may be worth it to check what parameters remain in the file, either from yourself or your adminstrator, as many of them have changed over the last few versions.

Optistruct
Optistruct can be optimized in a similar, by first running a datacheck and then using the correct memory parameters.
If one is in a hurry, one can simply run optistruct with the below settings
radioss -core in -cpu 2 jobfile.fem
If sufficient memory is available to run in-core with minimum disk use, it will use it, and in this example it will use two cpus in SMP style.  Note that if insufficient memory is available for in-core it will error out.

If we want to see what a job will need, then we can instead run
radioss -check jobfile.fem
Assuming your model is built well, the .out file will eventually read like this:

MEMORY ESTIMATION INFORMATION :
-------------------------------
 Solver Type is:  Sparse-Matrix Solver
                  Direct Method

 Current Memory (RAM)                                    :     116 MB
 Estimated Minimum Memory (RAM) for Minimum Core Solution:     154 MB
 Recommended Memory (RAM) for Minimum Core Solution      :     154 MB
 Estimated Minimum Memory (RAM) for Out of Core Solution :     189 MB
 Recommended Memory (RAM) for Out of Core Solution       :     211 MB
 Recommended Memory (RAM) for In-Core Solution           :    1515 MB
 Recommended Number of Nodes for OS SPMD Parallel Run    :       1
 (Note: Minimum Core Solution Process is Activated.)
 (Note: The Minimum Memory Requirement is limited by Assembly Module.)      
 (Note: Use param,HASHASSM,yes to avoid assembly module memory bottleneck)

DISK SPACE ESTIMATION INFORMATION :
-----------------------------------
 Estimated Disk Space for Output Data Files              :      18 MB
 Estimated Scratch Disk Space for In-Core Solution       :     208 MB
 Estimated Scratch Disk Space for Out of Core Solution   :    1895 MB
 Estimated Scratch Disk Space for Minimum Core Solution  :    1952 MB

In the above example, we would need a total of 1515+208MB of ram for a maximum reduction in hard drive use.  The syntax for this would be
radioss -len 1723 -ramdisk 208 -cpu 2 jobfile.fem
As noted before, additional -cpu cpu's add some measure of speed but do not require more ram.  

If a job is of a type that can also DMP, then they can be requested using the syntax:
radioss -len 1723 -ramdisk 208 -cpu 2 -mpi -np 4 jobfile.fem
A few things I've found: hpmpi sometimes has issues, so take care with the documentation to show it the path to the hpmpi files if necessary.  Also note that the total memory demands are now 4x1723=6892 MB, and the total number of cpus needed is 4x2=8.  Solution sequences that make use of DMP well tend to be direct frequency and lanczos eigensolutions, although eigensolutions will nearly always be faster when using a modern multilevel eigensolver.

Closing Remarks
As we've seen, different solvers can be very different in how they understand the tuning parameters given to them by users.  Additionally, there is typically a significant amount to be learned before even solving a model by simply invoking a checkout run.  As we will see in the upcoming Nastran entry, checkout runs are unfortunately not as capable in MSC/MD Nastran.

The need for speed: Part 1 of 7 - Intro

How can I make my FEA simulation run faster?
Ask less of your computer, use more of your computer, or use a faster computer(s).

Once you've meshed the geometry, applied the material properties, applied the loads, assemble the load cases, and the model runs sometime today, doing more work to make the model run faster is probably the last thing on your mind. Tuning parameters and measures of the solution difficulty of a model can seem dauntingly complex, and the payoff from a model that runs faster may not seem worth it. However, a working knowledge of how to manage the detail and run times of a model can have some major payoffs:

• knowing ahead of time if a model has surpassed the ability of a computer to quickly solve
• minimizing storage and archiving requirements
• ability to run the same model several times to assess design sensitivities and optimize the performance of a design

This final advantage is oftentimes the most important reason to put effort into minimizing run times. The ability to analyze a design more than once in the time available can make the difference between a high performing design and and an inadequate design.

In a series of posts, I'll outline the practical steps an analyst can take to speed up their run times. This is obviously an extremely complex topic to fully cover.  Fortunately, a little knowledge can go a long way, and I will focus on the topics that typically have the largest impact.  Upcoming posts will cover:

Use more of your computer:

• Performance tuning parameters: Common Topics
• Performance tuning parameters: Abaqus and Optistruct/Radioss
• Performance tuning parameters: Nastran
• A faster computer: performance metrics

Asking less of your computer

• Reducing output requests
• Optimizing model detail and solution type

MPCs: a quick summary

Many years ago one of my coworkers built a model in Optistruct and was disappointed to see the RBE that he'd built failed to provide the restraint he expected.  He called up the technical support at Altair, and after some back and forth about the RBE element the support representative finally lost his patience: "It is not an element, it is a system of equations!"

So what are these equations, and what do they do?
First of all, they are indeed different from an element.  Although FEA software may refer to them as a type of element, they have a fundamental difference from a normal element. A normal element adds to the global stiffness, mass, and damping matrices. An MPC (multi point constraint) is more like an SPC (single point constraint), in that it modifies instead of adds to the matrices that describe the model in order to describe the special behavior of these MPCs.

So all that sounds interesting, but it hasn't really told you much about what they do. I've thought of different ways to describe them to my coworkers, and the best I've come up with is this analogy. Basically, you're including a group of grids in a type of government, and you're letting them know what kind of leader they have. So what's an RBE2? An RBE2 is a monarchy, where the control grid is king, and tells the other grids what to do. An RBE3, on the other hand, is more like a democracy, where the President does what the people tell it to do. So what works and what doesn't work when we try to make use of these MPCs?

What Works

The above works because the king can tell the dependent nodes what to do.  There are constraints on grids, but not on the same ones as the RBE2.

The above also works because the dependent grid knows what to do because the nodes that vote for it at least know what they want; if the elements beneath them were unconstrained then the whole set of elements would not know what to do.

This one works because the voters still know what they want: the constraints tell them what they want! The RBE2 above the RBE3 also knows what to do because the president is telling it what to do.  Ok, My analogy is getting old.  I'll switch to talking about independent/dependent grids.

As you can see above, I lied, the deputies are out!  Through the use of UM grids the RBE3 is not the dependent element, and can now be told what to do.

The above also works, as the UM grids allow the top RBE3 to not have its dependent grid be the same as the bottom RBE3 dependent grid.

Finally, the above works because the top RBE2 is only connected to independent grids.

You can download the above examples at RBEThingsYouCanDo.bdf

What Doesn't Work

Well this won't work, the RBE2 is trying to tell the dependent grids what to do, and the constraints are doing the same thing.

The above also doesn't work.  There are nodes which are dependent nodes in two separate RBE2's.  

The above also has problems.  The UM grids have been set, making them no longer independent, but those grids also have constraints, so again we have grids where MPCs and constraints are both trying to tell  a grid what to do.

Finally, the above is also bad.  You can't make a grid the dependent grid of more than one RBE3.

You can download the examples of things that don't work at RBEThingsYouCantDo.BDF

There are fun tricks you can do once you're feeling comfortable with RBE3s.  The two most interesting are:
-Applying load without adding stiffness.  If you have a certain total load that needs to be applied across a cross section of a model, you can use an RBE3 to apply it.  This is particularly useful at the ends of a beam.
-Constraining the overall motion of a larger body.  If it's known that something is sitting on a very soft support, such as rubber or water, an RBE3 can be created across the supported region, and through the setting of the UM card you can constrain the former dependent grid to control the overall average motion of the model.

There is, of course, something that analysts commonly do when they need to make a part of their model very stiff but don't have the time or experience to construct MPCs without errors: create elements with very very stiff properties that will behave similarly to MPCs.  The upside to this approach is that it will typically yield a very similar answer, the downside is that it may take a few iterations to find a stiffness that is stiff enough, yet not so stiff the stiffness matrix becomes ill-formed.

So wouldn't it be great if there was an MPC that automatically made a very stiff element that was just stiff enough?  Something that automatically created a perfectly rigid body but then had stiffness that connected it to the dependent grids?  Well there is in fact an element that does this.  This type of element is typically called a Lagrangian element, and it can be selected in certain load cases in Nastran and is the behavior for Kinematic (RBE2 style) and distributing (RBE3 style) elements in Abaqus.  I'll cover this topic in more detail in a later post.

Update 28 Sep 2021: Due to a Google security update the example file links expired, should be working again.

A Short and Incomplete History of Pre- and Post-Processors

As seen in our previous example, applied finite element theory requires more than just the ability to find a solution to a posed problem, one must also pose the problem!  Even after finding a solution, significant work usually awaits after results are found, and software for this purpose has evolved in tandem with FEA solvers.
The Dark Ages
Before the introduction of software designed to aid in the generation of finite element models, modeling was accomplished in a manner similar to other prehistoric engineering work: with reams of paper.  The more limited computers available in the 60s and 70s could find solutions to models of limited size.  Therefore the manpower required to take copies of blueprints, dimension the locations of grids, and connect the related elements, was more manageable.  The limited model size also made more practical reordering the grids to allow for faster solutions to structural FEAs.  As is common in engineering, analysts became very talented at work that would later be done faster and usually better by automatic algorithms.
Several phrases still in common use when referring to finite element models, particularly Nastran, come from this era.  One in particular is the term 'card', which describes the lines of text used to describe finite element entities, which were literally stored on punch cards.  Clever analysts would have large libraries of punch cards which could be readily used to describe the properties of elements and materials.

Proprietary codes and the dawn of Patran
As the 70s gave way to the 80s, computers fast enough for graphical display of geometry allowed for the development of programs which would allow for easier generation of models.  A number of large engineering companies developed their own proprietary pre-processors, while MSC corporation, the original vendor of Nastran, developed the matching pre-processor Patran.  Patran was initially given to Nastran customers at no additional cost, and rapidly became the industry standard pre-processor.  This led competing FEA codes, such as ABAQUS, to partner with MSC to have support for their solvers added to Patran.  Patran would grow to have very broad functionality, allowing for importing of geometry from CAD design systems, renumbering of grids to reduce solution times, and graphical display of element properties to allow rapid validation of models.

Hypermesh, ABAQUS CAE, and ANSYS
Beginning around the end of the 80s additional vendors began competing in the marketplace.
Hypermesh was authored with the specific goal of being solver agnostic, allowing analysts to familiarize themselves with a single solver and quickly adapt models from one solver to another.  Later iterations of Hypermesh allowed for greater modifications of existing models independent of CAD generated geometry, and allow for pre-processing specific to the optimization capabilities of its own solver, Optistruct, descended from Nastran.
ABAQUS CAE took a different track from Hypermesh, with a focus on a single solver and the ability to make full use of the unique features of that solver.  A rarity in pre-processors, CAE allowed CAD style dimensioning of 2-D sections as the origins of 3-D models.  In a preview of a growing trend in Pre-processors, emphasis was made on generating geometry then generating mesh associated with that geometry,   rather than operating on the mesh directly, as was the style of Hypermesh or Patran.
ANSYS took a similar approach to ABAQUS, creating their own pre-processor, with the additional step of hiding the input into their solver from the user.   As solvers predated pre-processors, the typical pre-processor workflow was a pre-processor that generated an ASCII text file that could be inspected and edited by the user, and also imported into a competing pre-processor.  By hiding this abstraction from the user, ANSYS created a more complete solution that was also less amenable to users mixing and matching pieces of their workflow from other vendors.

FEMAP, Solidworks simulation, and CATIA Analysis
As desktop computers became fast enough to solve large and not particularly efficient FEA models, more vendors became interested in broadening the FEA user base from dedicated analysts to typical drafters and designers.
FEMAP was authored as a typical pre-processor of the previous era, handling multiple solvers and generating an input deck, but with a focus on affordability and intuitive ease of use rather than sophisticated capabilities.
Solidworks Simulation and CATIA Analysis, both now a part of the Dassault systems product lineup, each add FEA capabilities to advanced CAD systems.  Solidworks incorporates the COSMOS solver, whereas CATIA incorporates the ABAQUS solver.  Both take care to make reasonable choices of FEA parameters for the type of analysis chosen by the user, such as element type and internal solver, and are integrated into the larger parametric workflow of the designer.

Optimization and 
The ideal future workflow for engineering is an intuitive GUI which allows a minimally trained analyst to:

1. Conceptualize a design
2. Evaluate its structural adequacy for its function
3. Optimize its design for both cost and function
4. Generate design detail, including variability tolerance, sufficient to produce the design
5. Save the results of the analysts work into a product data management system

 With Hypermesh and Solidworks/CATIA, there are two reasonable workflows that are likely to continue to be used:

• Design first: For smaller design teams working on designs with a reasonable number of pieces with shorter design cycles, such as a consumer product rather than a jet fighter, the Solidworks/CATIA workflow tends to work best.  Software licensing costs are usually more reasonable, training investments more manageable, and models sizes easier to solve by more typical computing hardware. 
• Analysis first: For larger design teams, typically with dedicated analysts teamed with dedicated designers, an analysis first methodology tends to work well.  At several steps and levels of detail, an analyst will take an initial concept of a design and, with the use of pre-processors such as Patran and Hypermesh, mature it into a more reasonable design using either hand iterations or optimization. This will yield dimensions of a design that the analyst will then pass onto the designers who will realize these dimensions into producible designs.

Closing Remarks
As computing hardware and FEA software continue to evolve, the trend will likely be towards the more intuitive design first approach becoming more common.  This trend will take some time.  An FEA model that hasn't been carefully designed to have only as much detail as necessary can take a very long time to solve, given that solution times typically grow with the square of the model detail, which for a cube of material grows with the cube of detail in any direction!  On the other hand, Moore's Law only generates a double of transistor count (not speed!!) about every 18 months.  Both design methodologies are likely to remain in force for some time to come, and their continued influence on each other should yield dividends in efficiency and intuitiveness that will benefit both.

An Example Optimization

The below example of rapidly maturing a design from concept to near complete design comes from a presentation I created for the Aerospace Corporation in 2007.

Example : multi-constraint optimization of an actuated door 
For a given design space, materials, and fully-reversible pressure loading, create the layout and dimensions of
a door which:

• is at least 15 Hz away from the first 2 harmonics of 50hz
• does not experience gross tension yielding under pressure loading
• Prevents buckling under pressure loading
• Minimizes weight

Optimization steps:

1. Create a model with applied loads and solid material filling the design space
2. Perform topology optimization to find stiffest layout for the design space
3. Using the results of the topology optimization, make a shell model of the door
4. Perform size optimization of thicknesses of shell model to satisfy design constraints while minimizing weight

Step 1
Shell- and hex-mesh the design space, and apply pressure distribution.
Dimensions are roughly 16"x11", with the door covering roughly a quarter wedge of a full cylinder wall

What stiffener pattern might most efficiently stiffen the design space? One of these?  Any of these?  

The best stiffening pattern is seen below.

The small radius of curvature means that the design is naturally stiff down the axis of rotation, so the stiffeners tended to cross the design space in the other direction.  They also increased the connection between the two main support points.  This a typical result of topology optimization, a layout which would have required careful consideration by an experienced analyst.
The geometric results of the topology optimization can be imported into the Hypermesh pre-processor, which then can guide the analyst in laying out a detailed mesh to be used for more detailed optimization.

To perform an optimization in Optistruct, the optimization problem must meet a few requirements:

1. One or more responses, such as weight or maximum stress 
2. Only one objective, based on one or more response, such as minimize weight or minimize maximum stress
3. As many constraints as an analyst desires, such as limiting maximum stress while also limiting the natural frequency of a design

The shell model had responses based on stress, natural frequency, and weight.  The objective was to minimize weight, and the constraints were to limit the stress of the material and the natural frequency of the door.  The shell model was divided into the design regions seen below, each color representing a different design region.

Within six iterations, Optistruct had taken a design which had responses 35% higher than allowed to one which met all design constraints.

The dominant ribs and underlying webs required the thickest dimensions.

A design that meets all design constraints at the first iteration will usually see only improvement in the objective; i.e. a part that already is strong enough will only become lighter.  The alternative is a design which does not meet its design constraints will make its design constraints, hopefully without the addition of too much material.  The quality of the layout from the topology optimization allowed the design to meet its constraints with the addition of only 6% more weight.

The full presentation on the broader utility of the Altair Hyperworks suite can be found here.  Note that later versions of Hypermesh and Optistruct have added new features outside of the limits seen in the linked presentation.