Multirepresentation

In V6, a multirepresentation is a set of several representations defined on a given reference. These representations can be a 3D shape, a model, a cgr or applicative data (e.g. DMU, FTA data).

Note that Designer Central and SmarTeam do not support multirepresentation.

V6 Multirepresentation vs. V5 Multirepresentation

V6 and V5 representation models are a bit different, which has an impact on the way references are converted by the DownwardCompatibility batch.

V6 Representation Model V5 Representation Model




When running the DownwardCompatibility batch on a V6 reference, the representations under the reference are converted as follows:

  • 3D shapes/2D drawing representations are converted to CATParts/CATDrawings.
  • Model/V4 representations are kept as .model documents.
  • Cgr representations are converted to cgr documents.
  • Other representations are not converted.

Multirepresentation Conversion with the DownwardCompatibility Batch

Multirepresentation is converted by the DownwardCompatibility batch.

It is assumed that even if multiple representations exist, only one can be seen as the main representation. Other representations are seen as alternate shapes of this main representation.

A main representation is a 3D representation (other supported objects for conversion such as cgr representations, models or 2D drawing representations cannot be defined as a main representation) and can only be defined under a terminal reference. A terminal reference may or not contain a main representation but when a main representation exists, it is unique under the terminal reference.

For a terminal reference (i.e. a Product Structure node without any child reference), the data conversion works as follows:

  • The main representation is converted to a CATPart.
  • Other 3D shape representations are converted to CATShapes under the CATPart.
  • Other references are converted to a CATProduct and 3D representations are converted to CATShapes directly linked to this CATProduct. Therefore, associativity is kept.

    Note: If there is no main representation, other 3D representations are converted to CATShapes attached to the CATProduct.

  • Model or cgr representations are attached as alternate representations.
  • If the terminal reference contains more than one main representation, the conversion process fails and an error message is displayed to indicate that there is an ambiguity regarding the main representation, which causes a multirepresentation conflict.

Main Representation Defined in Settings

The multirepresentation is converted to one CATPart (the one defined as the main representation) and several CATShapes defined as alternate representations.


  • Creation of:
    • A CATPart for the main representation linked to the CATProduct.
    • Alternate shapes (CATShape, .model, .cgr).
    • Isolated drawing representations (without any link to the main product) for all 2D drawing alternate representations.
  • Publications in the main representation are transferred to the corresponding CATPart.
  • Publications in alternate representations are transferred to the main CATPart.
  • PLM attributes are mapped from the product reference to the corresponding V5 added properties in the CATPart and the CATProduct.
  • There is no symmetry with FBDI for additional representations. If such a structure is created in V5, the result of the FBDI operation will be different.

Below is an example of the conversion of a reference with a multirepresentation:



Main Representation Not Defined in Settings

In that case, a default behavior is applied.


  • Creation of:
    • A CATPart (.model or .cgr) for each representation (except 2D drawing representations). Only the first CATPart of type Definition is linked to the CATProduct.
    • Isolated drawing representations (without any link to the main product) for all 2D drawing alternate representations.
  • PLM attributes are mapped from the product reference to the corresponding V5 CATProduct properties.
  • There is no symmetry with FBDI for additional representations.

The HTML report for the batch execution indicates that the default behavior has been successfully applied and the batch successfully ends with the warning: "NO MULTIREP CRITERIA DEFINED".

Terminal reference with a main representation

When the terminal reference contains a main representation, it must be unique. Otherwise, an error message is displayed when running the DownwardCompatibility batch to indicate that there is a conflict.



Regarding representations defined under an intermediate reference, they are converted to alternate shapes attached to the CATProduct:



Terminal reference with no main representation

In that case, the conversion result depends on the structure and number of representations under the reference.

For a multirepresentation reference, all representations are converted to CATShapes attached to the CATProduct:



For a monorepresentation (I.e. a reference with only one 3D representation), the representation is converted to a CATPart:



If the monorepresentation is updated afterwards to add a main representation, then the former representation will be converted to a CATShape and attached to the main CATPart. Therefore, the main representation might change:



CATShapes

A CATShape is an existing V5 modelization containing the same data as a CATPart, except a product container. CATShapes are converted according to specific rules.

Naming

The naming rules applied to names converted CATShapes are the same as for any other converted object: the converted CATShape is named according to the PLM_ExternalID of the reference, except when converting a representation (in that case, the CATShape is named according to the PLM_ExternalID of the representation).

