From david.thompson at kitware.com  Thu Sep 10 19:57:04 2015
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 10 Sep 2015 19:57:04 -0400
Subject: [Smtk-developers] Fwd: Evaluating boost.polygon for 2D modeling
References: <5D6C01F8-7F74-450C-A564-B4574518E428@kitware.com>
Message-ID: <56F686EB-1DD8-40EA-B430-9E5D4D92A517@kitware.com>

Hi all,

Forwarding with one less figure since the list-server bounced it.

	David

> Begin forwarded message:
> 
> From: David Thompson <david.thompson at kitware.com>
> Subject: Evaluating boost.polygon for 2D modeling
> Date: September 8, 2015 at 7:33:10 PM EDT
> To: Bob Obara <bob.obara at kitware.com>, "smtk-developers at smtk.org" <smtk-developers at smtk.org>
> 
> Hi all,
> 
> I've been looking at whether we might use boost.polygon to get faster, more robust 2D modeling. My first experiments have been aimed at exercising and benchmarking it, not integrating it into SMTK. A progress report is below.
> 
> 	David
> 
> ## Simple exercises
> 
> Starting with Boost 1.52, the polygon package comes with a "segment" concept and a function for finding self-intersecting segments (used to precondition data for Voronoi diagram generation). It has an interesting quirk, but should be useful for breaking ill-conditioned model edges into multiple, proper model edges.
> 
> The quirk is that entirely coincident line segments are not eliminated or marked as redundant, so testing 2 copies of the segment (0,0)->(10,10) results in 2 identical output segments. However, testing (0,0)->(10,10) and (4,4)->(8,8) yields 4 output segments: (0,0)->(4,4); (4,4)->(8,8); (8,8)->(10,10); and (4,4)->(8,8).
> 
> Another quirk is the way boost.polygon reports "tessellations." Instead of providing triangles or quadrilaterals that compose a polygon, it generates trapezoids. The trapezoids always have 2 edges are aligned with either the horizontal or vertical axis. However, they may also have more than 4 points... I've seen some with more than 2 collinear points along the axis-aligned segments. So, what boost appears to actually report are convex polygons which are easy to triangulate. Not a deal-killer, but a definite quirk.
> 
> ## Boolean exercises
> 
> After getting boolean operations working with simple rectangles, I did some timings on a more complex shape; I took the Chesapeake bay contour (7664 points in 1 very crinkly polygon) we've used for testing CMB and imported it into a boost.polygon model. It takes about 0.1 sec per boolean when I start subtracting random(-ish) rectangles but the cost decreases as more crinkly stuff gets removed, so that when punching 500 random rectangular holes, the amortized cost is 0.069 seconds per rectangle. Uniting all the holes and subtracting that is much faster.
> 
> You can see some attached pictures of the trapezoids reported for as part of the benchmark. Overall, it seems decently fast and also gets us Voronoi functionality as well.
> 
> ## Using Boost.Polygon for an SMTK session
> 
> To expose boost as a 2D modeling kernel in SMTK will take some work. Boost does not distinguish between model vertices and mid-edge vertices, mainly because Boost does not model polygons with edges at all. The "segment" concept above is used only for Voronoi diagram computation; when you create a polygon, you provide an ordered set of points (and optionally a set of polygonal holes). So, the SMTK session bridging the boost polygon would have to track edges and their model-face adjacencies as well as map UUIDs to vertices, edges, faces and (perhaps) uses.
> 
> We would also have to provide an algorithm to discern which edges form closed polygons, but (1) we already have an implementation of this (vtkDiscoverRegions) that could be adapted and (2) we probably also want to keep a data structure identifying vertex-edge adjacencies anyway, since Boost doesn't provide it; boost's polygon sets are just bags of polygons with no relationship to each other.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bay-NoHoles.pdf
Type: application/pdf
Size: 102991 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150910/8d47a19d/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BayStar.pdf
Type: application/pdf
Size: 37297 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150910/8d47a19d/attachment-0004.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BayWith500Holes.pdf
Type: application/pdf
Size: 51692 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150910/8d47a19d/attachment-0005.pdf>
-------------- next part --------------
> 


From david.thompson at kitware.com  Thu Sep 10 20:53:59 2015
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 10 Sep 2015 20:53:59 -0400
Subject: [Smtk-developers] More boost polygon work
Message-ID: <CBD7D5A2-2546-46BF-8338-9A9FC99832FA@kitware.com>

Hi all,

As a result of the previous boost.polygon evaluation, I was asked to make sure that booleans were still fast even when both the workpiece and tool inputs were complex. So, I've rotated the Chesapeake bay contour by a few degrees (anywhere from 10 to 50) and subtracted it from the original. It is fast: loading the dataset, rotating points, doing the boolean, and writing the output take a total of 0.08 seconds.

