Mechanical Modeler

Configuration and Versioning

Ascendant Stability in Build Process and Mechanical Behaviours
Technical Article

Abstract

Mechanical Modeler and Geometrical Modeler have several internal algorithms to manage generic naming,topological operator etc...

For many reasons (enhancements etc...), those algorithms may change. As side effects, some behaviours could not be exactly the same after the code modification.
A solution to keep stable and defined behaviours on your feature is to version them.

The aim of this article is to make an overview of versioning in Mechanical Modeler and to describe the steps needed to version correctly a Mechanical Feature.

To take full advantage of this article, it may be interesting to have a look at the "The Versioning of the Topological Operators" article [1]

Why versioning? - Software Configuration

Mechanical Modeler and Geometrical Modeler have different internal algorithms, which differ from software releases.
Consequently, Mechanical Feature instantiated, inserted in MechanicalPart, and built on a specific date, should -potentially- have different behaviours when it is used on new software level.

For instance, between "CATIA Rxx" and "CATIA Ryy", BRep behaviors could have changed, which could impact visualization or Colorization.

Example of Colour Behaviors between "CATIA Rxx" & "CATIA Ryy"

"In CATIA Rxx"

"In CATIA Ryy"

To keep the same behaviours on your mechanical features, release after release and build after build, it is necessary to version them when they are instantiated and built.

This is done setting and storing the CATSoftwareConfiguration on the feature.
This Class defines the software (Algorithm) configuration which is a set of code modifications and a level on which the code must be run.

With this data stored on the instance, feature's update and mechanical behaviours will be the same as at the first time it was instantiated and built !

In deed, for example during the build step, retrieving the CATSoftwareConfiguration stored on the feature, you will determine the CATTopData to use on TopologicalOperator and the level of Mechanical Modeler (and CGM ) algorithms to execute in order to retrieve the same behaviours as the first time you build the feature.

Þ  In Consequence, versioning your Mechanical Feature guarantees ascendant stability and continuity in your parts: there will always be the same build for your feature as at the first time whenever you call it!

[Top]

What kind of algorithms are versioned ?

With provided services "CATMmrAlgoConfigServices", you just take care about internal algorithms.

This means that those services are just used to keep the level of internal Algorithms (in Mechanical and Geometric Modelers)

[Top]

How to version a Mechanical Feature?

Versioning a Mechanical feature is done in two steps.

  1. First, prepare the instance to be versioned:

    At the instantiation time, the Feature instance has to be prepared to store the Algorithm Configuration i.e. the CATSoftwareConfiguration.
    To prepare it and so, to initialize the versioning of your instance, you just need to call to CATMmrAlgoConfigServices::CreateConfigurationData method during the factory implementation. [2]
     
    ...
   rc = CATMmrAlgoConfigServices::CreateConfigurationData(*pISpecObjectOnInstance);
   if( FAILED(rc) )
     return rc;
...


    This step prepare instance to store the CATSoftwareConfiguration. It is a primordial step in Versioning MechanicalFeature process.
     

  2. Second, version the instance of the feature:

    At the first build time, the current Algorithm Configuration need to be retrieved in order to know the current Algorithm level of current software code.
    This is done thanks to the call of CATMmrAlgoConfigServices::GetConfiguration.
     
    ...
           rc = QueryInterface(IID_CATISpecObject,(void **) & pSOCombinedCurve);
       if(SUCCEEDED(rc)&&pSOCombinedCurve != NULL)
       {
           rc = CATMmrAlgoConfigServices::GetConfiguration(pSOCombinedCurve ,pSoftConfig ,IsConfigToStore);
           if(SUCCEEDED(rc))
           {
               // SetSoftwareConfig 
               TopData.SetSoftwareConfiguration(pSoftConfig) ;
               // release pSoftConfig after the procedural report ending
           }
       }

...


    With this CATSoftwareConfiguration, you could define the good CATTopData to use to build feature's result.
     

    Then, at the end of the first build time, this Algorithm Configuration need to be stored on the instance, to keep it for following builds.
    This is done calling CATMmrAlgoConfigServices::StoreConfiguration method.[3]

     

      ...
       if ( SUCCEEDED(rc) )
       {
          if ( NULL != pResultBody )
          {
             int BoolOper = 0 ; 
             piProcReport->StoreProcReport(pResultBody,NoCopy,BoolOper); 
              
             if(IsConfigToStore == 1) 
             { 
                 CATMmrAlgoConfigServices::StoreConfiguration(pSOCombinedCurve ,pSoftConfig); 
             } 
          }
          else
          {
             CATMfErrUpdate *pErrorNoIntersection = new CATMfErrUpdate();
             CATUnicodeString Diagnostic("The two extruded curves do not intersect.");
             pErrorNoIntersection->SetDiagnostic(1,Diagnostic);

             CATThrow(pErrorNoIntersection);
          }
       }
  ...

    Please, note that after this storage, the configuration can not be modified anymore. It is impossible to by-pass this restriction. It's the only way to assure that the configuration used during the following builds will be the same that during the first one.

    Other build times:

    On following build times, the stored Algorithm Configuration is retrieved using CATMmrAlgoConfigServices::GetConfiguration method and this data is used to define the only corresponding CATTopData used in Topological et geometrical operator.

    With this unique CATTopData, Build result is guaranteed equal to the first built result. And your feature will not be impacted by enhancement or maintenance side effect.

     

In Short

In order to protect your feature from Algorithm changes in MechanicalModeler or in GeometricalModeler code, it is necessary to version your mechanical feature.
 

The way to do this is to use CATMmrAlgoConfigServices services on instantiate and build steps.
 

Using correctly those services, your feature will not be "release dependant on internal algorithms". This means that its behaviours (in particular for Build and update operation) will not depend on Mechanical or Geometrical Modeler internal algorithm changes.

[Top]

References

[1] The Versioning of the Topological Operators
[2] Creating a New StartUp Deriving from a Mechanical StartUp
[3] Integrating a New Geometrical Feature in the Update Mechanism
[Top]

History

Version: 1 [Jan 2007] Document created
[Top]

Copyright © 1999-2007, Dassault Systèmes. All rights reserved.