# Inconsistency in Read/Write with OCCT tools

**URL:** <https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671>\
**Category:** Simulation Modeling Toolkit (SMTK)\
**Created:** [June 29, 2021, 5:02pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671 "2021-06-29T17:02:01Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ryan\_Krattiger](https://discourse.kitware.com/user_avatar/discourse.kitware.com/ryan_krattiger/32/390_2.png) [@Ryan\_Krattiger](https://discourse.kitware.com/u/Ryan_Krattiger)\
**Post date:** [June 29, 2021, 5:02pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/1 "2021-06-29T17:02:01Z")

</div>

Running a test with the OpenCascade Plugins Read/Write operators has exposed a potential issue where the representation that is written with `BRepToos::Write` is inconsistent with the shapes that are stored under the hood in the `TopeDS_Shape`.

This is illustrated when loading the attached STEP file, writing it back as a BRep file, and then reloading the BRep file.

Visually the models appear to be nearly identical, but upon closer inspection of the model entities there are missing entities from the original model representation.

Plugin Code: [https://gitlab.kitware.com/cmb/plugins/opencascade-session](https://gitlab.kitware.com/cmb/plugins/opencascade-session)  
Test Data: [https://data.kitware.com/#user/606b71c62fa25629b95d7506/folder/60db51872fa25629b9a21d75](https://data.kitware.com/#user/606b71c62fa25629b95d7506/folder/60db51872fa25629b9a21d75)

---

<div class="post-metadata">

**Author:** ![Ryan\_Krattiger](https://discourse.kitware.com/user_avatar/discourse.kitware.com/ryan_krattiger/32/390_2.png) [@Ryan\_Krattiger](https://discourse.kitware.com/u/Ryan_Krattiger)\
**Post date:** [June 29, 2021, 5:02pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/2 "2021-06-29T17:02:43Z")

</div>

@dcthomp @Bob_Obara @aron.helser @johnt Do you guys have any thoughts on this?

---

<div class="post-metadata">

**Author:** ![C\_Wetterer-Nelson](https://discourse.kitware.com/user_avatar/discourse.kitware.com/c_wetterer-nelson/32/380_2.png) [@C\_Wetterer-Nelson](https://discourse.kitware.com/u/C_Wetterer-Nelson)\
**Post date:** [June 29, 2021, 5:12pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/3 "2021-06-29T17:12:22Z")

</div>

what model entities are missing? to write a STEP file, a TopoDS\_Shape needs to be translated, and that translation (from BRep\_Tools::Write) may be missing those types of entities. Maybe try using the [STEPControl\_Writer](https://dev.opencascade.org/doc/refman/html/class_s_t_e_p_control___writer.html) for writing?

---

<div class="post-metadata">

**Author:** ![Ryan\_Krattiger](https://discourse.kitware.com/user_avatar/discourse.kitware.com/ryan_krattiger/32/390_2.png) [@Ryan\_Krattiger](https://discourse.kitware.com/u/Ryan_Krattiger)\
**Post date:** [June 29, 2021, 5:16pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/4 "2021-06-29T17:16:03Z")

</div>

I am writing a BRep file from the internal shapes. The original model that was a STEP file seems to import correctly.

---

<div class="post-metadata">

**Author:** ![C\_Wetterer-Nelson](https://discourse.kitware.com/user_avatar/discourse.kitware.com/c_wetterer-nelson/32/380_2.png) [@C\_Wetterer-Nelson](https://discourse.kitware.com/u/C_Wetterer-Nelson)\
**Post date:** [June 29, 2021, 5:29pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/5 "2021-06-29T17:29:23Z")

</div>

Right, but that shape may be simplified in the export to STEP process. Here are some options for how that export occurs: [STEPControl\_StepModelType.hxx File Reference - Open CASCADE Technology Documentation](https://dev.opencascade.org/doc/refman/html/_s_t_e_p_control___step_model_type_8hxx.html#a032affe8dae498d429a83225f8c5da4e)

Notice that some options do potentially remove geometry.

---

<div class="post-metadata">

**Author:** ![dcthomp](https://discourse.kitware.com/user_avatar/discourse.kitware.com/dcthomp/32/10_2.png) [@dcthomp](https://discourse.kitware.com/u/dcthomp)\
**Post date:** [June 30, 2021, 2:16pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/6 "2021-06-30T14:16:14Z")

</div>

I think the issue here is that he’s not exporting to STEP but writing the imported data out in OCC’s native file format.

All I can think to do is identify what entities are not being saved by

- importing the step file
- running the “save” operation which writes a `.smtk` and a `.brep` file
- **importing** the `.brep` file (which will assign new, non-conflicting uuids to all shapes) and using 2 TopoDS iterators to see where the mismatches are and how they might be related.

---

<div class="post-metadata">

**Author:** ![cadprobs](https://discourse.kitware.com/user_avatar/discourse.kitware.com/cadprobs/32/1217_2.png) [@cadprobs](https://discourse.kitware.com/u/cadprobs)\
**Post date:** [November 9, 2026, 2:46pm UTC](https://discourse.kitware.com/t/inconsistency-in-read-write-with-occt-tools/671/7 "2026-11-09T14:46:53Z")

</div>

OCCT STEP round-trips are picky. Before you dig into BRep write inconsistency, open the source STEP once and check solids / units so the file itself isn’t already the mismatch. [STEP File Viewer Online: Open STP Files, No Account | CADProps](https://www.cadprops.com/tools/step-viewer/)