One other request I had was to see whether integer overflow would be a problem with the scaling factor chosen based on the smallest feature of interest. Assuming we use 64-bit integers for coordinates and make each integer 1mm in length, the largest "map" we could handle would be 2**63 mm = 10**15.965 m = 9.22 x 10**15 m = 5.73 x 10**12 miles. The semi-major axis of Earth's orbit around the sun is 149.5e9 m, so we could comfortably map every point the center of the earth travels around the sun in a year down to the nearest millimeter. More likely, we would choose quanta much smaller than a millimeter because intersection points along lines near the feature size would be hard to resolve otherwise. There is plenty of room to do this.

With that, I will proceed to implement a 2-d polygon session in SMTK that uses the boost approach (points stored in each session as integer coordinates, with the session transforming 3-d floating-point coordinates into 2-d integers by projection and scaling). You will be required to provide the transform and scaling information before inserting vertices, edges, or faces (or accept the default). Please let me know if you have any concerns.

	David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bay-SubtractRotatedInputs.pdf
Type: application/pdf
Size: 86958 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150910/74b4a531/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bay-SubtractRotated45.pdf
Type: application/pdf
Size: 48457 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150910/74b4a531/attachment-0003.pdf>

From bob.obara at kitware.com  Thu Sep 10 23:22:46 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Thu, 10 Sep 2015 23:22:46 -0400
Subject: [Smtk-developers] Fwd: Evaluating boost.polygon for 2D modeling
In-Reply-To: <56F686EB-1DD8-40EA-B430-9E5D4D92A517@kitware.com>
References: <5D6C01F8-7F74-450C-A564-B4574518E428@kitware.com>
 <56F686EB-1DD8-40EA-B430-9E5D4D92A517@kitware.com>
Message-ID: <8B43CBA0-4793-4905-9647-DE44F83296D7@kitware.com>

Hey David,

This is looking good.  I?ll talk with ERDC concerning precision tomorrow.

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




> On Sep 10, 2015, at 7:57 PM, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi all,
> 
> Forwarding with one less figure since the list-server bounced it.
> 
> 	David
> 
>> Begin forwarded message:
>> 
>> From: David Thompson <david.thompson at kitware.com>
>> Subject: Evaluating boost.polygon for 2D modeling
>> Date: September 8, 2015 at 7:33:10 PM EDT
>> To: Bob Obara <bob.obara at kitware.com>, "smtk-developers at smtk.org" <smtk-developers at smtk.org>
>> 
>> Hi all,
>> 
>> I've been looking at whether we might use boost.polygon to get faster, more robust 2D modeling. My first experiments have been aimed at exercising and benchmarking it, not integrating it into SMTK. A progress report is below.
>> 
>> 	David
>> 
>> ## Simple exercises
>> 
>> Starting with Boost 1.52, the polygon package comes with a "segment" concept and a function for finding self-intersecting segments (used to precondition data for Voronoi diagram generation). It has an interesting quirk, but should be useful for breaking ill-conditioned model edges into multiple, proper model edges.
>> 
>> The quirk is that entirely coincident line segments are not eliminated or marked as redundant, so testing 2 copies of the segment (0,0)->(10,10) results in 2 identical output segments. However, testing (0,0)->(10,10) and (4,4)->(8,8) yields 4 output segments: (0,0)->(4,4); (4,4)->(8,8); (8,8)->(10,10); and (4,4)->(8,8).
>> 
>> Another quirk is the way boost.polygon reports "tessellations." Instead of providing triangles or quadrilaterals that compose a polygon, it generates trapezoids. The trapezoids always have 2 edges are aligned with either the horizontal or vertical axis. However, they may also have more than 4 points... I've seen some with more than 2 collinear points along the axis-aligned segments. So, what boost appears to actually report are convex polygons which are easy to triangulate. Not a deal-killer, but a definite quirk.
>> 
>> ## Boolean exercises
>> 
>> After getting boolean operations working with simple rectangles, I did some timings on a more complex shape; I took the Chesapeake bay contour (7664 points in 1 very crinkly polygon) we've used for testing CMB and imported it into a boost.polygon model. It takes about 0.1 sec per boolean when I start subtracting random(-ish) rectangles but the cost decreases as more crinkly stuff gets removed, so that when punching 500 random rectangular holes, the amortized cost is 0.069 seconds per rectangle. Uniting all the holes and subtracting that is much faster.
>> 
>> You can see some attached pictures of the trapezoids reported for as part of the benchmark. Overall, it seems decently fast and also gets us Voronoi functionality as well.
>> 
>> ## Using Boost.Polygon for an SMTK session
>> 
>> To expose boost as a 2D modeling kernel in SMTK will take some work. Boost does not distinguish between model vertices and mid-edge vertices, mainly because Boost does not model polygons with edges at all. The "segment" concept above is used only for Voronoi diagram computation; when you create a polygon, you provide an ordered set of points (and optionally a set of polygonal holes). So, the SMTK session bridging the boost polygon would have to track edges and their model-face adjacencies as well as map UUIDs to vertices, edges, faces and (perhaps) uses.
>> 
>> We would also have to provide an algorithm to discern which edges form closed polygons, but (1) we already have an implementation of this (vtkDiscoverRegions) that could be adapted and (2) we probably also want to keep a data structure identifying vertex-edge adjacencies anyway, since Boost doesn't provide it; boost's polygon sets are just bags of polygons with no relationship to each other.
>> 
> <Bay-NoHoles.pdf><BayStar.pdf><BayWith500Holes.pdf>
>> 
>> 
> 
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150910/ef6e1be8/attachment.html>

