≡ Menu

3 Master Model Concept Misconceptions

Share the knowledge

If you’re around NX for very long you’ll hear someone talk about the Master Model concept. It is an important concept. It comes up in the various forums from time to time. Usually when people as, What is the master model concept? There are no shortage of answers offered. But I feel that most of the discussions miss the mark. I think there are a lot of misconceptions about the Master Model Concept. I am going to try to clear some of them up.

Master Model Definition

If I’m going to discuss what people get wrong about the Master Model Concept, I should at least try to provide a definition of what it is. Here is how I define it

Master Model Concept:

A method of separating a CAD model definition from data which is dependent upon the CAD model but does not define the CAD model itself. This separation is achieved by storing the CAD model definition, called a Master Model, within one file and each piece of dependent data within separate files which refer to the Master Model, typically by including it as a component within themselves. Typical examples of dependent data types are drawings, machining tool path definitions, and FEA analyses.

Now, on to the misconceptions.

Master Model Misconceptions

These are the misconceptions that I feel people have.

1. The Master Model Concept is Only for Drawings

Drawings are the first place most of us encounter the MMC. Unfortunatley many people think this is all the MMC is about. In the early days of Unigraphics, there was but one file, and it contained your geometry and your drawing. Then UG gave us the ability to create assemblies. Soon someone figured out that you could the geometry in one file and the drawing in another. And then the word spread that drawings did not have to be embedded into the same file as the model.

But that’s not the only thing you can do use MMC for. You can have a separate file for your manufacturing tool path information too. And another file for your FEA analyses. Any type of work you need to do that is driven by the model but does not influence the model can (and should!) be broken out into a separate file that references the master model.

2. The Master Model Concept is about reducing file sizes

The second misconception I hear is that the main benefit of MMC is that it reduces your file sizes. Drawings and tool paths and FEA meshes can be consume a lot disk space, so by separating them out from the model file you make your models easier to work with.

That is a benefit. I agree with that.

I just don’t think it’s the primary benefit.

I think the primary benefit is that MMC decouples your model file from your drawings, machining files, and analysis models. Decoupling is a word that is used in software engineering fairl regularly. However, if it’s used in terms of CAD modeling, I’ve not heard it. Decoupling means to take a system and divide it into logical self-contained units which share only what they need to share with each other through well defined channels. For example, drawings do not need to know the model tree for the geometry. It makes no difference if that hole was created with a feature or by extruding a sketch. All the drawing needs to see are the faces and the edges. Likewise, the model does not need to know that the drawing even exists.

So here’s another point about MMC:

The flow of information in MMC is from the master model and to the dependent files.

So, why is this A Good Thing?

Protecting model integrity

No, I’m not talking about protecting the reputations of Victoria’s Secret models. I mean that there is nothing you can do to the drawing, tool paths, or FEA analyses that will damage the master model.

If you had everything in one file, could you be sure that you wouldn’t inadvertently make an unintended change to the model when you were only supposed to be updating the drawing?

Parallel work efforts

A second benefit of decoupling the model from the dependent files is that you can now divide the work effort into parallel tracks. One person can be working the model while another starts on the drawing and a third begins to prepare the tool paths.

Separate life cycles

Since the model and drawing and machining and analysis files are separate they can be submitted to different workflows for review and release. The engineering group can review the model, the drafting group can review the drawing, manufacturing, the tool paths, etc.

Independent changes

The different files can be revised independently. A change to a note on the drawing does not require the model to be changed. Nor does a new analyses. And changes to the model that do not affect the other files do not require them to be updated. For example, there’s no reason to update a tool path because someone added a new reference set to the model.

3. In Teamcenter the Dependent Models Must be Manifestations

The standard implementation of Teamcenter puts the master model in a UGMASTER dataset that is attached to a item revision with a Specification relationship. Then, additional datasets for the other models, like the drawing, are put in UGPART datasets that are attached to the same item revision but with a Manifestation relationship. Some people seem to think that this is what MMC has to look like in Teamcenter. But there are other solutions. For example, the drawing could be in its own item revision under a different item. For more on this topic, see this post on different ways of storing drawings in Teamcenter

Closing Thoughts


If anyone knows the history of who first came up with the master model concept, please share. (Paging John Baker…)

Be Consistent

I endorse using the MMC for all files. I know that some people feel that for really simple models that the drawing should be embedded in the model file. Personally, I feel it’s better to just consistently use one approach. If you’re going to use MMC in some cases (and you should), just use it in all cases.

Watch out for the WAVE

Interpart relationships, particularly WAVE relations, can turn the MMC upside down. Watch out for any relationship that makes a master model dependent on something that happens in the derivative file(s).


Have I missed any misconceptions? Do you disagree with my choices? Leave a comment, below.

Was this useful?

