Variational versus Parametric... it's all really quite simple

Posted by Wayne McClelland to the ICCON Bulletin Board, 26-May-1995

Despite all the hype and aura that one hears in the industry, it is really quite simple to contrast the mathematical approaches known as variational and parametric modeling. Up front, it should be noted that we'll be discussing the pure mathematics of variational and parametric modeling, not the way that these approaches might be implemented and even mixed together in any particular software system.

We can view both approaches as seeking to solve a set of governing equations, where the equation set is characterized by variables (the unknowns) and constraints (the boundary conditions of the problem). In general we might have geometric variables (e.g., dimensions expressing length, height, etc), geometric constraints (e.g., parallelism, tangency), and/or engineering variables (e.g., flow rate, gear ratio, etc).

The parametric approach employs a sequential solution to a set of governing equations:

... where each equation is solved in sequence one after the other until all variables are determined. By definition there must be as many equations as there are unknowns and there can be no coupling amongst variables. (We'll come back to these issues in a moment.)

The variational approach employs simultaneous solution to the set of governing equations:

... where the equation set is in general nonlinear, coupled (off diagonal terms are non-zero), and even perhaps non-symmetric (corresponding off diagonal terms, e.g. A12 and A21, are not equal). There can be fewer equations than unknowns (m<n) in which case the solution will be for one of perhaps several valid solutions.

Mathematically, that's really all there is to it. So, what are the implications that result from these two different approaches?

... which means??

bulletThe ability to handle partially constrained problems means that the design engineer does not have to (slow down to) fully define all constraints before proceeding with his design activity. Consider the following simple sketch of the rim of a milled pocket:

bulletIn this case, the design engineer could bypass having to specify dozens of dimensional constraints, directly proceed to generating a solid feature, and if and when desired return to the sketch at any time to add some or all constraints.
bulletCoupled relationships can be simply viewed as:

a = f(b) and b = f(c) and c = f(a)
bulletIn spreadsheet programs, these are usually called 'circular references' and if the user asks for these to be considered, then the spreadsheet program solves the equation set simultaneously rather than sequentially.

Does coupling ever happen in practical engineering? Consider two dimensioning schemes for a triangle (perhaps representing the cylinder centers of a 3 piston engine). First dimension the triangle 'side-angle-side':

This is an uncoupled situation because the problem can be solved sequentially by:

bulletstarting at pt1, draw a horizontal line of length s1
bulletdraw a line at angle a to the first horizontal line (of 'infinite' length)
bulletmeasure distance s2 along the second line, and then draw the third edge of the triangle.

Both a parametric and variational approach can solve such uncoupled cases.

Now consider a 'side-side-side' dimensioning scheme (perhaps our key design objective is to carefully position the piston centerlines at fixed distances from one another):

This is a coupled condition because steps 2 and 3 cannot be solved sequentially but rather must be solved simultaneously, in this case for the intersection of the two circles to find pt 2 and hence define the desired triangle.

Only the variational approach can solve such coupled cases.

In addition to these issues of partially/fully constrained and coupled/uncoupled, variational and parametric approaches often differ in the way they handle geometric constraints (e.g. parallel, tangent, colinear, perpendicular).

bulletIn the parametric approach these constraints are usually handled as 'implied constraints' based on the current state of the design variables (e.g. two lines meet at 'close enough' to 90 deg to be considered perpendicular), wherein the number of equations and variables are reduced each time one of these constraints is deduced. If the design engineer wants to change the constraints (e.g. change perpendicularity to a 2 degree draft angle), then because of the implied constraints he is forced to delete geometry and resketch (e.g. delete one of the perpendicular lines, sketch a new line that is angled enough to be outside the perpendicularity snap).
bulletIn the variational approach constraints are stored as 'explicit constraints' and treated as boundary conditions in the simultaneous equation solution. The advantage of the explicit constraint approach is that the user can apply, delete, or modify his desired constraint scheme at any time in the design process (e.g. delete a perpendicularity and add a 88 degree angular constraint to represent draft angle) without having to delete geometric entities and resketch.

In summary, it's clear from our discussion that the mathematics of the variational approach are a superset of the parametric approach. The more general variational approach provides the design engineer with the following important benefits:

bulletto be more productive (and more natural) because of the ability to represent and solve partially constrained problems.
bulletto handle a broader class of engineering problems, including those with coupled geometric and engineering relationships.
bulletto provide a more understandable and productive way to define and change the design problem, because of explicit handling of design constraints.

Remember that our discussion has focused only on the mathematics behind each approach, and not how these approaches might be implemented in a particular software system. In fact, it is certainly possible to add certain special case variational elements to a system that has as its foundation a parametric approach. However, at SDRC, we chose to implement the variational approach as a foundational element of the I-DEASTM system and believe strongly that all successful mechanical design automation systems will follow this lead.

 
Back Up

back to WAMware homepage®
Copyright © 1996-