From bob.obara at kitware.com  Mon Sep 14 17:05:06 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Mon, 14 Sep 2015 17:05:06 -0400
Subject: [Smtk-developers] Problem with CMB SuperBuild and SMTK
Message-ID: <5F08A72B-2FCC-48B6-9F03-5F00A002B892@kitware.com>

Hi All,

When trying to build CMB via a clean super build I?m getting:

CMake Error at Source/ModelBridges/CMakeLists.txt:4 (find_package):
  Found package configuration file:

    /Users/obara/Projects/Kitware/Builds/CMBSuperBuild/install/lib/cmake/SMTK/SMTKConfig.cmake

  but it set SMTK_FOUND to FALSE so package "SMTK" is considered to be NOT
  FOUND.  Reason given by package:

  The following imported targets are referenced, but are missing: MOAB



-- Configuring incomplete, errors occurred!


This is with a branch of CMB with my root view removal changes and SMTK master.

Any Ideas??

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150914/29e21d1a/attachment.html>

From david.thompson at kitware.com  Mon Sep 14 17:12:19 2015
From: david.thompson at kitware.com (David Thompson)
Date: Mon, 14 Sep 2015 17:12:19 -0400
Subject: [Smtk-developers] Problem with CMB SuperBuild and SMTK
In-Reply-To: <5F08A72B-2FCC-48B6-9F03-5F00A002B892@kitware.com>
References: <5F08A72B-2FCC-48B6-9F03-5F00A002B892@kitware.com>
Message-ID: <1AE68BEC-19AA-4472-952A-B39F6835CF1A@kitware.com>

Hi Bob,

> When trying to build CMB via a clean super build I?m getting: ...
>   The following imported targets are referenced, but are missing: MOAB
> This is with a branch of CMB with my root view removal changes and SMTK master.
> Any Ideas??

I think this is one of the reasons we haven't merged master to release-v1 yet. :-)

1. Is SMTK building its own MOAB library? If so, is it not being installed properly?
2. Rob and I had talked about installing an SMTK-built MOABConfig.cmake in lib/cmake/SMTK . I don't know if Rob got that merged in or not, but I do know the superbuild is not set up to properly configure SMTK to use its MOAB library...

	David

From bob.obara at kitware.com  Mon Sep 14 17:30:58 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Mon, 14 Sep 2015 17:30:58 -0400
Subject: [Smtk-developers] Problem with CMB SuperBuild and SMTK
In-Reply-To: <1AE68BEC-19AA-4472-952A-B39F6835CF1A@kitware.com>
References: <5F08A72B-2FCC-48B6-9F03-5F00A002B892@kitware.com>
 <1AE68BEC-19AA-4472-952A-B39F6835CF1A@kitware.com>
Message-ID: <48A543FE-5485-49F4-AAE8-FC3B4631D8DD@kitware.com>

Hi David,

Thanks!  Would I get around the problem by building MOAB explicitly in the SuperBuild?

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




> On Sep 14, 2015, at 5:12 PM, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi Bob,
> 
>> When trying to build CMB via a clean super build I?m getting: ...
>>  The following imported targets are referenced, but are missing: MOAB
>> This is with a branch of CMB with my root view removal changes and SMTK master.
>> Any Ideas??
> 
> I think this is one of the reasons we haven't merged master to release-v1 yet. :-)
> 
> 1. Is SMTK building its own MOAB library? If so, is it not being installed properly?
> 2. Rob and I had talked about installing an SMTK-built MOABConfig.cmake in lib/cmake/SMTK . I don't know if Rob got that merged in or not, but I do know the superbuild is not set up to properly configure SMTK to use its MOAB library...
> 
> 	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150914/6e7409ad/attachment.html>

