From david.thompson at kitware.com  Thu Jun  1 10:22:42 2017
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 1 Jun 2017 10:22:42 -0400
Subject: [Smtk-developers] buildbot & gitlab?
Message-ID: <ED2FA77C-2AB5-44FC-83FC-DAD6509C3891@kitware.com>

Hi all,

Is there a reason buildbot is not responding this morning? I went to merge some MRs from last night that have finished testing/review and BB is not merging... it's been about 5 minutes and normally is < 30s.

	David

From david.thompson at kitware.com  Thu Jun  1 20:40:40 2017
From: david.thompson at kitware.com (David Thompson)
Date: Thu, 1 Jun 2017 20:40:40 -0400
Subject: [Smtk-developers] PLY support and auxiliary geometry test data
Message-ID: <C8461213-DE0C-4D60-BE96-11484EE23631@kitware.com>

Hi Jie,

I've added the files listed below to the test-data repo. The 4 shapes do not overlap, so your test can just load one shape for each file-format and a single screenshot will do.

Once [SMTK MR 655](https://gitlab.kitware.com/cmb/smtk/merge_requests/655) is merged, auxiliary geometry instances whose URLs point to PLY files will be rendered properly.

Also, I've merged in the fix for GrabCuts so now loading in a "lines" file will let you run immediately without further input.

	David


model/3d/obj/box.obj
model/3d/obj/cone.obj
model/3d/obj/cylinder.obj
model/3d/obj/sphere.obj
model/3d/ply/box.ply
model/3d/ply/cone.ply
model/3d/ply/cylinder.ply
model/3d/ply/sphere.ply
model/3d/vtk/box.vtp
model/3d/vtk/cone.vtp
model/3d/vtk/cylinder.vtp
model/3d/vtk/sphere.vtp
point_cloud/box.pts
point_cloud/cone.pts
point_cloud/cylinder.pts
point_cloud/sphere.pts


From kriolog at gmail.com  Mon Jun  5 14:44:40 2017
From: kriolog at gmail.com (Maxim Torgonskiy)
Date: Mon, 5 Jun 2017 14:44:40 -0400
Subject: [Smtk-developers] smtk + netgen
Message-ID: <CAHXhknufukZ9bsHJGr21XEtM5in7SngQWAeqgY_dbcHyZ_p9UA@mail.gmail.com>

Hello,

We use smtk for one our paraview-based project (paraview filter
https://github.com/kriolog/paraview_smtk_reader). We also need to
integrate netgen in it. Meshkit already have netgen bindings and uses
the same dependencies as smtk. Is it a good idea is to use the
versions of cgm, moab, occ/oce which I already have in
smtk-superbuild? Or maybe there is a ready solution for
smtk-(remus?)-netgen or smtk-meshkit bridge?

Thanks,
Maxim

From tj.corona at kitware.com  Mon Jun  5 16:27:28 2017
From: tj.corona at kitware.com (TJ Corona)
Date: Mon, 5 Jun 2017 16:27:28 -0400
Subject: [Smtk-developers] smtk + netgen
In-Reply-To: <CAHXhknufukZ9bsHJGr21XEtM5in7SngQWAeqgY_dbcHyZ_p9UA@mail.gmail.com>
References: <CAHXhknufukZ9bsHJGr21XEtM5in7SngQWAeqgY_dbcHyZ_p9UA@mail.gmail.com>
Message-ID: <4964112C-C6D2-4FF9-A554-B85118508F96@kitware.com>

Hi Maxim,

smtk::mesh uses MOAB as its backend, and we have nascent support for a modeling session that uses smtk::mesh as its backend. It looks like MOAB has support for reading/writing to/from netcdf, so if you are interested in using SMTK to perform model annotation, I think this functionality could be easily supported. Do you have a sample Netgen file we could try importing/exporting?

Sincerely,
T.J.

Thomas J. Corona, Ph.D.
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

> On Jun 5, 2017, at 2:44 PM, Maxim Torgonskiy <kriolog at gmail.com> wrote:
> 
> Hello,
> 
> We use smtk for one our paraview-based project (paraview filter
> https://github.com/kriolog/paraview_smtk_reader). We also need to
> integrate netgen in it. Meshkit already have netgen bindings and uses
> the same dependencies as smtk. Is it a good idea is to use the
> versions of cgm, moab, occ/oce which I already have in
> smtk-superbuild? Or maybe there is a ready solution for
> smtk-(remus?)-netgen or smtk-meshkit bridge?
> 
> Thanks,
> Maxim
> _______________________________________________
> 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/20170605/442715fc/attachment.html>

From kriolog at gmail.com  Mon Jun  5 16:59:12 2017
From: kriolog at gmail.com (Maxim Torgonskiy)
Date: Mon, 5 Jun 2017 16:59:12 -0400
Subject: [Smtk-developers] smtk + netgen
In-Reply-To: <4964112C-C6D2-4FF9-A554-B85118508F96@kitware.com>
References: <CAHXhknufukZ9bsHJGr21XEtM5in7SngQWAeqgY_dbcHyZ_p9UA@mail.gmail.com>
 <4964112C-C6D2-4FF9-A554-B85118508F96@kitware.com>
Message-ID: <CAHXhknvf__woYfB9vFoz_duNQaA7CZdfCXxiCzXnr1ZeD04QXA@mail.gmail.com>

Hi T.J.,

Thank you for your reply.  Sorry, I think I didn't explain myself
well. I need the netgen mesher itself, not only import/export.
Here is an example of how meshkit does it with moab and netgen:
https://bitbucket.org/fathomteam/meshkit/src/d23e7dd46053e2fe6382f7bfe69efbecfc8893e8/example/example_ngtetmesher.cpp?at=master&fileviewer=file-view-default
The test model is the following:
https://bitbucket.org/fathomteam/meshkit/src/d23e7dd46053e2fe6382f7bfe69efbecfc8893e8/data/threeholecube.stp?at=master&fileviewer=file-view-default
Is there any possibility to bind netgen with smtk? I've found only a
remus::Worker class
(https://github.com/Kitware/Remus/tree/master/remus/worker) that can
mesh using a server-client architecture (which could be a  big
advantage for us in the future).

Thanks,
Maxim

2017-06-05 16:27 GMT-04:00 TJ Corona <tj.corona at kitware.com>:
> Hi Maxim,
>
> smtk::mesh uses MOAB as its backend, and we have nascent support for a
> modeling session that uses smtk::mesh as its backend. It looks like MOAB has
> support for reading/writing to/from netcdf, so if you are interested in
> using SMTK to perform model annotation, I think this functionality could be
> easily supported. Do you have a sample Netgen file we could try
> importing/exporting?
>
> Sincerely,
> T.J.
>
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443
>
> On Jun 5, 2017, at 2:44 PM, Maxim Torgonskiy <kriolog at gmail.com> wrote:
>
> Hello,
>
> We use smtk for one our paraview-based project (paraview filter
> https://github.com/kriolog/paraview_smtk_reader). We also need to
> integrate netgen in it. Meshkit already have netgen bindings and uses
> the same dependencies as smtk. Is it a good idea is to use the
> versions of cgm, moab, occ/oce which I already have in
> smtk-superbuild? Or maybe there is a ready solution for
> smtk-(remus?)-netgen or smtk-meshkit bridge?
>
> Thanks,
> Maxim
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>

From david.thompson at kitware.com  Wed Jun  7 09:57:30 2017
From: david.thompson at kitware.com (David Thompson)
Date: Wed, 7 Jun 2017 09:57:30 -0400
Subject: [Smtk-developers] Model export operator
Message-ID: <870D569D-7AC4-4D80-A3D9-4801FB96D25A@kitware.com>

Hi Bob et al.,

I've submitted MRs that split off the model export functionality into a new operator.

https://gitlab.kitware.com/cmb/smtk/merge_requests/665
https://gitlab.kitware.com/cmb/cmb/merge_requests/435

The SMTK one will break CMB, so I'll probably merge both once the SMTK one passes tests.

	David

From bob.obara at kitware.com  Wed Jun  7 10:57:45 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Wed, 7 Jun 2017 10:57:45 -0400
Subject: [Smtk-developers] Model export operator
In-Reply-To: <870D569D-7AC4-4D80-A3D9-4801FB96D25A@kitware.com>
References: <870D569D-7AC4-4D80-A3D9-4801FB96D25A@kitware.com>
Message-ID: <F8809E56-7ADD-44DC-A077-70B010F398B2@kitware.com>

Hey David - great!  Are you around?  I was working on the qtOperatorInforDialog (now called qtViewInfoDialog) and have a couple questions I want to discuss.

Talk with you later.

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 Jun 7, 2017, at 9:57 AMEDT, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi Bob et al.,
> 
> I've submitted MRs that split off the model export functionality into a new operator.
> 
> https://gitlab.kitware.com/cmb/smtk/merge_requests/665
> https://gitlab.kitware.com/cmb/cmb/merge_requests/435
> 
> The SMTK one will break CMB, so I'll probably merge both once the SMTK one passes tests.
> 
> 	David

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

From david.thompson at kitware.com  Wed Jun  7 13:26:22 2017
From: david.thompson at kitware.com (David Thompson)
Date: Wed, 7 Jun 2017 13:26:22 -0400
Subject: [Smtk-developers] Breaking change
Message-ID: <A6850898-99F8-44D4-915C-B331C5717655@kitware.com>

Hi all,

I'm pushing changes to the "save smtk model" operator and its custom UI panel (smtkSaveModelView) that will break CMB without additional changes -- which I am also going to merge now. So be aware that both need to be updated at once.

FYI: These changes split the operator into 2 operators: the existing one and a new one named "export smtk model". The "save smtk model" operator always marks the model(s) you save as clean/unmodified and does not move files away from their current location. The "export smtk model" ensures that all files (auxiliary geometry/image, meshes, model kernel data, etc.) are in the same directory or a subdirectory of the SMTK file and does *not* mark the model as clean. In this way, "export smtk model" acts like "Save a copy".

	David

From david.thompson at kitware.com  Mon Jun 12 14:13:04 2017
From: david.thompson at kitware.com (David Thompson)
Date: Mon, 12 Jun 2017 14:13:04 -0400
Subject: [Smtk-developers] Mesh location
Message-ID: <571BCE25-0075-48D8-BFD5-2B14B28D7A16@kitware.com>

Hi all,

Does anyone mind if I change the SMTK file format before the release? In the "mesh_collection" section, I would like to rename each collection's "location" keyword to "url". This would let smtk/io/LoadJSON.cxx process relative filenames for meshes the same as everything else. And be consistent with all the other file locations stored in SMTK.

	David

From bob.obara at kitware.com  Mon Jun 12 14:42:47 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Mon, 12 Jun 2017 14:42:47 -0400
Subject: [Smtk-developers] Mesh location
In-Reply-To: <571BCE25-0075-48D8-BFD5-2B14B28D7A16@kitware.com>
References: <571BCE25-0075-48D8-BFD5-2B14B28D7A16@kitware.com>
Message-ID: <0F613FBB-8984-4F46-94F8-A8EE7474E9C2@kitware.com>

Hey David,

Will the change cause existing SMTK files to be invalid?

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 Jun 12, 2017, at 2:13 PMEDT, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi all,
> 
> Does anyone mind if I change the SMTK file format before the release? In the "mesh_collection" section, I would like to rename each collection's "location" keyword to "url". This would let smtk/io/LoadJSON.cxx process relative filenames for meshes the same as everything else. And be consistent with all the other file locations stored in SMTK.
> 
> 	David
> _______________________________________________
> 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/20170612/7bb69fe0/attachment.html>

From david.thompson at kitware.com  Mon Jun 12 15:21:17 2017
From: david.thompson at kitware.com (David Thompson)
Date: Mon, 12 Jun 2017 15:21:17 -0400
Subject: [Smtk-developers] Mesh location
In-Reply-To: <0F613FBB-8984-4F46-94F8-A8EE7474E9C2@kitware.com>
References: <571BCE25-0075-48D8-BFD5-2B14B28D7A16@kitware.com>
 <0F613FBB-8984-4F46-94F8-A8EE7474E9C2@kitware.com>
Message-ID: <7AD6A781-B44C-45EF-ABDA-5E83EDA55AE2@kitware.com>

> Will the change cause existing SMTK files to be invalid?

No, if "url" isn't present then it looks for "location" (see SMTK MR 675).

Only "url" will support relative paths, but that has always been the case so nothing that worked previously will be broken.

	David

From bob.obara at kitware.com  Mon Jun 12 15:35:20 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Mon, 12 Jun 2017 15:35:20 -0400
Subject: [Smtk-developers] Mesh location
In-Reply-To: <7AD6A781-B44C-45EF-ABDA-5E83EDA55AE2@kitware.com>
References: <571BCE25-0075-48D8-BFD5-2B14B28D7A16@kitware.com>
 <0F613FBB-8984-4F46-94F8-A8EE7474E9C2@kitware.com>
 <7AD6A781-B44C-45EF-ABDA-5E83EDA55AE2@kitware.com>
Message-ID: <BC82B9D1-21E3-44E5-94C2-46093F91C31E@kitware.com>

Sounds ok to me then :)

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 Jun 12, 2017, at 3:21 PMEDT, David Thompson <david.thompson at kitware.com> wrote:
> 
>> Will the change cause existing SMTK files to be invalid?
> 
> No, if "url" isn't present then it looks for "location" (see SMTK MR 675).
> 
> Only "url" will support relative paths, but that has always been the case so nothing that worked previously will be broken.
> 
> 	David

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

From tj.corona at kitware.com  Wed Jun 14 10:17:27 2017
From: tj.corona at kitware.com (TJ Corona)
Date: Wed, 14 Jun 2017 10:17:27 -0400
Subject: [Smtk-developers] SMTK dashboard hiccup
Message-ID: <BFD4C10F-AE46-47DF-B252-5095E49BB1AD@kitware.com>

Hi all,

Haocheng and Jie discovered yesterday that smtk has not been testing with remus enabled. We have enabled remus on the dashboards, but until the superbuild performs a complete cycle our dashboards are going to be a massacre of configuration errors. You know what they say about making an omelette? Sorry!

Sincerely,
T.J.

Thomas J. Corona, Ph.D.
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

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

From bob.obara at kitware.com  Wed Jun 14 10:21:27 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Wed, 14 Jun 2017 10:21:27 -0400
Subject: [Smtk-developers] SMTK dashboard hiccup
In-Reply-To: <BFD4C10F-AE46-47DF-B252-5095E49BB1AD@kitware.com>
References: <BFD4C10F-AE46-47DF-B252-5095E49BB1AD@kitware.com>
Message-ID: <1710BD33-9CA8-4381-8EEF-C1BF4DE869B1@kitware.com>

Hey TJ - Thanks for the heads up - cook away!

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 Jun 14, 2017, at 10:17 AMEDT, TJ Corona <tj.corona at kitware.com> wrote:
> 
> Hi all,
> 
> Haocheng and Jie discovered yesterday that smtk has not been testing with remus enabled. We have enabled remus on the dashboards, but until the superbuild performs a complete cycle our dashboards are going to be a massacre of configuration errors. You know what they say about making an omelette? Sorry!
> 
> Sincerely,
> T.J.
> 
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443
> 
> _______________________________________________
> 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/20170614/5a384673/attachment.html>

From david.thompson at kitware.com  Wed Jun 14 15:46:48 2017
From: david.thompson at kitware.com (David Thompson)
Date: Wed, 14 Jun 2017 15:46:48 -0400
Subject: [Smtk-developers] smtk + netgen
In-Reply-To: <CAHXhknvf__woYfB9vFoz_duNQaA7CZdfCXxiCzXnr1ZeD04QXA@mail.gmail.com>
References: <CAHXhknufukZ9bsHJGr21XEtM5in7SngQWAeqgY_dbcHyZ_p9UA@mail.gmail.com>
 <4964112C-C6D2-4FF9-A554-B85118508F96@kitware.com>
 <CAHXhknvf__woYfB9vFoz_duNQaA7CZdfCXxiCzXnr1ZeD04QXA@mail.gmail.com>
Message-ID: <FC43C1C0-1C10-4C9C-AB7D-F42F9B0F70C1@kitware.com>

Hi Maxim,

Sorry for the slow reply.

We have a few mesh workers (separate executables that use remus to communicate with ModelBuilder). Each worker typically deserializes a model from an SMTK file (whose filename is passed as a parameter to the worker's job) and meshes it, then returns (via Remus) the location of the mesh file it generated to ModelBuilder.

Unfortunately, none of these mesh workers are public yet as the meshers themselves are not under our control. However, TJ is working on a simple Delaunay-triangulation mesh worker that might serve as an example of how we are tying SMTK to mesh generators:

https://gitlab.kitware.com/cmb/smtk/merge_requests/676

It's a work in progress until it gets merged, but hopefully it will help. We would really like to have a mesh worker based on the cgm session that uses netgen to create meshes, so if you are thinking about contributing one that would be great.

Given the tendency we have observed for most meshers to crash somewhere between occasionally and frequently, we like running the mesher in a separate process even though it adds the overhead of reading/writing files.

	David



> On Jun 5, 2017, at 16:59, Maxim Torgonskiy <kriolog at gmail.com> wrote:
> 
> Hi T.J.,
> 
> Thank you for your reply.  Sorry, I think I didn't explain myself
> well. I need the netgen mesher itself, not only import/export.
> Here is an example of how meshkit does it with moab and netgen:
> https://bitbucket.org/fathomteam/meshkit/src/d23e7dd46053e2fe6382f7bfe69efbecfc8893e8/example/example_ngtetmesher.cpp?at=master&fileviewer=file-view-default
> The test model is the following:
> https://bitbucket.org/fathomteam/meshkit/src/d23e7dd46053e2fe6382f7bfe69efbecfc8893e8/data/threeholecube.stp?at=master&fileviewer=file-view-default
> Is there any possibility to bind netgen with smtk? I've found only a
> remus::Worker class
> (https://github.com/Kitware/Remus/tree/master/remus/worker) that can
> mesh using a server-client architecture (which could be a  big
> advantage for us in the future).
> 
> Thanks,
> Maxim
> 
> 2017-06-05 16:27 GMT-04:00 TJ Corona <tj.corona at kitware.com>:
>> Hi Maxim,
>> 
>> smtk::mesh uses MOAB as its backend, and we have nascent support for a
>> modeling session that uses smtk::mesh as its backend. It looks like MOAB has
>> support for reading/writing to/from netcdf, so if you are interested in
>> using SMTK to perform model annotation, I think this functionality could be
>> easily supported. Do you have a sample Netgen file we could try
>> importing/exporting?
>> 
>> Sincerely,
>> T.J.
>> 
>> Thomas J. Corona, Ph.D.
>> Kitware, Inc.
>> Senior R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4443
>> 
>> On Jun 5, 2017, at 2:44 PM, Maxim Torgonskiy <kriolog at gmail.com> wrote:
>> 
>> Hello,
>> 
>> We use smtk for one our paraview-based project (paraview filter
>> https://github.com/kriolog/paraview_smtk_reader). We also need to
>> integrate netgen in it. Meshkit already have netgen bindings and uses
>> the same dependencies as smtk. Is it a good idea is to use the
>> versions of cgm, moab, occ/oce which I already have in
>> smtk-superbuild? Or maybe there is a ready solution for
>> smtk-(remus?)-netgen or smtk-meshkit bridge?
>> 
>> Thanks,
>> Maxim
>> _______________________________________________
>> Smtk-developers mailing list
>> Smtk-developers at smtk.org
>> http://public.kitware.com/mailman/listinfo/smtk-developers
>> 
>> 
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers


From bob.obara at kitware.com  Wed Jun 14 15:54:25 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Wed, 14 Jun 2017 15:54:25 -0400
Subject: [Smtk-developers] Release of CMB 4.2 and SMTK 1.1 and Beyond
Message-ID: <F99E50E1-7CB3-47B3-BED6-7E3D3289BECC@kitware.com>

Hi All,

We are nearly the release of both CMB 4.2 and SMTK 1.1 (I hope either the end of this week or the beginning of next week).  As soon as the release is tagged and branched we will be moving on to CMB 5.0 and SMTK 2.0 (We will be maintaining CMB 4.2.x and SMTK 1.1.x for awhile).

The first change will be to transition to QT 5.9 (and leave QT 4.8.x in the past) and support on the pybind11 Python wrapping generation tool (and say goodbye to Shiboken).  This will require Visual Studio 2015  (which is needed by pybind11), Mac, and Linux developers should not be effected.

I did run a QT5 Experimental Build on CMB 4.2-RC2 on my Mac running 10.11.6:

PB11 - Pybind11 Issue
NBL - New Baseline Needed
WPI - Widget Path Issue

	 21 - MeshViewerMeshChangeMaterial (Failed) - NBL
	 26 - MeshViewerMeshSmoothing3dm (Failed)
	 31 - ModelBuilderAssignColors1 (Failed)
	 39 - ModelBuilderEdgeModification (Failed)
	 56 - ModelBuilderRotate2D (Failed) - NBL
	 74 - ModelBuilderPolygonCreateFaceFromImage (Failed)
	 82 - ModelBuilderRotateAlongPickedCenter (Failed) - NBL
	107 - ModelBuilderExportSimAdHShallowPy (Failed) - PB11
	108 - ModelBuilderExportSimAdHSurfacePy (Failed) - PB11
	109 - ModelBuilderExportSimDakotaPy (Failed) - PB11
	110 - ModelBuilderExportSimHydraPy (Failed) - PB11
	111 - ModelBuilderExportSimProteusPy (Failed) - PB11
	121 - SceneBuilderArcCreate1 (Failed) - WPI

Of the 13 test failures - the 5 python tests are currently not supported using Pybind11 (right John?)


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/20170614/ae6ed1c0/attachment.html>

From tj.corona at kitware.com  Mon Jun 19 18:45:18 2017
From: tj.corona at kitware.com (TJ Corona)
Date: Mon, 19 Jun 2017 17:45:18 -0500
Subject: [Smtk-developers] An idea for connecting SMTK sessions
Message-ID: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>

Hi all,

I have an idea, and I?d like to know what everyone thinks. We currently have multiple sessions with different backings, and each of these sessions have a different set of operators that it can perform. To my understanding, if a user wants to cross from session to session, they currently have to do so manually (i.e. create a working model in one session, open the model in a new session and perform the operation). What if we created ?bridges? between sessions that facilitated to/from operations for each session pair, and then made these conversions implicit during model manipulation in ModelBuilder? For example, we create a bridge between the polygon and mesh sessions that describe how to convert a model of one type to the other (going from polygon to mesh would imply an implicit meshing operation, and going from mesh to model would imply an extraction of vertices, edges and faces in the mesh session to construct a polygon model). This way, a user could create a polygon model and then perform any of the meshing operations on it without having to know what session currently backs their model. Is this crazy?

Sincerely,
T.J.

Thomas J. Corona, Ph.D.
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

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

From bob.obara at kitware.com  Mon Jun 19 22:08:52 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Mon, 19 Jun 2017 22:08:52 -0400
Subject: [Smtk-developers] An idea for connecting SMTK sessions
In-Reply-To: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
References: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
Message-ID: <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>

Wouldn?t  the conversion to/from pair just be in a  separate plugin (since it would need to be built against a pair of sessions)?  In this case the conversion operators would be added to the corresponding sessions when the plugin is loaded.  I?m not sure if having the model be implicitly being created is a good idea since the conversion may result in a loss of information) - explicit conversion at least would inform the user of the conversion limitations - now a workflow that requires such a conversion (for example going from a polygonal planar model to a 3d non-planar discrete model after applying an elevation field) would be able to apply it implicitly when going from one task in the workflow to another since the workflow designer would have factored in the conversion issues when designing the workflow.

Does that make sense or am I missing something?

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 Jun 19, 2017, at 6:45 PMEDT, TJ Corona <tj.corona at kitware.com> wrote:
> 
> Hi all,
> 
> I have an idea, and I?d like to know what everyone thinks. We currently have multiple sessions with different backings, and each of these sessions have a different set of operators that it can perform. To my understanding, if a user wants to cross from session to session, they currently have to do so manually (i.e. create a working model in one session, open the model in a new session and perform the operation). What if we created ?bridges? between sessions that facilitated to/from operations for each session pair, and then made these conversions implicit during model manipulation in ModelBuilder? For example, we create a bridge between the polygon and mesh sessions that describe how to convert a model of one type to the other (going from polygon to mesh would imply an implicit meshing operation, and going from mesh to model would imply an extraction of vertices, edges and faces in the mesh session to construct a polygon model). This way, a user could create a polygon model and then perform any of the meshing operations on it without having to know what session currently backs their model. Is this crazy?
> 
> Sincerely,
> T.J.
> 
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443
> 
> _______________________________________________
> 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/20170619/a90f9429/attachment.html>

From david.thompson at kitware.com  Mon Jun 19 22:21:24 2017
From: david.thompson at kitware.com (David Thompson)
Date: Mon, 19 Jun 2017 22:21:24 -0400
Subject: [Smtk-developers] An idea for connecting SMTK sessions
In-Reply-To: <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>
References: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
 <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>
Message-ID: <547199C0-FF96-4FD0-967C-148AB913A8C7@kitware.com>

Hi TJ,

I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.

But I think it is nice to have a way to perform the conversion. In fact, the ERDC CS session has an operator for converting any non-parametric model into a model in that session. If we come up with a convention, we should make sure that operator is brought along for the ride.

    David

> On Jun 19, 2017, at 22:08, Bob Obara <bob.obara at kitware.com> wrote:
> 
> Wouldn?t  the conversion to/from pair just be in a  separate plugin (since it would need to be built against a pair of sessions)?  In this case the conversion operators would be added to the corresponding sessions when the plugin is loaded.  I?m not sure if having the model be implicitly being created is a good idea since the conversion may result in a loss of information) - explicit conversion at least would inform the user of the conversion limitations - now a workflow that requires such a conversion (for example going from a polygonal planar model to a 3d non-planar discrete model after applying an elevation field) would be able to apply it implicitly when going from one task in the workflow to another since the workflow designer would have factored in the conversion issues when designing the workflow.
> 
> Does that make sense or am I missing something?
> 
> 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 Jun 19, 2017, at 6:45 PMEDT, TJ Corona <tj.corona at kitware.com> wrote:
>> 
>> Hi all,
>> 
>> I have an idea, and I?d like to know what everyone thinks. We currently have multiple sessions with different backings, and each of these sessions have a different set of operators that it can perform. To my understanding, if a user wants to cross from session to session, they currently have to do so manually (i.e. create a working model in one session, open the model in a new session and perform the operation). What if we created ?bridges? between sessions that facilitated to/from operations for each session pair, and then made these conversions implicit during model manipulation in ModelBuilder? For example, we create a bridge between the polygon and mesh sessions that describe how to convert a model of one type to the other (going from polygon to mesh would imply an implicit meshing operation, and going from mesh to model would imply an extraction of vertices, edges and faces in the mesh session to construct a polygon model). This way, a user could create a polygon model and then perform any of the meshing operations on it without having to know what session currently backs their model. Is this crazy?
>> 
>> Sincerely,
>> T.J.
>> 
>> Thomas J. Corona, Ph.D.
>> Kitware, Inc.
>> Senior R&D Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4443
>> 
>> _______________________________________________
>> Smtk-developers mailing list
>> Smtk-developers at smtk.org
>> http://public.kitware.com/mailman/listinfo/smtk-developers
> 
> _______________________________________________
> 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/20170619/2050a95d/attachment-0001.html>

From tj.corona at kitware.com  Mon Jun 19 22:49:55 2017
From: tj.corona at kitware.com (TJ Corona)
Date: Mon, 19 Jun 2017 21:49:55 -0500
Subject: [Smtk-developers] An idea for connecting SMTK sessions
In-Reply-To: <547199C0-FF96-4FD0-967C-148AB913A8C7@kitware.com>
References: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
 <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>
 <547199C0-FF96-4FD0-967C-148AB913A8C7@kitware.com>
Message-ID: <91BA9840-80A7-4BE3-910E-310F5E21DAC2@kitware.com>

>> I?m not sure if having the model be implicitly being created is a good idea since the conversion may result in a loss of information

That?s true: I guess only some sessions would be able to convert back and forth without loss. Any implicit operations that resulted in an assumption of information or a loss of information would definitely be a bad thing.

> I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.


Also true. This gets to the heart of one of the design patterns in SMTK that I don?t quite understand, though: how do we better exploit the common interface of the default session to construct operators that span multiple derived sessions? The option of extending operators across sessions via implicit conversions is probably the wrong path, but I think that the problem it addresses is worth considering. Encompassing meta-operators that manually call their derived counterparts could work, but it seems like there is opportunity here for a more elegant solution. 

> But I think it is nice to have a way to perform the conversion. 

Me too! I?ve been thinking about the conversion between the mesh session and VTK in a similar context. We discussed wrapping SMTK mesh objects as zero-copy VTK objects, and I?d like to give that a try when I get a chance. Perhaps a similar paradigm could exist between some of the sessions.

Thomas J. Corona, Ph.D.
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

> On Jun 19, 2017, at 9:21 PM, David Thompson <david.thompson at kitware.com> wrote:
> 
> Hi TJ,
> 
> I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.
> 
> But I think it is nice to have a way to perform the conversion. In fact, the ERDC CS session has an operator for converting any non-parametric model into a model in that session. If we come up with a convention, we should make sure that operator is brought along for the ride.
> 
>     David
> 
> On Jun 19, 2017, at 22:08, Bob Obara <bob.obara at kitware.com <mailto:bob.obara at kitware.com>> wrote:
> 
>> Wouldn?t  the conversion to/from pair just be in a  separate plugin (since it would need to be built against a pair of sessions)?  In this case the conversion operators would be added to the corresponding sessions when the plugin is loaded.  I?m not sure if having the model be implicitly being created is a good idea since the conversion may result in a loss of information) - explicit conversion at least would inform the user of the conversion limitations - now a workflow that requires such a conversion (for example going from a polygonal planar model to a 3d non-planar discrete model after applying an elevation field) would be able to apply it implicitly when going from one task in the workflow to another since the workflow designer would have factored in the conversion issues when designing the workflow.
>> 
>> Does that make sense or am I missing something?
>> 
>> 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 Jun 19, 2017, at 6:45 PMEDT, TJ Corona <tj.corona at kitware.com <mailto:tj.corona at kitware.com>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I have an idea, and I?d like to know what everyone thinks. We currently have multiple sessions with different backings, and each of these sessions have a different set of operators that it can perform. To my understanding, if a user wants to cross from session to session, they currently have to do so manually (i.e. create a working model in one session, open the model in a new session and perform the operation). What if we created ?bridges? between sessions that facilitated to/from operations for each session pair, and then made these conversions implicit during model manipulation in ModelBuilder? For example, we create a bridge between the polygon and mesh sessions that describe how to convert a model of one type to the other (going from polygon to mesh would imply an implicit meshing operation, and going from mesh to model would imply an extraction of vertices, edges and faces in the mesh session to construct a polygon model). This way, a user could create a polygon model and then perform any of the meshing operations on it without having to know what session currently backs their model. Is this crazy?
>>> 
>>> Sincerely,
>>> T.J.
>>> 
>>> Thomas J. Corona, Ph.D.
>>> Kitware, Inc.
>>> Senior R&D Engineer
>>> 21 Corporate Drive
>>> Clifton Park, NY 12065-8662
>>> Phone: 518-881-4443
>>> 
>>> _______________________________________________
>>> Smtk-developers mailing list
>>> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
>>> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>
>> 
>> _______________________________________________
>> Smtk-developers mailing list
>> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
>> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>

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

From haocheng.liu at kitware.com  Tue Jun 20 09:31:00 2017
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Tue, 20 Jun 2017 09:31:00 -0400
Subject: [Smtk-developers] An idea for connecting SMTK sessions
In-Reply-To: <91BA9840-80A7-4BE3-910E-310F5E21DAC2@kitware.com>
References: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
 <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>
 <547199C0-FF96-4FD0-967C-148AB913A8C7@kitware.com>
 <91BA9840-80A7-4BE3-910E-310F5E21DAC2@kitware.com>
Message-ID: <CACbTE7N3KAFUgahgs56fejQD6RsuytA2_5mcw3ep0TxJLbnCvg@mail.gmail.com>

Good Morning TJ,

On Mon, Jun 19, 2017 at 10:49 PM, TJ Corona <tj.corona at kitware.com> wrote:

> I?m not sure if having the model be implicitly being created is a good
> idea since the conversion may result in a loss of information
>
>
> That?s true: I guess only some sessions would be able to convert back and
> forth without loss. Any implicit operations that resulted in an assumption
> of information or a loss of information would definitely be a bad thing.
>
> I agree with Bob that implicit conversion could be a problem, especially
> when a similar operation exists in multiple sessions.
>
>
> Also true. This gets to the heart of one of the design patterns in SMTK
> that I don?t quite understand, though: how do we better exploit the common
> interface of the default session to construct operators that span multiple
> derived sessions?
>
I believe the current logic is that first we create operators for the
default session and store them in the class variable
defaultSession->m_operatorSys(*smtk::attribute::system* type). Next let's
say we want to create a discrete session, we would then initialize discrete
session operators and append dafault session's operators to
discreteSession->m_operatorSys. Here we only copy definitions that do not
already exist so we can realize "overriding operator". You can take a look
at /smtk/model/Session.cxx#L1048
<https://gitlab.kitware.com/cmb/smtk/blob/master/smtk/model/Session.cxx#L1048>
for
detail.

The option of extending operators across sessions via implicit conversions
> is probably the wrong path, but I think that the problem it addresses is
> worth considering. Encompassing meta-operators that manually call their
> derived counterparts could work, but it seems like there is opportunity
> here for a more elegant solution.
>
>  There is no implicit conversions here for extending operators across
sessions actually. For now I think the only operator which has inheritance
is the EntityGroupOperator. Discrete session has its own derived version.
Another special case are the Add image and Add auxiliary geometry operator.
Add image operator has its own sbt file and internally it's using Add
auxiliary geometry operator to load an image.


> But I think it is nice to have a way to perform the conversion.
>
>
> Me too! I?ve been thinking about the conversion between the mesh session
> and VTK in a similar context. We discussed wrapping SMTK mesh objects as
> zero-copy VTK objects, and I?d like to give that a try when I get a chance.
> Perhaps a similar paradigm could exist between some of the sessions.
>
+1. I agree that mesh session would be a nice bridge :)

>
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443 <(518)%20881-4443>
>
> On Jun 19, 2017, at 9:21 PM, David Thompson <david.thompson at kitware.com>
> wrote:
>
> Hi TJ,
>
> I agree with Bob that implicit conversion could be a problem, especially
> when a similar operation exists in multiple sessions.
>
> But I think it is nice to have a way to perform the conversion. In fact,
> the ERDC CS session has an operator for converting any non-parametric model
> into a model in that session. If we come up with a convention, we should
> make sure that operator is brought along for the ride.
>
>     David
>
> On Jun 19, 2017, at 22:08, Bob Obara <bob.obara at kitware.com> wrote:
>
> Wouldn?t  the conversion to/from pair just be in a  separate plugin (since
> it would need to be built against a pair of sessions)?  In this case the
> conversion operators would be added to the corresponding sessions when the
> plugin is loaded.  I?m not sure if having the model be implicitly being
> created is a good idea since the conversion may result in a loss of
> information) - explicit conversion at least would inform the user of the
> conversion limitations - now a workflow that requires such a conversion
> (for example going from a polygonal planar model to a 3d non-planar
> discrete model after applying an elevation field) would be able to apply it
> implicitly when going from one task in the workflow to another since the
> workflow designer would have factored in the conversion issues when
> designing the workflow.
>
> Does that make sense or am I missing something?
>
> 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 <(518)%20881-4931>
>
>
>
>
> On Jun 19, 2017, at 6:45 PMEDT, TJ Corona <tj.corona at kitware.com> wrote:
>
> Hi all,
>
> I have an idea, and I?d like to know what everyone thinks. We currently
> have multiple sessions with different backings, and each of these sessions
> have a different set of operators that it can perform. To my understanding,
> if a user wants to cross from session to session, they currently have to do
> so manually (i.e. create a working model in one session, open the model in
> a new session and perform the operation). What if we created ?bridges?
> between sessions that facilitated to/from operations for each session pair,
> and then made these conversions implicit during model manipulation in
> ModelBuilder? For example, we create a bridge between the polygon and mesh
> sessions that describe how to convert a model of one type to the other
> (going from polygon to mesh would imply an implicit meshing operation, and
> going from mesh to model would imply an extraction of vertices, edges and
> faces in the mesh session to construct a polygon model). This way, a user
> could create a polygon model and then perform any of the meshing operations
> on it without having to know what session currently backs their model. Is
> this crazy?
>
> Sincerely,
> T.J.
>
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443 <(518)%20881-4443>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>
>
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org
> http://public.kitware.com/mailman/listinfo/smtk-developers
>
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170620/fda8c2df/attachment-0001.html>

From tj.corona at kitware.com  Tue Jun 20 10:18:27 2017
From: tj.corona at kitware.com (TJ Corona)
Date: Tue, 20 Jun 2017 09:18:27 -0500
Subject: [Smtk-developers] An idea for connecting SMTK sessions
In-Reply-To: <CACbTE7N3KAFUgahgs56fejQD6RsuytA2_5mcw3ep0TxJLbnCvg@mail.gmail.com>
References: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
 <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>
 <547199C0-FF96-4FD0-967C-148AB913A8C7@kitware.com>
 <91BA9840-80A7-4BE3-910E-310F5E21DAC2@kitware.com>
 <CACbTE7N3KAFUgahgs56fejQD6RsuytA2_5mcw3ep0TxJLbnCvg@mail.gmail.com>
Message-ID: <E87DB9EA-FA94-4605-92B7-EF79E90C97CE@kitware.com>

> Here we only copy definitions that do not already exist so we can realize "overriding operator?.

Ah, ok. Thanks! I guess this feature could be extended to provide a unified API across sessions (kind of like multi-session operators, but maintained by hand).

>  There is no implicit conversions here for extending operators across sessions actually. For now I think the only operator which has inheritance is the EntityGroupOperator. Discrete session has its own derived version. 

I think this pattern works well when there is a generic means of accomplishing a task, but derived sessions have more optimized approaches. 

> Another special case are the Add image and Add auxiliary geometry operator.

Similarly, this pattern works when there is an operation that requires the action of a different operation as a part of its workflow. I don?t think these patterns provide us with a means of exposing our operators to models from different sessions, though (which is a feature that I think would be really cool). The idea of implicitly converting models between sessions would allow operators to convert models prior to execution, but is probably a bad idea (for the reasons Bob and David gave). 

Thomas J. Corona, Ph.D.
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

> On Jun 20, 2017, at 8:31 AM, Haocheng Liu <haocheng.liu at kitware.com> wrote:
> 
> 
> Good Morning TJ,
> 
> On Mon, Jun 19, 2017 at 10:49 PM, TJ Corona <tj.corona at kitware.com <mailto:tj.corona at kitware.com>> wrote:
>>> I?m not sure if having the model be implicitly being created is a good idea since the conversion may result in a loss of information
> 
> That?s true: I guess only some sessions would be able to convert back and forth without loss. Any implicit operations that resulted in an assumption of information or a loss of information would definitely be a bad thing.
> 
>> I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.
> 
> 
> Also true. This gets to the heart of one of the design patterns in SMTK that I don?t quite understand, though: how do we better exploit the common interface of the default session to construct operators that span multiple derived sessions? 
> I believe the current logic is that first we create operators for the default session and store them in the class variable defaultSession->m_operatorSys(smtk::attribute::system type). Next let's say we want to create a discrete session, we would then initialize discrete session operators and append dafault session's operators to discreteSession->m_operatorSys. Here we only copy definitions that do not already exist so we can realize "overriding operator". You can take a look at /smtk/model/Session.cxx#L1048 <https://gitlab.kitware.com/cmb/smtk/blob/master/smtk/model/Session.cxx#L1048> for detail.
> 
> The option of extending operators across sessions via implicit conversions is probably the wrong path, but I think that the problem it addresses is worth considering. Encompassing meta-operators that manually call their derived counterparts could work, but it seems like there is opportunity here for a more elegant solution. 
> 
>  There is no implicit conversions here for extending operators across sessions actually. For now I think the only operator which has inheritance is the EntityGroupOperator. Discrete session has its own derived version. Another special case are the Add image and Add auxiliary geometry operator. Add image operator has its own sbt file and internally it's using Add auxiliary geometry operator to load an image.
>  
>> But I think it is nice to have a way to perform the conversion. 
> 
> Me too! I?ve been thinking about the conversion between the mesh session and VTK in a similar context. We discussed wrapping SMTK mesh objects as zero-copy VTK objects, and I?d like to give that a try when I get a chance. Perhaps a similar paradigm could exist between some of the sessions.
> +1. I agree that mesh session would be a nice bridge :) 
> 
> Thomas J. Corona, Ph.D.
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4443 <tel:(518)%20881-4443>
>> On Jun 19, 2017, at 9:21 PM, David Thompson <david.thompson at kitware.com <mailto:david.thompson at kitware.com>> wrote:
>> 
>> Hi TJ,
>> 
>> I agree with Bob that implicit conversion could be a problem, especially when a similar operation exists in multiple sessions.
>> 
>> But I think it is nice to have a way to perform the conversion. In fact, the ERDC CS session has an operator for converting any non-parametric model into a model in that session. If we come up with a convention, we should make sure that operator is brought along for the ride.
>> 
>>     David
>> 
>> On Jun 19, 2017, at 22:08, Bob Obara <bob.obara at kitware.com <mailto:bob.obara at kitware.com>> wrote:
>> 
>>> Wouldn?t  the conversion to/from pair just be in a  separate plugin (since it would need to be built against a pair of sessions)?  In this case the conversion operators would be added to the corresponding sessions when the plugin is loaded.  I?m not sure if having the model be implicitly being created is a good idea since the conversion may result in a loss of information) - explicit conversion at least would inform the user of the conversion limitations - now a workflow that requires such a conversion (for example going from a polygonal planar model to a 3d non-planar discrete model after applying an elevation field) would be able to apply it implicitly when going from one task in the workflow to another since the workflow designer would have factored in the conversion issues when designing the workflow.
>>> 
>>> Does that make sense or am I missing something?
>>> 
>>> 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 <tel:(518)%20881-4931>
>>> 
>>> 
>>> 
>>> 
>>>> On Jun 19, 2017, at 6:45 PMEDT, TJ Corona <tj.corona at kitware.com <mailto:tj.corona at kitware.com>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I have an idea, and I?d like to know what everyone thinks. We currently have multiple sessions with different backings, and each of these sessions have a different set of operators that it can perform. To my understanding, if a user wants to cross from session to session, they currently have to do so manually (i.e. create a working model in one session, open the model in a new session and perform the operation). What if we created ?bridges? between sessions that facilitated to/from operations for each session pair, and then made these conversions implicit during model manipulation in ModelBuilder? For example, we create a bridge between the polygon and mesh sessions that describe how to convert a model of one type to the other (going from polygon to mesh would imply an implicit meshing operation, and going from mesh to model would imply an extraction of vertices, edges and faces in the mesh session to construct a polygon model). This way, a user could create a polygon model and then perform any of the meshing operations on it without having to know what session currently backs their model. Is this crazy?
>>>> 
>>>> Sincerely,
>>>> T.J.
>>>> 
>>>> Thomas J. Corona, Ph.D.
>>>> Kitware, Inc.
>>>> Senior R&D Engineer
>>>> 21 Corporate Drive
>>>> Clifton Park, NY 12065-8662
>>>> Phone: 518-881-4443 <tel:(518)%20881-4443>
>>>> _______________________________________________
>>>> Smtk-developers mailing list
>>>> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
>>>> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>
>>> 
>>> _______________________________________________
>>> Smtk-developers mailing list
>>> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
>>> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>
> 
> 
> _______________________________________________
> Smtk-developers mailing list
> Smtk-developers at smtk.org <mailto:Smtk-developers at smtk.org>
> http://public.kitware.com/mailman/listinfo/smtk-developers <http://public.kitware.com/mailman/listinfo/smtk-developers>
> 
> 
> 
> 
> -- 
> Best regards
> Haocheng
> 
> Haocheng LIU
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4421 <tel:(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170620/fd9569b1/attachment-0001.html>

From david.thompson at kitware.com  Tue Jun 20 10:22:37 2017
From: david.thompson at kitware.com (David Thompson)
Date: Tue, 20 Jun 2017 10:22:37 -0400
Subject: [Smtk-developers] An idea for connecting SMTK sessions
In-Reply-To: <E87DB9EA-FA94-4605-92B7-EF79E90C97CE@kitware.com>
References: <55C47FE0-3CA2-4CCE-9B6F-71E3B469AA9C@kitware.com>
 <65BE00AD-9C91-4DCB-A04C-B6D13E2D483F@kitware.com>
 <547199C0-FF96-4FD0-967C-148AB913A8C7@kitware.com>
 <91BA9840-80A7-4BE3-910E-310F5E21DAC2@kitware.com>
 <CACbTE7N3KAFUgahgs56fejQD6RsuytA2_5mcw3ep0TxJLbnCvg@mail.gmail.com>
 <E87DB9EA-FA94-4605-92B7-EF79E90C97CE@kitware.com>
Message-ID: <8131D308-35D2-4715-B61B-F08A7C63973D@kitware.com>

Hi TJ,

> ... The idea of implicitly converting models between sessions would allow operators to convert models prior to execution, but is probably a bad idea (for the reasons Bob and David gave). 

It's not the conversion that's a bad idea. It's the implicit part. But that doesn't mean the conversion couldn't be explicit and yet automatic. However, we must be careful to expose it in a user-friendly and understandable way. Even exposing operators for the current session is something that needs work in ModelBuilder before I am happy, so this seems like a secondary goal for now, but one I am interested in.

	David

From david.thompson at kitware.com  Wed Jun 21 14:57:16 2017
From: david.thompson at kitware.com (David Thompson)
Date: Wed, 21 Jun 2017 14:57:16 -0400
Subject: [Smtk-developers] CMBv5 changes
Message-ID: <547E8870-F9AD-48CC-AF8E-A12251182285@kitware.com>

Hi Bob,

We've talked about splitting the model representation in ParaView apart in v5 so that vertices, edges, faces, etc. each have a separate representation so that picking/selection and filtering can be done using the PV pipeline.

One potential pitfall is that PV doesn't appear to guarantee any particular rendering order for the representations within a view, which could put us back to having edges and vertices hidden by faces. Perhaps we can ask Utkarsh if there's a way to specify render order when he's around?

	David

From tj.corona at kitware.com  Fri Jun 30 09:40:53 2017
From: tj.corona at kitware.com (TJ Corona)
Date: Fri, 30 Jun 2017 09:40:53 -0400
Subject: [Smtk-developers] Dashboard matron
Message-ID: <25A26759-ED62-460D-A0C2-EBDB113E485A@kitware.com>

Hi all,

I just wanted you to know that the dashboard matron has duly admonished the party responsible for breaking the dashboards last night? me. They should be fixed now. Sorry!

Sincerely,
T.J.

Thomas J. Corona, Ph.D.
Kitware, Inc.
Senior R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

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