Some CAD systems are developed to support the "Basic" design lifecycle of the vessel model and others are developed to also support the "Detailed" design lifecycle. In the former (basic design), the model is based on "moulded" j(i.e. zero-thickness surfaces and curves defined on these moulded surfaces with properties denoting the plate thickness and orientation and the stiffener orientations and offsets. In the latter (detailed design, the physical geometry of the plates and stiffeners is adjusted to reflect their true position in the 3D model space.
We have a definition in the OCX saying how to interpret the thickness and stiffener material offsets as depicted in the figure below:
Currently , the OCX schema for "PhysicalProperties" contains a single attribute for the "CenterOfGravity" (CoG) defined by 3 co-ordinate values (X, Y, and Z). If the "basic" design tool exports the moulded CoG without adjustments for "thickness" offset of the plate material (the default), the importing translator handling the OCX--according to the recommended practice interpretation--will apply an offset of the plate equal to the thickness. The same applies to Stiffeners and Edge Reinforcements.
When outputting the target statistics for the plate CoG, the translator will report the CoG in the middle of the plate with an offset if the offset is accounted for. This will create a deviation between the native and target statics resulting in an error. But the test case should not show an error, because the translator imported the OCX correctly.
This inconsistency between the native statics from a vendor and the OCX imports from that vendor creates a dilemma for the test results reporting: None of these test cases will show success.
The question is how we should handle this situation.
It has been suggested that the schema be enhanced to support the possibility to report surface and thickness-based CoG's depending on the native system capabilities. The importing translator can then decide which statistics to compare.
This could be accomplished by modifying the "PhysicalProperties" element to
support 2 CoG's--one for the "moulded" (zero-thickness) values and another for the "solid" (thickened) values. Since it is unlikely that all vendors will support exporting values, the optional or mandatory cardinality of these attributes would have to be taken into account.
Add an attribute to define which CoG values are being reported--moulded or solid, however, this approach would not support the ability to exchange both values.
Some CAD systems are developed to support the "Basic" design lifecycle of the vessel model and others are developed to also support the "Detailed" design lifecycle. In the former (basic design), the model is based on "moulded" j(i.e. zero-thickness surfaces and curves defined on these moulded surfaces with properties denoting the plate thickness and orientation and the stiffener orientations and offsets. In the latter (detailed design, the physical geometry of the plates and stiffeners is adjusted to reflect their true position in the 3D model space.
We have a definition in the OCX saying how to interpret the thickness and stiffener material offsets as depicted in the figure below:
Currently , the OCX schema for "PhysicalProperties" contains a single attribute for the "CenterOfGravity" (CoG) defined by 3 co-ordinate values (X, Y, and Z). If the "basic" design tool exports the moulded CoG without adjustments for "thickness" offset of the plate material (the default), the importing translator handling the OCX--according to the recommended practice interpretation--will apply an offset of the plate equal to the thickness. The same applies to Stiffeners and Edge Reinforcements.
When outputting the target statistics for the plate CoG, the translator will report the CoG in the middle of the plate with an offset if the offset is accounted for. This will create a deviation between the native and target statics resulting in an error. But the test case should not show an error, because the translator imported the OCX correctly.
This inconsistency between the native statics from a vendor and the OCX imports from that vendor creates a dilemma for the test results reporting: None of these test cases will show success.
The question is how we should handle this situation.
It has been suggested that the schema be enhanced to support the possibility to report surface and thickness-based CoG's depending on the native system capabilities. The importing translator can then decide which statistics to compare.
This could be accomplished by modifying the "PhysicalProperties" element to