From bob.obara at kitware.com  Mon Sep 14 17:41:43 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Mon, 14 Sep 2015 17:41:43 -0400
Subject: [Smtk-developers] Problem with CMB SuperBuild and SMTK
In-Reply-To: <48A543FE-5485-49F4-AAE8-FC3B4631D8DD@kitware.com>
References: <5F08A72B-2FCC-48B6-9F03-5F00A002B892@kitware.com>
 <1AE68BEC-19AA-4472-952A-B39F6835CF1A@kitware.com>
 <48A543FE-5485-49F4-AAE8-FC3B4631D8DD@kitware.com>
Message-ID: <BD34D878-9A62-41B7-8083-6DFA7C5E25DE@kitware.com>

Answered my own question: NOPE - in fact enable moab option produces an error when building MOAB.

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




> On Sep 14, 2015, at 5:30 PM, Robert Michael O'Bara <bob.obara at kitware.com> wrote:
> 
> Hi David,
> 
> Thanks!  Would I get around the problem by building MOAB explicitly in the SuperBuild?
> 
> Bob
> 
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
> 
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
> 
> Phone: (518) 881- 4931
> 
> 
> 
> 
>> On Sep 14, 2015, at 5:12 PM, David Thompson <david.thompson at kitware.com <mailto:david.thompson at kitware.com>> wrote:
>> 
>> Hi Bob,
>> 
>>> When trying to build CMB via a clean super build I?m getting: ...
>>>  The following imported targets are referenced, but are missing: MOAB
>>> This is with a branch of CMB with my root view removal changes and SMTK master.
>>> Any Ideas??
>> 
>> I think this is one of the reasons we haven't merged master to release-v1 yet. :-)
>> 
>> 1. Is SMTK building its own MOAB library? If so, is it not being installed properly?
>> 2. Rob and I had talked about installing an SMTK-built MOABConfig.cmake in lib/cmake/SMTK . I don't know if Rob got that merged in or not, but I do know the superbuild is not set up to properly configure SMTK to use its MOAB library...
>> 
>> 	David
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150914/bb070389/attachment.html>

From david.thompson at kitware.com  Mon Sep 14 17:44:23 2015
From: david.thompson at kitware.com (David Thompson)
Date: Mon, 14 Sep 2015 17:44:23 -0400
Subject: [Smtk-developers] Problem with CMB SuperBuild and SMTK
In-Reply-To: <BD34D878-9A62-41B7-8083-6DFA7C5E25DE@kitware.com>
References: <5F08A72B-2FCC-48B6-9F03-5F00A002B892@kitware.com>
 <1AE68BEC-19AA-4472-952A-B39F6835CF1A@kitware.com>
 <48A543FE-5485-49F4-AAE8-FC3B4631D8DD@kitware.com>
 <BD34D878-9A62-41B7-8083-6DFA7C5E25DE@kitware.com>
Message-ID: <36EF0ACB-B985-495A-B8CE-669B995E39CE@kitware.com>

> Answered my own question: NOPE - in fact enable moab option produces an error when building MOAB.

Hmmm. Well, I think the answer is to point SMTK at another MOAB (whether it's the superbuild's or not). But I also have concerns about how SMTK relays information about the version of MOAB it was built against to dependent packages like CMB. Rob and I talked about this on a recent PR, but I don't know if anything has been done yet.

	David

From ben.boeckel at kitware.com  Wed Sep 16 13:50:28 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 16 Sep 2015 13:50:28 -0400
Subject: [Smtk-developers] [ANN] Gitlab expected downtime today
Message-ID: <20150916175028.GA374@megas.khq.kitware.com>

Hi,

Gitlab (and buildbot) will be down for a short time today while we upgrade the
VM it is running on to have more resources.

Expected downtime is about 5 to 15 minutes.

Thanks,

--Ben

From ben.boeckel at kitware.com  Wed Sep 16 15:50:52 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 16 Sep 2015 15:50:52 -0400
Subject: [Smtk-developers] [ANN] Gitlab expected downtime today
In-Reply-To: <20150916175028.GA374@megas.khq.kitware.com>
References: <20150916175028.GA374@megas.khq.kitware.com>
Message-ID: <20150916195052.GF29564@megas.khq.kitware.com>

On Wed, Sep 16, 2015 at 13:50:28 -0400, Ben Boeckel wrote:
> Gitlab (and buildbot) will be down for a short time today while we upgrade the
> VM it is running on to have more resources.
> 
> Expected downtime is about 5 to 15 minutes.

All set.

--Ben

