To clarify…. When Deelip mentions localized rebuilds, he's not referring to the solver. What he's trying to describe is something PTC built into Pro/E a few years back (2002 or 2003) which we called "Intelligent Regeneration".

In the past in Pro/E, and I expect in most other history-based systems, when a user modified, say feature 5 out of a 100 feature part, Pro/E wouldbegin the regeneration process at feature 5, and update features 6, and 7 and 8 and so on all the way up until 100. This ensured that the changes due to previous feature updates were propagated throughout the model. It's a logical, and conservative approach, but in some (many?) cases, it is inefficient.

By analyzing the impact of feature modifications on surrounding topology (not just child features in the traditional "referencing" sense, but the identification other feature that might be affected by changes to the geometry, even though they are not direct child features), PTC was able to eliminate unnecessary updates to features which were not affected by the change. So instead of updating features 5 through 100, maybe features 5 through 8 were updated, and 61 through 72, but not any of the others since there was no need to update them.

This change resulted in some pretty significant regeneration reductions (of course, this varies, depending on how your model was constructed), which helps customers get their jobs done better and faster!

~ Mike

To clarify…. When Deelip mentions localized rebuilds, he's not referring to the solver. What he's trying to describe is something PTC built into Pro/E a few years back (2002 or 2003) which we called "Intelligent Regeneration".

In the past in Pro/E, and I expect in most other history-based systems, when a user modified, say feature 5 out of a 100 feature part, Pro/E wouldbegin the regeneration process at feature 5, and update features 6, and 7 and 8 and so on all the way up until 100. This ensured that the changes due to previous feature updates were propagated throughout the model. It's a logical, and conservative approach, but in some (many?) cases, it is inefficient.

By analyzing the impact of feature modifications on surrounding topology (not just child features in the traditional "referencing" sense, but the identification other feature that might be affected by changes to the geometry, even though they are not direct child features), PTC was able to eliminate unnecessary updates to features which were not affected by the change. So instead of updating features 5 through 100, maybe features 5 through 8 were updated, and 61 through 72, but not any of the others since there was no need to update them.

This change resulted in some pretty significant regeneration reductions (of course, this varies, depending on how your model was constructed), which helps customers get their jobs done better and faster!

~ Mike

It's a function of the design of the solver. The Pro/E solver was parametric, while the IDEAS solver was variational.

In any event, before swearing to this, I'd need to do a little homework. (I could be off on the date, and the solvers of that time may have used hybrid methods.)

Now, as for whether customers want parametric feature-based modeling, or direct feature modeling: I think what they want most of all is to get their jobs done better and faster.

Let me know if you have further questions. I’m just a tweet away.

Dora Smith
Siemens PLM Software

My opinions are based on Solid Edge, because that is all I have access to. Siemens has spoken about giving me a demo of NX, but for some reason or another, it has not yet happened. That's the reason I try and avoid mentioning NX in my writings.

Thanks for the clarification. And this is precisely the reason why I allow anonymous comments on this blog.

The availability of ST FEATURES as tools in a history-based model has proven, over and over, to be extremely valuable in our organization.

It is very unfortunate that the differences in implementation of ST between NX and Solid Edge are being confused (by everyone, from Siemens to the blog media etc).

There's very good reasons why a shift towards the sync tech is a good idea and its going to take time to shake out and see where it goes. Kudos to Siemens for having a stab at it. Is it a wise decision? Only time will tell that. Personally, I think they made too much of a deal about it as its a very embryonic technology – yeah, one that's getting a lot of development resources, but embryonic still.

If they made a mistake, its making such a huge noise about the move to sync tech-based modelling technology, I've heard of users reevaluating their Solid Edge licenses, some even dropping it and moving to another direct editing system that's more mature. Why? because of this notion that history is being dumped.

I understand that Siemens is not abandoning feature based modeling. Synchronous Technology has features, parameters and constraints, as I have mentioned time and over on this blog. But to me it looks like they are abandoning history based feature modeling. There is a world of a difference between feature based modeling and history based feature modeling. That's why I made sure I added the phrase "history based" to my statement.

Al, come one. You have been around far more than I have. In the software world, "shifting development focus" equals "abandoning". This is typical press release lingo and you should be more equipped to read between the lines than me.

Thanks for clarifying about PTC – "realtime recalculation of history based model" in Wildfire 5.0 and "Direct Modeling" in WildFire 6.0. The PTC guys were not very forthcoming in giving me information at that point in time. They just wanted me to see what they were showing and not ask questions.

I think that's a pretty irresponsible thing to say – mostly because its inaccurate. you're mixing two things. History-based model construction and Feature-based model construction. Sync Tech is feature-based modelling – without a history. So you can't lump the two in together Deelip.

As as far as I can see, Siemens aren't abandoning either. shifting developmental focus towards a history-free approach – but even then, if you look at NX, then the Sync Tech implementation, certainly is both history and feature-based – just not as reliant on it as might be obvious.

as for PTC's approach, there are two things at play. realtime recaclulation of a history-based model (shipping in Wildfire 5.0) to give dynamic feedback of dynamic edits – while explicit modelling (ala) CoCreate will be in a later release.

If you're going to wax lyrical about the subject, ensure you've got your terminology correct, otherwise it confuses the user community and that's not in anyone's interest.

Cheers

Al