Wednesday, June 3, 2009

PDM and the History Tree

As you would expect, I take whatever opportunity comes alone, with whoever is willing to listen, to explain the benefits of history-free CAD. As such I get to hear many reasons why history-free CAD will not meet a person’s particular requirements. Some of these reasons are certainly valid based on their product characteristics and/or design process. Some, on the other hand, are, well, puzzling to say the least. It is amazing what some people believe that the history tree is doing for them.

One of the frequent and more “puzzling” reasons that I hear for needing the history tree is; “I don’t want anyone to be able to change my model”.

Wow! There are so many things wrong with this statement I’m not sure where to begin.

First of all, the history tree technology (CSG) was originally leveraged into 3D mechanical CAD to make the editing of models easier and more predictable, as compared to the ridged editing capabilities of the old B-Rep CAD systems. When did it become a method for restricting edits? It is true though, you can organize the history tree and constraints to make only specific edits possible. But then if you actually have access rights to make these very specific edits, you also have the rights to reorder the tree, or even corrupt the tree? Strangely enough, you most likely also have the rights to delete the file. Whether intentional or by accident, the model can be changed. Since when did the history tree become some form of data management?

Maybe these people are simply referring to the use of the history tree to capture and somehow communicate their design intent. If this is the case, we should consider how many people within the team and throughout the enterprise need to understand this design intent. And of those, how many have the skill to properly evaluate a history tree to accurately assess the intent. Of these people, how many should have access to the native CAD data? I think the number will get real small, real quick. We have been capturing and conveying design intent via 2D drawings ever since humans have been inventing stuff, and 2D drawings will continue to be the preferred method for many years to come. Model Based Definition may catch on at some point, but MBD does not require a history tree. What unique design intent is captured in the tree? And how does it get communicated to the greater enterprise?

I suppose that there are some that would tell me that what these people really mean is that they want to make sure that IF the model is changed, i.e. a boss is moved on one part, the mating feature on another part is updated accordingly. If that is the case, they are confusing the history tree with parameters and constraints. And please don’t assume that just because these relationships exist, you don’t need to check the results. Relationships and parameters can be changed, removed and even broken - and now we are back to data management.

Maybe I am missing something here, but it seems to me that there is a tendency to believe that a nice looking, well constrained 3D CAD model with a well structured history tree somehow implies “security” and “completeness”. Bottom line: if you think the history tree is somehow protecting your model/assembly, or perhaps somehow controlling and communicating intent, you’re at risk, (in so many ways).

Paul

4 comments:

Matt said...

Paul,

I have a feeling what that person meant in saying that was that was one of the reasons they didn't want to deploy direct editing at their company. They wanted to send out a translated model and make sure that no one effed with it. You may be familiar with a certain CADCAM terrorist who is fond of claiming that machinists need to change engineers parts to make them cheaper. That is the kind of thing that anyone who is responsible for a design fears. Letting just anybody make changes to models has its downside.

Darcy said...

Hi Paul,

You make some good points. You are right that the parametric/feature based/associative CAD users really mean they want to preserve their design intent. That's what I care about most. Design Intent captures rules which are, roughly speaking, organized into features, parameters, constraints and dimensions.

It is popular to use the term 'history based'. But in reality it's not all history and I think the term can be misleading when comparing explicit modeling.

A simple example would be considering the design intent captured in a sketch. There is no history in a sketch. Instead there are is an unordered set of sketched entities, dimensions, and constraints. Internally the CAD tool builds a graph of the relationships between the entities and constraints (as in topology not a plot). A topological sort of the graph then tells the CAD system the sequence of calculations required to solve/regenerate what the sketched shape must look like.

Features in the model tree do appear to have a history to them... so it is understandable where the term comes from. It's more valuable to consider the dependency relationships between features which is not the same as a sequential list that the model tree implies.

BTW: I found your blog while reading your recent comments on dezignstuff.com about dumb geometry. Your comments were great. Also, I am a fellow PTC employee. Next time you're in Needham, stop by my office. It would be great to say hello and chat.

Darcy said...

On a related noted... maybe you could answer the following question in a blog entry or email?

I am interested in the origins of the term 'explicit' modeling. I have some confusion because I have heard it explained that explicit modelers are based on explicit equations of surfaces and curves, and that parametric modelers use implicit equations. (The implied logic seems to be that since Parametric modeling is different than explicit modeling, then it must be using the other type equation - implicit.)

This doesn't seem right to me, because I understand an explicit equation to be in the form y=f(x). Whereas an implicit equation is of the form f(x,y)=0. Parametric equations, x=x(t), y=y(t), z=z(t), are a type of explicit equation.

I think I understand many of the features/capabilities of an explicit modeler and their semantic differences to a parametric modeler like Pro/E. But I would like to reconcile the conflict in my understanding of the term 'explicit' as used in the math sense and as use when speaking of explicit modeling.

Perhaps I am being picky about the use of 'explicit' and there are multiple definitions... but I wondered if you had insight into the 'explicit modeling' name?

Paul Hamilton said...

Hello Darcy.

Thanks for your comments. I look forward to meeting you sometime and will look you up next time I'm in Needham.

I like your comments about the sketch. This is similar to what is being done directly in the 3D B-Rep within history-free direct modeling.

The term "Explicit" is one of those, like "hybrid", that will have many different meanings depending on the context. At CoCreate we never used the term. After the acquisition, PTC applied the term to CoCreate Modeling. The term was used in the early days of CAD to differentiate a B-Rep modeling system from a CSG systems, and I think that this is the context that PTC came to use the term again. In that context I believe that it is more related to that fact that a user must be “explicit” or “specific” in the interaction with the geometry. I don’t believe it had anything to do with the actual math behind it.

I personally don’t like the use of the term in this context simply because the direct history-free technology has matured to the point that you don’t always need to be explicit in the interaction with the geometry. There are many ways now to add intelligence to the B-Rep to help reduce the need for explicit or specific interaction with the geometry – when desired.

While history-based systems are becoming more flexible, (explicit), history-free systems are making it possible to intelligently control geometry, (less explicit). (maybe the start for a new post)

Paul