From david.thompson at kitware.com  Sat Sep 19 20:57:44 2015
From: david.thompson at kitware.com (David Thompson)
Date: Sat, 19 Sep 2015 20:57:44 -0400
Subject: [Smtk-developers] Polygon question
Message-ID: <05DBF662-48CF-46FD-AC09-15F143BD8894@kitware.com>

Hi Bob,

I have a question about how many corner cases the polygon session should handle:

  should users be allowed to create non-manifold models?

The case I am worried about is if (see attached figure) a user creates
- face 1 with vertices A-B-C-D-F-G and then creates
- face 2 with vertices A-B-F-G and then creates
- face 3 with vertices B-C-D-F.

In that case, edge A-B (for example) is used twice in the same sense.
Vertices B and F are also troublesome.

The data structure I use for vertices and edges will be different depending on what you say. If I only have to track manifold models, then it is enough to store a list of edges in CCW order at each model vertex plus a list of face IDs between pairs of adjacent edges (and nothing at edges except model vertices). If I have to handle non-manifold models, then edges will have to store lists of loops and vertices will not store faces between adjacent edges (or will have to store a map between pairs of edges and faces).

Any opinions?

	Thanks,
	David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: poly-example.pdf
Type: application/pdf
Size: 16495 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150919/72c6ba03/attachment.pdf>

From bob.obara at kitware.com  Sat Sep 19 23:59:39 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Sat, 19 Sep 2015 23:59:39 -0400
Subject: [Smtk-developers] Polygon question
In-Reply-To: <05DBF662-48CF-46FD-AC09-15F143BD8894@kitware.com>
References: <05DBF662-48CF-46FD-AC09-15F143BD8894@kitware.com>
Message-ID: <6CE4EC20-A5D8-4354-9F6D-F6882D92F6F3@kitware.com>

Hi David,

The situation you described would be invalid for 2d domains.  Either there is the one large polygonal model face or there are two.  To have all three would mean that a point in space would be "owned" by more than one model entity.  If we were modeling a 3D contact type of problem then a spatial point could be owned by more than one model entity; however, those model entities could not belong to the same topological "network".  

Does that make sense?

Bob

Sent from my iPad

> On Sep 19, 2015, at 8:57 PM, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi Bob,
> 
> I have a question about how many corner cases the polygon session should handle:
> 
>  should users be allowed to create non-manifold models?
> 
> The case I am worried about is if (see attached figure) a user creates
> - face 1 with vertices A-B-C-D-F-G and then creates
> - face 2 with vertices A-B-F-G and then creates
> - face 3 with vertices B-C-D-F.
> 
> In that case, edge A-B (for example) is used twice in the same sense.
> Vertices B and F are also troublesome.
> 
> The data structure I use for vertices and edges will be different depending on what you say. If I only have to track manifold models, then it is enough to store a list of edges in CCW order at each model vertex plus a list of face IDs between pairs of adjacent edges (and nothing at edges except model vertices). If I have to handle non-manifold models, then edges will have to store lists of loops and vertices will not store faces between adjacent edges (or will have to store a map between pairs of edges and faces).
> 
> Any opinions?
> 
>    Thanks,
>    David
> <poly-example.pdf>

From david.thompson at kitware.com  Sun Sep 20 18:25:18 2015
From: david.thompson at kitware.com (David Thompson)
Date: Sun, 20 Sep 2015 18:25:18 -0400
Subject: [Smtk-developers] Polygon question
In-Reply-To: <6CE4EC20-A5D8-4354-9F6D-F6882D92F6F3@kitware.com>
References: <05DBF662-48CF-46FD-AC09-15F143BD8894@kitware.com>
 <6CE4EC20-A5D8-4354-9F6D-F6882D92F6F3@kitware.com>
Message-ID: <BCE6DE99-D35E-49D7-90F9-9B335445D40A@kitware.com>

Hi Bob,

> The situation you described would be invalid for 2d domains.  Either there is the one large polygonal model face or there are two.  To have all three would mean that a point in space would be "owned" by more than one model entity.  If we were modeling a 3D contact type of problem then a spatial point could be owned by more than one model entity; however, those model entities could not belong to the same topological "network".  
> 
> Does that make sense?

I am happy to take things that way. :-) However, I suspect at some point we will see someone complain about a mangled model because they created the "large" face manually; then created the middle edge and ran the "create all faces" operator ? which would either fail or create an inconsistent model.

Right now, the "create edge" operator in my branch verifies the edge does not self-intersect but it doesn't do any checks against existing model faces or edges. Arguably it should not, since ? as you say ? users might want to construct several independent "networks."

Maybe we should have a "model geometry lint" filter?

	David