If so, please share, and endorse (+1, Like, etc.) on your social network of choice.
If you feel I’m mistaken about or missing something, pleas share your thoughts in the comments.

  • srinivasan r

    Insightful ! Is the MMC applicable for Pro E and Catia models (or any other for that mater) as well?

    • http://plmdojo.com/ Scott Pigman

      Regarding Pro E and Catia, I have to qualify my reply since I haven’t worked with those systems, but from what I know or think I know about them MMC is actually built into them because they use different file types (extensions) for different types of files, where as NX has only one, .prt.

      As for the separate lifecycles question, I think you’re assuming a data model that looks like,

      – Item Revision
      – Model Dataset
      – Drawing Dataset

      which would make it difficult to set up independent lifecycles for the model and drawings. I would expect that instead you’d have a data model that looks like this:

      Model Item
      – Model Item Revision
      – Model Dataset

      Drawing Item
      – Drawing Item Revision
      – Drawing dataset

      and then you’d be able to send the item revisions and their datasets through separate workflows.

      • srinivasan r

        Thanks for the reply Scott !! That helps.And i fully appreciate this site and the articles you post.This opens all the unknown aspects of PLM to users. Thanks !!

    • Dustin Neifer

      There is a “master model” concept for Pro/E (e.g. Creo) however it’s not the same in nature as what is being discussed here relative to NX. In Pro/E it is also described as “top down design” and builds referential relationships between separate files. Certain Pro/E functions are such as copy geometry, envelopes, inheritance, publish geometry, etc. are typically used in those cases.

      Our practice is to keep MCAD drawings and the model they depict in revision letter lockstep so the datasets are parked under the same item revision. UGPART and UGMASTER, ProDrw and ProAsm, ProDrw and ProPrt, etc.

      I’ve never had the pleasure of having to deal with CATIA. Sacré bleu!

      • http://plmdojo.com/ Scott Pigman

        I think that the master model concept as NX uses it is implicit in ProE’s file types — Your ProPrt or ProAsm files would be the “master” file and then your ProDrw would be the “manifestation” that refers back it.

  • Teamcenter Heretic

    IMHO, the only downside to the method where the drawing is a single part assy of the model is that you have to fabricate some stupid convention like 12345_DWG.
    with the V10 concept of compound id that disadvantage goes away and I cannot imagine why anyone running Nx (is there really any other CAD system?) would want to stick with the UGMASTER/UGPART method.

    Even the Part/Design/Drawing scenario makes great sense in V10!!

    Cant wait to use my ITK skillz to begin re-identifying all those legacy items when V10 gets here ;) I love POM calls!!!!!

  • http://www.facebook.com/randy.ellsworth Randy Ellsworth

    Excellent article as always Scott.
    To add a little to the “benefits” section. By creating a separate Mfg Part (Item and Revision) for tool paths and using a manifestation relation allows a Mfg Engr to regenerate those paths without “revising” the model. This is needed if a tool wears down or is replaced with a new tool. Since the Mfg Part doesn’t affect the geometry of the model (doesn’t describe it) then there is no reason to revise the model. By default, a manifestation isn’t released, allowing the dataset to be modified without revising.
    A mistake some companies make is to add manifestation to the release workflow which locks it down and prevents modification without revising it first. Basically turning a manifestation into a specification.

    • http://plmdojo.com/ Scott Pigman

      Thank you for the insight about manifestations (and for the compliment :-)

      In your view, is there not a need to lock down the tool paths at some point and control when and how they are updated, even if they are updated separately from the master model & revision? I’m imagining possibly having a workflow that only accepted and statused UGPART datasets — but then i don’t know how you’d “revise” just the dataset.(unstatus it and create a new version?)

      “Manifestations — what are they good for?” might be a good topic for a discussion.

  • Teamcenter Heretic

    Manifestations are a kludge at best IMHO.

    The fact that a manifestation does not get locked down is both a blessing and a curse.
    Just go find one of those really important released CAD models and cut/delete the manifestation with those many man weeks of NC programming it in… Viola!!

    Also, where used does not report manifestations that reference their master so if the relation gets cut you are hosed.

  • Don Knab

    I think the whole implementation for MM in NX and TC is a little kludged.

    In NX there’s sort of a child/parent assembly relationship thing going between models and drawings.
    In TC they’ve hidden the assembly relationship (where used), and then implemented another relationship to suffice.

    I can see the TC developers when they had to implement it:
    Developer#1 – OK folks, this is what they’ve given us. We need to find a way to make “this” fit into the whole which “that” fits in, using only “these” (Apollo 13).

  • Dustin Neifer

    I still find the default NX dataset type naming in TcUA to be confusing:

    UGMASTER = assembly model *or* part model

    UGPART = drawing

    A part is a drawing? OK …

    • http://plmdojo.com/ Scott Pigman

      It’s the result of having a single .prt file type all types of files. I haven’t heard of any other CAD programs that that use a single file extension.

      UGPART could be something other than than a drawing too. And if you store drawings under their own, separate, items then they’ll be UGMASTERs too.

      Not differentiating between assemblies or parts is a good thing, IMHO. Too frequently designs start as one and then evolve to the other.

    • Teamcenter Heretic

      Uh, what is this thing called UG? Is it related to iMAN?