Mechanical Modeler

CATMmrVerifyUpdate Application Principles

The CATMmrVerifyUpdate Application can be used in two steps:

1. When you are developing a new feature.

At first, it enables Feature Modeler [2] rules verification. Next, the application allows you to verify that the result provided by the CATIBuild implementation on the feature is correct [3].

2. When the code creating a feature is modified.

The application allows you to check the update's stability of the feature for which the contents of the CATIBuild implementation [3] (or its included methods) has been changed.

[Top]

How to Launch the CATMmrVerifyUpdate Application

To launch CATMmrVerifyUpdate, you will need to set up the build time environment, set up the run time environment, and then execute the command [8] such as:

mkrun -c "CATMmrVerifyUpdate [InputPart |-L PartList] [-specs] [-valid] [-stab] [-o OutputPath] [-feat FeatureName] [-cat CatalogName] [-noforce] [-h]"

or if you have only the run time environment, you can use the catstart command to launch CATMmrVerifyUpdate  

catstart -run "CATMmrVerifyUpdate [InputPart |-L PartList] [-specs] [-valid] [-stab] [-o OutputPath] [-feat FeatureName] [-cat CatalogName] [-noforce] [-h]"

The usage of catstart is explained in the interactive documentation. Refer to CATIA Infrastructure > CATIA Infrastructure User Guide > Basic Tasks > Starting Version 5 > Starting a Session on Windows (method 5) or Starting a Session on Unix (method 2)

The CATMmrVerifyUpdate application carries out checks on Part documents. You can online set one document (InputPart), or you can specify a list of documents in a text file (PartList). This file is pre-fixed with the -L option. If a txt file is given, the InputPart argument is not taken into account. In two cases, the Part document format is the complete path with the .CATPart suffix.

Whatever the options, CATMmrVerifyUpdate checks the update of the Part features. 

The options are the following, the first three being afterwards named the "check options":

• -specs

In addition to the update check, CATMmrVerifyUpdate also checks for each feature some Feature Modeler [2] rules and some others rules: Specifications

• -valid

In addition to the update check, CATMmrVerifyUpdate also checks for each feature:

• The validity of the scope [4]: Generic Naming

• The contents of the topological report: Topological Report

This option enables you to check the CATIBuild result [3]. 

Caution, this check option is available only if the -cat option is set.

• -stab

In addition to the update check, CATMmrVerifyUpdate also makes a comparison, between some specific values, before and after the feature's update: Update Stability.

This option enables you to check the validity of the modifications done in a CATIBuild implementation [3].

• -o OutputPath

CATMmrVerifyUpdate generates some TXT files and HTML files according to check option's requested. This option allows you to specify the path of these files, otherwise there are created in the directory indicated by the CATTemp environment variable.

There are files to sum up for each processed Part the check results.

• Whatever the check option there is the CheckSummary.txt file. 
• If at least one check option is specified (-specs, -valid, -stab) there is also the CheckSummary.html file

For each Part to analyze, a sub-directory, named with the Part name, is created inside the result directory. This sub-directory contains:

    *) Files to sum up for each processed Part's feature the check outputs. 

• Whatever the check option there is the PartSummary.txt file
• If at least one check option is specified (-specs, -valid, -stab) there is also the PartSummary.htm  
 

    * ) Either the errors, the files below can be also generated. They contain the details of check outputs. 

• (with -specs)  CheckSpecifications.txt
• (with -valid)    CheckNaming.html,
• (with -valid)    CheckJournalVerdict.html,
• (with -valid)    CheckJournalMoreInformation.html,

• (with -stab)    CheckStability.html

• -feat FeatureName

This option enables you to check only one feature contained in the InputPart Part document. FeatureName can be:

• The alias name of the feature (CATIAlias- GetAlias)
• The display name of the feature (CATISpecObject- GetDisplayName)
• The (internal) name of the feature (CATISpecObject-GetName) [2]

This option is not taken into account if there are several Parts

• -cat CatalogName

This option, only available for the -valid and -stab check options,  enables you to filter the features to analyze. Thanks to this option, you can select a specific feature catalog to filter your features among the features of the Part document. CatalogName is the name of the feature catalog without the storage path and with the ".CATfct" suffix. 

