Multirepresentation

In 3DEXPERIENCE, 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.

The Business Logic is defined in database: it appears in the Knowledge Business Logic tree under the "Business Rules - Coexistence Business Logic" node. This tree can be accessed through the Compass: Quality Rules Capture

This page discusses:

3DEXPERIENCE Multirepresentation vs. V5 Multirepresentation

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

3DEXPERIENCE Representation ModelV5 Representation Model




When running the DownwardCompatibility batch on a 3DEXPERIENCE 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

Multirepresentations are 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.

Defined Main Representation

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:



Undefined Main Representation

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. This needs to be managed in a Business Logic script defined for MainRep criteria. For details, see MainRepresentation Valuation Business Logic Openness Implementation.



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 after adding 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 3DEXPERIENCE data has been modified since the last conversion operation, the converted V5 CATShape is opened and synchronized with the 3DEXPERIENCE modifications.

In addition to this, CATShapes support the delta mode mechanism: when the original 3DEXPERIENCE 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 ownership can be transferred from 3DEXPERIENCE to V5 and from V5 to 3DEXPERIENCE 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 3DEXPERIENCE to V5 of a CATShape.
  • A V5 CATShape cannot be imported to 3DEXPERIENCE 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 3DEXPERIENCE but in that case, links to this CATShape are isolated. To solve this, you can use publications.