[cgma-dev] Facet/Cholla engine

Jane Hu janejhu at gmail.com
Tue Jan 21 13:15:59 CST 2014


David,

I tried both of your programs, you are right that the key for success in
build_facet_surface relies on the how the CubitPoints are defined. I have
observed the following:

1. If you define new CubitPoints for each facet, even they share the same
location, the code is creating separate surface for each facet.

2. It doens't matter if you provide the point list or not as long as the
facets are created through different sets of points. I attach another file
here to demonstrate, where you can see, if you define 4 facets using 12
different points (just pointer different), even you don't provide the point
list, the code still generates 4 surfaces(which is prefered). When building
a body, the duplicate vertices and edges are merged, leaving 4 refedges and
4 refpoints in the model.

3. If you define facets using shared points, you indicates to connect the
edges and don't separate the model on the points. In this case, you have to
give all such facets in one build_facet_surface call, otherwise, code
crashes on not being able to find the shared edges.

I'll put the feature-angle issue as an enhancement bug to the system.

Thanks and have a nice day!

Jane




On Sat, Jan 18, 2014 at 3:08 PM, David Thompson
<david.thompson at kitware.com>wrote:

> Hi Jane,
>
> I've found a combination of things that allow me to build models with
> multiple faceted surfaces per shell. It boils down to creating disjoint
> sets of CubitPointData instances for each FacetSurface, but which re-use a
> given CubitPoint shared among facets on the same FacetSurface. When
> multiple FacetSurfaces are combined into a shell, the facet engine merges
> the duplicate vertices on their common boundaries. I tried passing an empty
> point_list, but that failed. Passing CubitFacetData instances to the same
> build_facet_surface() call that have coincident points encoded in multiple
> CubitPointData instances (instead of a shared instance) also fails.
> Attached are working examples (one build 4 FacetSurfaces from 4 triangles,
> the other 2 FacetSurfaces from 4 triangles).
>
> It would be nice if the documentation for build_facet_surface() was
> updated to include some mention of this:
>
>     //- Create one or more new FacetSurfaces with all of its lower
>     //- order entities.  Use an optional feature_angle to break
>     //- surface.
>     //-
>     //- Where the input CubitFacet and/or CubitQuadFacet instances
>     //- share a vertex, they should reference the same CubitPoint
>     //- pointer. However, no CubitPoint instance shared with a
>     //- surface created by a separate call to build_facet_surface()
>     //- should be referenced; if multiple build_facet_surface() calls
>     //- are made, points on shared boundaries between will be merged
>     //- when the a shell containing the surfaces is created.
>     //-
>     //- The point_list should contain exactly the points in
>     //- the input facets and no others.
>
> I still have not been able to get surface-splitting by feature_angle
> working, so that is probably still worth a bug report.
>
>         David
>
>


-- 
Jane Hu

Asst. Researcher
Dept. of Engineering Physics
UW @ Madison

"And we know that for those who love God, that is, for those who are called
according to his purpose, all things are working together for good."
(Romans 8:28)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140121/62ac9a99/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multifaceted-works.cxx
Type: text/x-c++src
Size: 3256 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20140121/62ac9a99/attachment.cxx>


More information about the cgma-dev mailing list