From bob.obara at kitware.com  Sun Sep 20 23:06:32 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Sun, 20 Sep 2015 23:06:32 -0400
Subject: [Smtk-developers] Polygon question
In-Reply-To: <BCE6DE99-D35E-49D7-90F9-9B335445D40A@kitware.com>
References: <05DBF662-48CF-46FD-AC09-15F143BD8894@kitware.com>
 <6CE4EC20-A5D8-4354-9F6D-F6882D92F6F3@kitware.com>
 <BCE6DE99-D35E-49D7-90F9-9B335445D40A@kitware.com>
Message-ID: <AA396812-F651-4338-A543-E7D4146DC1E9@kitware.com>

Hey David,

Technically the user would not be allowed to create that edge since it would intersect the large face - the user could one of the following though:

1. Delete the model face, then create the edge, then build all possible faces (in this case 2)
2. Perform a split face operation which will result in the same topology as 1.

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




> On Sep 20, 2015, at 6:25 PM, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi Bob,
> 
>> The situation you described would be invalid for 2d domains.  Either there is the one large polygonal model face or there are two.  To have all three would mean that a point in space would be "owned" by more than one model entity.  If we were modeling a 3D contact type of problem then a spatial point could be owned by more than one model entity; however, those model entities could not belong to the same topological "network".  
>> 
>> Does that make sense?
> 
> I am happy to take things that way. :-) However, I suspect at some point we will see someone complain about a mangled model because they created the "large" face manually; then created the middle edge and ran the "create all faces" operator ? which would either fail or create an inconsistent model.
> 
> Right now, the "create edge" operator in my branch verifies the edge does not self-intersect but it doesn't do any checks against existing model faces or edges. Arguably it should not, since ? as you say ? users might want to construct several independent "networks."
> 
> Maybe we should have a "model geometry lint" filter?
> 
> 	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150920/1b26ccbb/attachment.html>

From david.thompson at kitware.com  Thu Sep 24 00:25:14 2015
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 24 Sep 2015 00:25:14 -0400
Subject: [Smtk-developers] polygon progress
Message-ID: <208D5EF1-7CF7-4C84-B8D3-13D92BA1174A@kitware.com>

Hi all,

FYI: model, vertex, and edge creation operations are done and tested in SMTK for polygonal models but not merged yet. (It is in my github account on a branch named polygon.) A screenshot of the test dataset is attached and shows how a few odd conditions are handled:

+ the 4 vertices forming a small square near the center of the screenshot are placed into the model as model vertices;
+ the lower left shows how a request for 1 edge with 4 input points then gets turned into 4 edges due to self-intersection and contact with a pre-existing model vertex. 3 additional model vertices are created.
+ the bottom right shows how a request for 1 periodic edge with 5 input points is turned into 2 model edges. The model vertex in the output is not an input point; it is where 2 segments intersect.
+ the top left square shows a model edge with 5 input points and no model vertices.

There are some caveats:

+ the code used to enforce CCW-ordering of edges incident to each vertex is not numerically robust; it uses floating-point math and does not detect overflows or integer truncation due to the approximation of sqrt.
+ no GUI is provided for inserting points

The remaining operations to implement are (in rough order of priority):

+ create all possible, non-existent faces from a set of edges.
+ split an edge
+ merge edges
+ create a face given outer (and optionally inner) loops
+ move vertices (note that this could be very painful to do robustly when edges are attached).
+ booleans via boost.polygon
+ voronoi diagrams via boost.polygon

	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150924/6133e456/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-09-24 at 12.07.43 AM.png
Type: image/png
Size: 12413 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150924/6133e456/attachment.png>

From ben.boeckel at kitware.com  Thu Sep 24 17:15:50 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 24 Sep 2015 17:15:50 -0400
Subject: [Smtk-developers] [ANN] Gitlab expected downtime today for 8.0
	upgrade
Message-ID: <20150924211550.GA4007@megas.khq.kitware.com>

Hi,

Gitlab (and buildbot) will be down for about 20 minutes to an hour starting
around 5:30 while we upgrade to 8.0.

New features with 8.0 include:

  - new UI design;
  - separate tabs for "closed" and "merged" MRs;
  - all of our existing patches merged (though we need another for some bits
    new features missed);
  - better performance (apparently gitlab used to keep 2 clones per repo; now
    it is only one);
  - added refs for merge requests as refs/merge-requests/:id from the target
    repository; and
  - ability to upload files to issues and merge requests.

We will be working to enable another feature, reply-by-email where you can add
a Gitlab comment by replying to any notification email.

Also, LWN has an article about it in this week's edition:

    http://lwn.net/SubscriberLink/658072/2104b1cf923815e4/

Thanks,

--Ben