This table summarizes by check option type the feature taken into account:

	with -cat	without -cat
-spec	All the features are checked	All the features are checked
-valid	Only the features of the catalog are checked	No check
-stab	Only the features of the catalog are checked	All the features are checked

When there are several Parts, this option is applied to all. 

• -noforce

If the Part is up to date, this option must not be set, and the application will launch an update (force update) on all its features. Otherwise, if the Part is not up to date, -noforce must be set, and in this case a simple update will be launched. In other words:

• if -noforce is not set
• The Part is Up to Date : a force update is done
• The Part is Not Up to Date: an error is generated
• if -noforce is set
• The Part is Up to Date: an error is generated

• The Part is Not Up to Date: a simple update is done (only the none up to date features are updated)

When there are several Parts, this option is applied to all. 

• -h

This option displays the valid options for the command.

[Top]

Checks in Details

In this section, you will find in details the check meaning and the list of tests done for each of them. 

Update

This check enables you to validate the update of the geometrical features. In other words, it tests that the construction of the result associated with the feature is generated without error [5]. 

There are two reasons for an update error:

• A bad input specification for the feature. If it is possible, change the input
• A topological error.  By using the -valid options you could analyze the error. 

The results are displayed in the PartSummary files and 

Specifications

This check allows you to validate the Feature Modeler rules: attributes without valuation, feature not aggregated and other rules such as links to document not resolved and so on. To do that, CATMmrVerifyUpdate uses the Data Upward Assistant. Refer to CATIA Infrastructure > CATIA Infrastructure User Guide > Advanced Tasks > Using the Data Upward Assistant for complete details about this tool and how to analyze the output errors. 

CATMmrVerifyUpdate launches the CATDUAV5 command with the two first priorities:

• Priority One Return Code: Upwarding action may lead to data deletion
• Priority Two Return Code :Upwarding action may lead to data modification (without deletion)

The results are displayed in the CheckSpecifications.txt file

Topological Report

This check tests that the topological journal is valid. Refer to the CGM Journal article [7] for more details about the journal.

The results are displayed in the CheckJournalVerdict.html and CheckJournalMoreInformation.html files. 

Generic Naming

The update mechanism builds the result of the geometrical features. This result is a topological object (a CATBody) and an internal object (the scope). This scope ensures the access stability of each cell of the CATBody. It must contain a node for each followed cell [4].

There are several kinds of check:

1. Test that each feature has a scope and its scope has a link to a CATBody.

2. Test the bijection between nodes and followed cells, in other words:

• Each node represents a followed cell [4]

• Each followed cell [4] has a node

3. Test that each cell is selectable.

The "Journal Debug" interactive command can help you to check such error. [6]

The results are displayed in the CheckNaming.html file. 

Update Stability

The aim of this check is to verify the update stability of a given Part. The Part, created at the creation feature step, has been stored to be the reference. At each code modification:

• In the CATIBuild or CATIBuildShape implementation code,
• In your topological operator,
• In the journal management

it is important to test that the feature is stable from the update viewpoint. A none update stability can break another feature which have for input a cell (a BRep feature [4]) of the modified feature.

There are several kinds of check:

1. No regression in the topological cell naming (only if -cat option)

It is important to guaranty the naming stability, so that the following features, that are laid on the feature geometry, will continue to update themselves even if the feature is modified.

2. No addition nor suppression of nodes (only if -cat option)

3. The geometrical results are still the same:

• Test the volume - There is an error if the difference represents 0,1 % of difference with the initial volume.
• Test the gravity center - There is an error if the difference is larger than 0,01 mm 

The results are displayed in the CheckStability.html file. 

[Top]

Output Files in Details

This section describes in details the contents of each output files. It enables you to see their presentation, and the most important, to understand the check result signification.

CheckSummary.txt / CheckSummary.html 

These files sum up on a row and for each processed Part the result of each specified checks. The TXT file is always provided whenever the HTML file is only provided when at least one check option is given (-specs, -valid, -stab).

These files contain three parts:

1. The list of processed Parts and for each of them the name of the sub-directory containing their specific results:

2. The global result of each check in table form. 

It can have three kinds of output presentations:

