Track and Match CQ Objects On an Export-Import Round Trip

[jmwright]

User Story: As a user, I want to be able to export a CQ object or assembly to STEP/BRep, then import it again and be able to match the imported objects with the original pre-export CQ objects.

This will require some work on the CQ internals to accomplish.

Reference: Google Groups

@shimwell Please feel free to add additional details.

Related to #449

[shimwell]

Yes that would be a really useful feature for me.

The only tiny detail is that the Brep exported is also slightly differently to the default cadquery brep.

I use some code Adam wrote to merge shared surfaces link in the Brep file. This makes is easier to mesh in subsequent steps.

Full details of the messy workflow I have assembled are here in this unfinished paper I am working on. But having this round trip feature would allow the unreliable brep-part-finder package to be removed.
production_of_DAGMC_geometry_with_open_source_software_paper (1).pdf

[adam-urbanczyk]

@shimwell is this in the end about storing user defined labels per shape of subshape (e.g. face) that can survive the face merging process?

So something like:

As a user I want to be able to add labels to my models and use them to reference arbitrary shapes, possibly after merging duplicate faces.

[shimwell]

For me I just need to track the volumes. The removal of shared surfaces is a bit of a distraction. It happens in the workflow. But I just need to correlate the volumes in an assembly with the volumes in a brep file. I think in many cases the volume order is the same but not guaranteed to be the same

[shimwell]

Is there anything I can do to help with this

[adam-urbanczyk]

Hm, you could check if BOPAlgo_MakeConnected is indeed the correct algo for what you need.

[shimwell]

I've checked with the DAGMC community and we think BOPAlgo_MakeConnected that would be great for merging surfaces which is one of the things we would find very useful. The existing workflow uses the BOPALgo_Splitter (which you provided an example of a while ago) and this has also worked well for us.

@pshriwise and @ebknudsen might have further comments

[adam-urbanczyk]

Thanks @shimwell. I'm still not sure if this is at all about import/export. Based on the paper I concluded that you want to do this imprinting and matching in the back-end of CAD to DAGMC, so persisting to disk is not really needed. Is my conclusion correct?

What I have in mind so far is something like:

1. Start with a cq.Assembly
2. Construct a dictionary cq.Solid->id
3. Merge all cq.Solid instances using BOPAlgo_MakeConnected
4. Build a dictionary of cq.Solid->cq.Solid (after -> before (3)).
5. Create another dictionary cq.Solid -> id combining (4) and (2)
6. Return (5) and (3)

If it turns out that you do need to serialize, then using XDE/OCAF (native OCCT formats) would be preferred.

[shimwell]

The writing of a brep file to disk was done so that we can read it in by gmsh and meshed. I couldn't find another way of getting the geometry fro cadquery to gmsh so I currently write a brep file as they can both interact with that.

I actually also tried making triangular meshes in cadquery (then we wouldn't need to export) but that didn't result in watertight meshes a the surface mesh in gmsh did. If this had worked then the brep format could be avoided
https://github.com/fusion-energy/cad_to_dagmc/blob/7efb6805e52a4587a48de4a0a209f73b54ded91a/src/cad_to_dagmc/core.py#L164

[adam-urbanczyk]

I'm referring to the interface marked in red. AFAICT this part can be done in memory and has no relation to GMSH.

[shimwell]

Thanks Adam. Yes this interface is done in memory currently. Perhaps I've used the wrong terminology but a BREP "object" is passed between these stages

[adam-urbanczyk]

OK, so does what I proposed above (points 1-6) solve the problem you have?