From ben.boeckel at kitware.com  Thu Sep 24 18:06:11 2015
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Thu, 24 Sep 2015 18:06:11 -0400
Subject: [Smtk-developers] [ANN] Gitlab expected downtime today for 8.0
	upgrade
In-Reply-To: <20150924211550.GA4007@megas.khq.kitware.com>
References: <20150924211550.GA4007@megas.khq.kitware.com>
Message-ID: <20150924220611.GF6565@megas.khq.kitware.com>

On Thu, Sep 24, 2015 at 17:15:50 -0400, Ben Boeckel wrote:
> Gitlab (and buildbot) will be down for about 20 minutes to an hour starting
> around 5:30 while we upgrade to 8.0.

Gitlab is now back online!

--Ben

From bob.obara at kitware.com  Mon Sep 28 19:48:49 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Mon, 28 Sep 2015 17:48:49 -0600
Subject: [Smtk-developers] Pyside
Message-ID: <83CA2175-AD19-46F4-86E7-DF102D1F532B@kitware.com>

http://it.toolbox.com/blogs/enlightenment/pyside2-pyside-qt5-support-underway-68285

Looks like there is some movement for qt 5

Bob

Sent from my iPhone

From bob.obara at kitware.com  Mon Sep 28 22:06:38 2015
From: bob.obara at kitware.com (Robert Michael O'Bara)
Date: Mon, 28 Sep 2015 20:06:38 -0600
Subject: [Smtk-developers] Dakota Simulation and Exporting files
Message-ID: <8C574548-2B1E-447A-925E-9FCB5ADB3CB2@kitware.com>

Hi John,

Do you know if these files still work in V4?

Thanks!

Bob

Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150928/082eae4a/attachment.html>

From john.tourtellott at kitware.com  Tue Sep 29 10:20:45 2015
From: john.tourtellott at kitware.com (John Tourtellott)
Date: Tue, 29 Sep 2015 10:20:45 -0400
Subject: [Smtk-developers] Dakota Simulation and Exporting files
In-Reply-To: <8C574548-2B1E-447A-925E-9FCB5ADB3CB2@kitware.com>
References: <8C574548-2B1E-447A-925E-9FCB5ADB3CB2@kitware.com>
Message-ID: <CA+psXTxb9SGwE7upROYRN5jshkQdLJYtm0U5MQZZ0ak8omvu1w@mail.gmail.com>

Well, I'm not sure, Bob

   - Dylan added a regression test for Dakota
   - But I don't see *any* export tests running in the nightly dashboard
   - There have been no mods to the .sbt or .py files for V4, but...
   - Looking at them briefly, it seems to involve only attributes.

I'll have to update my v4 build and try it. I'll let you know.

On Mon, Sep 28, 2015 at 10:06 PM, Robert Michael O'Bara <
bob.obara at kitware.com> wrote:

> Hi John,
>
> Do you know if these files still work in V4?
>
> Thanks!
>
> Bob
>
> Robert M. O'Bara, MEng.
> Assistant Director of Scientific Computing
>
> Kitware Inc.
> 28 Corporate Drive
> Suite 101
> Clifton Park, NY 12065
>
> Phone: (518) 881- 4931
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150929/a7ddec69/attachment.html>

From john.tourtellott at kitware.com  Tue Sep 29 11:42:01 2015
From: john.tourtellott at kitware.com (John Tourtellott)
Date: Tue, 29 Sep 2015 11:42:01 -0400
Subject: [Smtk-developers] Dakota Simulation and Exporting files
In-Reply-To: <CA+psXTxb9SGwE7upROYRN5jshkQdLJYtm0U5MQZZ0ak8omvu1w@mail.gmail.com>
References: <8C574548-2B1E-447A-925E-9FCB5ADB3CB2@kitware.com>
 <CA+psXTxb9SGwE7upROYRN5jshkQdLJYtm0U5MQZZ0ak8omvu1w@mail.gmail.com>
Message-ID: <CA+psXTyGOEv_uXg8SHh0D5JuVvmDLg7On6STMTE=eTm0FrR97w@mail.gmail.com>

I had to hack things a bit (for some reason, PARAVIEW_DATA_ROOT isn't set
right in my build), but I was able to run the dakota regression test.

   - As I mentioned before, the current template and export script are
   attributes only (no model or mesh traversal).
   - The files still use smtk version 1 attributes.
   - The test *almost* passes.
   - There is one error in the python script, and I don't know why it
   didn't hose Dylan. There is a call to "smtk.attribute.Manager.refModel()";
   that method no longer exists, BUT it is NOT needed to perform the export
   logic.
   - So after deleting that one line, I get the expected output.
   - I can submit a merge request to update the python script; but would
   you prefer to update dakota to smtk version 2 instead?


On Tue, Sep 29, 2015 at 10:20 AM, John Tourtellott <
john.tourtellott at kitware.com> wrote:

> Well, I'm not sure, Bob
>
>    - Dylan added a regression test for Dakota
>    - But I don't see *any* export tests running in the nightly dashboard
>    - There have been no mods to the .sbt or .py files for V4, but...
>    - Looking at them briefly, it seems to involve only attributes.
>
> I'll have to update my v4 build and try it. I'll let you know.
>
> On Mon, Sep 28, 2015 at 10:06 PM, Robert Michael O'Bara <
> bob.obara at kitware.com> wrote:
>
>> Hi John,
>>
>> Do you know if these files still work in V4?
>>
>> Thanks!
>>
>> Bob
>>
>> Robert M. O'Bara, MEng.
>> Assistant Director of Scientific Computing
>>
>> Kitware Inc.
>> 28 Corporate Drive
>> Suite 101
>> Clifton Park, NY 12065
>>
>> Phone: (518) 881- 4931
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150929/56dcef50/attachment.html>

From david.thompson at kitware.com  Tue Sep  8 19:33:15 2015
From: david.thompson at kitware.com (David Thompson)
Date: Tue, 08 Sep 2015 23:33:15 -0000
Subject: [Smtk-developers] Evaluating boost.polygon for 2D modeling
Message-ID: <5D6C01F8-7F74-450C-A564-B4574518E428@kitware.com>

Hi all,

I've been looking at whether we might use boost.polygon to get faster, more robust 2D modeling. My first experiments have been aimed at exercising and benchmarking it, not integrating it into SMTK. A progress report is below.

	David

## Simple exercises

Starting with Boost 1.52, the polygon package comes with a "segment" concept and a function for finding self-intersecting segments (used to precondition data for Voronoi diagram generation). It has an interesting quirk, but should be useful for breaking ill-conditioned model edges into multiple, proper model edges.

The quirk is that entirely coincident line segments are not eliminated or marked as redundant, so testing 2 copies of the segment (0,0)->(10,10) results in 2 identical output segments. However, testing (0,0)->(10,10) and (4,4)->(8,8) yields 4 output segments: (0,0)->(4,4); (4,4)->(8,8); (8,8)->(10,10); and (4,4)->(8,8).

Another quirk is the way boost.polygon reports "tessellations." Instead of providing triangles or quadrilaterals that compose a polygon, it generates trapezoids. The trapezoids always have 2 edges are aligned with either the horizontal or vertical axis. However, they may also have more than 4 points... I've seen some with more than 2 collinear points along the axis-aligned segments. So, what boost appears to actually report are convex polygons which are easy to triangulate. Not a deal-killer, but a definite quirk.

## Boolean exercises

After getting boolean operations working with simple rectangles, I did some timings on a more complex shape; I took the Chesapeake bay contour (7664 points in 1 very crinkly polygon) we've used for testing CMB and imported it into a boost.polygon model. It takes about 0.1 sec per boolean when I start subtracting random(-ish) rectangles but the cost decreases as more crinkly stuff gets removed, so that when punching 500 random rectangular holes, the amortized cost is 0.069 seconds per rectangle. Uniting all the holes and subtracting that is much faster.

You can see some attached pictures of the trapezoids reported for as part of the benchmark. Overall, it seems decently fast and also gets us Voronoi functionality as well.

## Using Boost.Polygon for an SMTK session

To expose boost as a 2D modeling kernel in SMTK will take some work. Boost does not distinguish between model vertices and mid-edge vertices, mainly because Boost does not model polygons with edges at all. The "segment" concept above is used only for Voronoi diagram computation; when you create a polygon, you provide an ordered set of points (and optionally a set of polygonal holes). So, the SMTK session bridging the boost polygon would have to track edges and their model-face adjacencies as well as map UUIDs to vertices, edges, faces and (perhaps) uses.

We would also have to provide an algorithm to discern which edges form closed polygons, but (1) we already have an implementation of this (vtkDiscoverRegions) that could be adapted and (2) we probably also want to keep a data structure identifying vertex-edge adjacencies anyway, since Boost doesn't provide it; boost's polygon sets are just bags of polygons with no relationship to each other.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bay-NoHoles.pdf
Type: application/pdf
Size: 102991 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150908/8e6c447f/attachment-0004.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BayStar.pdf
Type: application/pdf
Size: 37297 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150908/8e6c447f/attachment-0005.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BayWith50Holes.pdf
Type: application/pdf
Size: 97341 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150908/8e6c447f/attachment-0006.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BayWith500Holes.pdf
Type: application/pdf
Size: 51692 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20150908/8e6c447f/attachment-0007.pdf>