Associativity

The DownwardCompatibility batch keeps the associativity on all exact representations (creation of a copy with link). For other types of representations, such as cgr, the content is removed and recreated.

Converted V5 CATShapes can be synchronized. When the original V6 data has been modified since the last conversion operation, the converted V5 CATShape is opened and synchronized with the V6 modifications.

In addition to this, CATShapes support the delta mode mechanism: when the original V6 object has not been modified AND the converted V5 CATShape already exists in the receiving site, then the object does not need to be processed (i.e. converted or updated) or saved.

Ownership Transfer

The ownsership can be transferred from V6 to V5 and from V5 to V6 through a dedicated batch named CoexistenceAdministration.

When running the CoexistenceAdministration batch, CATShapes follow the following basic representation ownership rules:

  • It is not possible to transfer the ownership from V6 to V5 of a CATShape.
  • A V5 CATShape cannot be imported to V6 through FBDI (or DBDI). This means that you cannot have a CATShape as V5 Master in the coexistence mapping table, whatever the coexistence context used.
  • If the result of the DownwardCompatibility batch contains a CATShape used in V5 in a contextual design, then the new V5 data can be imported to V6 but in that case, links to this CATShape ae isolated. To solve this, you can use publications.

Identification String

An identification string is a list of attributes' values separated by a string. It is used to name the documents and to valuate the PartNumber of CATPart documents. You can define an identification string for each representation reference. Identification strings are defined in the advanced options of the DownwardCompatibility batch.

When defining the identification string, note that if an attribute does not exist for a given representation, the value assigned to this attribute will be considered as empty. This might occur, for instance, if the identification string has been defined on a representation with a specific customization, and the current representation does not belong to the same customization.

Regarding the identification string's impact on V6 data, only the V6 mapping data information saved from previous representation conversions is concerned. As a Ref_PLM_ExternalID.CATPart has been created for any representation in the mapping table by previous conversions, running the DownwardCompatibility batch on such data with the same mapping context might change the name of the V5 document from Ref_PLM_ExternalID.CATPart to IdentificationString.CATPart.

Identification String is Not Defined

This is the default behavior which corresponds to what happens when the Identification String box is left empty. This behavior is as follows:

  • IdentificationString=Rep_PLM_ExternalID (PLM_ExternalID of the selected representation) when the selected object to convert is the representation.
  • IdentificationString=Ref_PLM_ExternalID (PLM_ExternalID of the selected reference) when the selected object to convert is the reference.

Let's suppose the following V6 structure:



where the main representation criterion is "OBF=DENO".


  • CATPart's PartNumber = Reference's PLM_ExternalID
  • 3D representation's document name =
    • Reference's PLM_ExternalID for the CATPart corresponding to the main representation
    • Representation's PLM_ExternalID for other 3D representations
  • 2D representation's document name = Representation's PLM_ExternalID
  • All leaf reference attributes are processed as "added properties" in the CATPart corresponding to the main representation.