1. The CheckSummary.html file



The CheckSummary.html gives the link of each PartSummary.html file in the first column. The Update column is always here, whenever the Specs, Naming, Journal and Stability column are displayed only if the dedicated option is specified.

2. The CheckSummary.txt file with at least one check option always displays seven columns. 



3. The CheckSummary.txt file without check option always displays three columns:



In the three cases, the meaning of each cell of these tables are the following:

 

3. The List of Parts where an error has been detected

There are several kinds of errors:

• Files not opened 
• Files opened and updated, with update error
• ....

This last part can be empty if no error occurs.

PartSummary.txt / PartSummary.html

These files sum up for each processed Part's feature the result of each specified checks. The TXT file is always provided whenever the HTML file is only provided when at least one check option is given (-specs, -valid, -stab). 

These files contain three parts:

1. The first error update detected (if any)

These files give the feature in error (Combine.7 here) and displays the same NLS error message that you will find in the Update Diagnosis Dialog Box [5] in an interactive session:

This part can be empty if the build of all the features is all right.

2. The global result for each requested check.

This part is displayed only if a check option is specified. 

If one result is KO, a link to the detailed file is generated too.

3. The check's status for each feature in table form 

It can have three kinds of output presentations:

1. The PartSummary.html



The PartSummary.html file gives the name of each feature in the first column. The Update column is always here, whenever the Specs, Naming, Journal and Stability column are displayed only if the dedicated option is specified.

2. The PartSummary.txt file with at least one check option always displays six columns:



3. The PartSummary.txt file without check option always displays three columns:



In the three cases, the contains of each column is the following:

For the Update check column, each cell value signifies:

• OK : The update of the feature has been correctly done, no error has occured during its build step.
• KO : Only one KO can appear in the column. The message associated with the error is displayed in the CheckSummary file. 
• -     : The feature has not been built for three reasons: it is not a geometrical feature, it is a geometrical feature without build, or a previous error has stopped the update step, and the current feature has not been reached.

For the Specs check column, each cell value signifies:

• OK :The check is correct 
• KO :The check is wrong 
• -    : The check has not be done on this feature

For the Naming and Journal  check columns, each cell value signifies:

• OK :The check is correct 
• KO :The check is wrong 
• -    : The check has not be done on this feature
• W  : The check has detected a warning, and not an error. 

For the Stability check column, the following table shorts in the cell value signification:

Before/After	Update OK	Update not Done	Update KO
Update OK	OK	KO	KO
Update not Done	W	OK	KO
Update KO	W	KO	OK

CheckSpecifications.txt

Refer to CATIA Infrastructure > CATIA Infrastructure User Guide > Advanced Tasks > Using the Data Upward Assistant for complete details about this tool and how to analyze the output errors given in this txt file.  

CheckNaming.html

This file is generated if the -valid check option is requested. The structure of this file is the following:

Between these two lines you can found such messages:

1. When the check is OK - 

2. When the check is K0 -  

3. When the feature has no scope nor body

CheckJournalVerdict.html

This file is generated if the -valid check option is requested. The structure of this file is the following:

CheckJournalMoreInformation.html

This file is generated if the -valid check option is requested. The structure of this file is the following:

CheckStability.html

This file is generated if the -stab check option is requested. The structure of this file is the following:

Between these two lines you can found such messages:

1. When the update comparison is OK

Curve.1 and Surface.2(*SKI2) are the alias names of the features. 

2. When the Update was KO before and successful now

In this case, the Stability check column displays a warning for the Sketch.5 feature.

3. New nodes have been created 

The scope associated with the Sketch.4 feature contains two new nodes with the new code. 

[Top]

 Return Codes of the CATMmrVerifyUpdate Application

If you make objects of test (odt) you can check the returned code of the application:

• 0 : all is OK

• 1 : Specification check has failed

• 2:  Naming check has failed

• 3: Journal check has failed

• 4 : At least one feature has an update error.

• 5 : Stability Check has failed

[Top]

In Short

The CATMmrVerifyUpdate application enables you to check a new geometrical feature or to validate code modifications. 

[Top]

References

History

Copyright © 2002, Dassault Systèmes. All rights reserved.