When converting this V6 structure to V5, 3 documents will be created:

  • Ref-Root.CATProduct
  • Ref-Leaf.CATPart (Added properties are valuated with the reference attributes' values)
  • Rep2.CATShape.



Important: There is no way to display the values assigned to the attributes of Rep1.

Identification String is Defined

In that case, a string has been entered in the identified with string box.

Let's suppose the same V6 structure:



where:

  • Main representation criterion is "OBF=DENO"
  • Identification string = {PLM_ExternalID + "-" +OBF}


  • CATPart's PartNumber = IdentificationString
  • 3D representation's document name = IdentificationString (this is the case for CATParts, CATShapes, V4 models and cgr documents
  • 2D representation's document name = IdentificationString
  • All leaf reference attributes are processed as "added properties" in the CATPart corresponding to the main representation.

When converting this V6 structure to V5, 3 documents will be created:

  • Ref-Root.CATProduct
  • Rep1_DENO.CATPart (Added properties are valuated with the reference attributes' values)
  • Rep2_VOAL.CATShape.



with the following V5 display customization defined in Tools > Options > Infrastructure > Product Structure > Nodes Customization:



Ports and Publications

Ports are created in V6 but are managed as publications. Publications defined for references with a multirepresentation can be exported to V5.

Two types of ports can be exported through the DownwardCompatibility batch:

  • Ports defined under a V6 terminal reference (i.e. a reference without any child) linked to the geometry of a CATPart or a CATShape.
  • Ports defined under a V6 representation are exported either to CATParts, or to CATProducts associated with CATShapes. These representations can be instantiated in intermediate references.

These ports are defined on terminal geometry or on terminal geometrical sub-elements.


  • A CATShape document cannot contain any publication definition. Therefore, if a representation reference with geometry pointed to by a port defined in the same representation is exported to a CATShape, then the V5 publication will be created inside a CATProduct or a CATPart and will be linked to the CATShape geometry:



  • If the same representation reference is exported to a CATPart, then the V6 port will be exported to the resulting CATPart:



  • The V6 port defined under a representation reference and the V6 port in the parent reference are exported under the same V5 product container. Therefore, if several V6 ports can be exported from different product structure levels under the same V5 reference, this might create publications with identical names. To avoid this, a port under a representation reference is exported with a V5 name which is the V6 name suffixed by the identification string of the representation reference it comes from. For a port under a terminal reference, it is exported with a V5 name which is the V6 name without any suffix.

    If no identification string has been explicitely defined, the PLM_ExternalID of the representation reference is used.

  • The DownwardCompatibility batch cannot create ports of a port (this could occur in case of a port defined under a terminal reference linked to another port defined under a representation reference). This means that the port of a port will not be exported and you will only get the port from the representation reference. This avoids the creation of two publications linked to the same geometry.
  • When exporting to the same V5 document two ports from two different product structure levels (a terminal reference and one of its associated representation references) linked to the same geometry, note that both ports are created and no check is performed.
Important:
  • Ports of parameters are not exported.
  • Ports of sub-geometrical elements which have been relimited on the final brep are not exported.
  • Ports of intermediate geometry are not exported.

Example 1

Three ports are defined under a terminal reference: two of them are linked to the geometry of a 3D shape and the other one is linked to the geometry of the previous ports (therefore, it is a port of a port).

There is also a port on the representation. This port has already been used by a port on a reference.

All these ports are exported as publications to V5, except the port of a port.



Where:

  • Main representation criterion is OBF = OBF2
  • Identification string = OBF.

In V5, only publications defined under a main representation will be resolved. Publications defined under alternate representations will only be resolved after opening the CATShape or activating the CATShape through the Manage Representations command. Loading the CATShape using File > Desk is not enough to resolve publications defined under alternate representations because this does not open the geometry in session.



Example 2

Two ports: one is defined under an intermediate reference, and the other one is defined on the representation on the intermediate reference.

Only the port defined on the representation is exported.



Where Identification String = OBF.



Associativity

Impacts are identified during synchronization:

  • If there is a naming confilct between a publication to be created by the DownwardCompatibility batch and an already existing V5 publication (not created by the batch), then the V5 publication is removed. Otherwise, the V5 publication is kept.
  • If the V5 document type changes, new V5 documents will be created without the already created publications. Therefore, the publications will be created again, except some of them which will not be created because of the type changes.
  • Other deletion, creation or update criteria remain unchanged.

XML File

The following tags dedicated to multirepresentation management are displayed in the XML file.


  • <CATDWC_MultiRep_Value> contains the string (MAINREP) identifying the main representation versus the alternate representation. To limit the impact on existing XML files which do not contain this tag (e.g. from a previous version), the default option is used: when editing the XML file, the tag can be valuated using ${VARIABLE}. A null value means that the default behavior applies.
  • <CATDWC_MultiRep_Attr> contains the attribute (TYPREP) identifying the main representation versus the alternate representation. To limit the impact on existing XML files which do not contain this tag (e.g. from a previous version), the default option is used: when editing the XML file, the tag can be valuated using ${VARIABLE}. An invalid or null value means that the default behavior applies.

    This tag appears only when no default value is applied, i.e. when the tag <CATDWC_MultiRep_Value> is not used to limit the impact on existing XML files.

  • <CATDWC_PartNumber_Identifier> contains the list of attributes (and the separator string) used to name the PartNumber of 3D representations and alternate shapes. To limit the impact on existing XML files which do not contain this tag (e.g. from a previous version), the default option is used: the batch behaves as if no identification string has been defined.

    When editing the XML file, the tag can be valuated using ${VARIABLE}. An invalid or null value means that the default behavior applies.

    Warning: This tag appears in the XML file only when an identification string has been defined in the advanced options of the DownwardCompatibility batch.