From michalwozniak at live.ca  Wed Feb  1 13:39:10 2017
From: michalwozniak at live.ca (michal wozniak)
Date: Wed, 1 Feb 2017 18:39:10 +0000
Subject: [Cmb-users] smtk build fail during cmb superbuild
In-Reply-To: <013AB4A1-68CB-45A8-AFD4-5BA3A7AEA445@kitware.com>
References: <DM5PR13MB1660214711062A92F5BF1B3AAD760@DM5PR13MB1660.namprd13.prod.outlook.com>
 <1908A492-9221-4415-9D3E-AF1BDCA4E44A@kitware.com>
 <DM5PR13MB1660D33199073D112C355A29AD4A0@DM5PR13MB1660.namprd13.prod.outlook.com>,
 <013AB4A1-68CB-45A8-AFD4-5BA3A7AEA445@kitware.com>
Message-ID: <DM5PR13MB166073E487499BD1F4506DD2AD4D0@DM5PR13MB1660.namprd13.prod.outlook.com>

Hi T.J.


I am currently trying to build a static build of CGM but I getting some errors


CMake Error: install(EXPORT "cgm" ...) includes target "cgma_init" which requires target "cholla" that is not in the export set.

CMake Error: install(EXPORT "cgm" ...) includes target "cgma_init" which requires target "cubit_facetboolstub" that is not in the export set.

CMake Error: install(EXPORT "cgm" ...) includes target "cgma_init" which requires target "cubit_facet" that is not in the export set.

CMake Error: install(EXPORT "cgm" ...) includes target "cgma_init" which requires target "cubit_virtual" that is not in the export set.

CMake Error: install(EXPORT "cgm" ...) includes target "cgma_init" which requires target "cubit_occ" that is not in the export set.

CMake Error: install(EXPORT "cgm" ...) includes target "cgma_init" which requires target "cubit_parallel" that is not in the export set.




I have never exported subproject to main projects before, do you have any suggestions or some documentation about this which I could read?


thank you

Michal


________________________________
From: TJ Corona <tj.corona at kitware.com>
Sent: Tuesday, January 31, 2017 11:09 PM
To: michal wozniak
Cc: cmb-users at computationalmodelbuilder.org
Subject: Re: [Cmb-users] smtk build fail during cmb superbuild

Hi Michal,

It looks as though CGM does not export its symbols properly on Windows. Perhaps you could try linking against a static build of CGM?

Sincerely,
T.J.

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

On Jan 31, 2017, at 5:27 PM, michal wozniak <michalwozniak at live.ca<mailto:michalwozniak at live.ca>> wrote:

Hi,

I looked through your CmakeCache (https://open.cdash.org/viewNotes.php?buildid=4733420#!#note3) and saw that you were building in 64 bit. I tried once more in 64 bit and it worked!

Then I tried again but this time I enabled cgm (ENABLE_cgm) and it failed during the smtk build.

"bin\smtkCGMSession.dll : fatal error LNK1120: 4 unresolved externals"

do I need something else to be able to build cmb with cgm?

Thank you
Michal

________________________________
From: TJ Corona <tj.corona at kitware.com<mailto:tj.corona at kitware.com>>
Sent: Friday, January 27, 2017 12:12 PM
To: michal wozniak
Cc: cmb-users at computationalmodelbuilder.org<mailto:cmb-users at computationalmodelbuilder.org>
Subject: Re: [Cmb-users] smtk build fail during cmb superbuild

Hi Michal,

I just built CMB using the superbuild with the same specs that you listed, and was unable to reproduce the error. CMB superbuild does pull SMTK and CMB from the latest master, so perhaps try a clean build again?

Sincerely,
T.J.

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

On Jan 27, 2017, at 9:48 AM, michal wozniak <michalwozniak at live.ca<mailto:michalwozniak at live.ca>> wrote:

Hi,

I am trying to build CMB using the super build but I am getting a failed build error during the SMTK build phase.

"Creating library lib\vtkSMTKReaderExt-7.1.lib and object lib\vtkSMTKReaderExt-7.1.exp
bin\vtkSMTKReaderExt-7.1.dll : fatal error LNK1169: one or more multiply defined symbols found"


building on win 10 using Visual studio 2013,  ninja & qt 4.8.6.

I have looked a bit through the source code and can't seem to find the cause that could trigger this error.

Michal Wozniak

<smtkError.txt>_______________________________________________
Cmb-users mailing list
Cmb-users at computationalmodelbuilder.org<mailto:Cmb-users at computationalmodelbuilder.org>
http://public.kitware.com/mailman/listinfo/cmb-users

<cgm_enabled_smtkFailed.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmb-users/attachments/20170201/e02713ca/attachment.html>

From ben.boeckel at kitware.com  Wed Feb  1 16:43:34 2017
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 1 Feb 2017 16:43:34 -0500
Subject: [Cmb-users] smtk build fail during cmb superbuild
In-Reply-To: <DM5PR13MB166073E487499BD1F4506DD2AD4D0@DM5PR13MB1660.namprd13.prod.outlook.com>
References: <DM5PR13MB1660214711062A92F5BF1B3AAD760@DM5PR13MB1660.namprd13.prod.outlook.com>
 <1908A492-9221-4415-9D3E-AF1BDCA4E44A@kitware.com>
 <DM5PR13MB1660D33199073D112C355A29AD4A0@DM5PR13MB1660.namprd13.prod.outlook.com>
 <013AB4A1-68CB-45A8-AFD4-5BA3A7AEA445@kitware.com>
 <DM5PR13MB166073E487499BD1F4506DD2AD4D0@DM5PR13MB1660.namprd13.prod.outlook.com>
Message-ID: <20170201214334.GA22021@megas.kitware.com>

On Wed, Feb 01, 2017 at 18:39:10 +0000, michal wozniak wrote:
> I have never exported subproject to main projects before, do you have
> any suggestions or some documentation about this which I could read?

The targets referenced here need exported. Roughly, each place which
does add_library(libname) needs this code too:

    install(
      TARGETS   ${libname}
      EXPORT    cgm
      COMPONENT Runtime)
    set_property(GLOBAL APPEND
      PROPERTY cgma_export_targets
        ${libname})

But it appears that more work needs to be done to get cgm to work in a
static build (on any platform).

--Ben

From bob.obara at kitware.com  Fri Feb  3 14:32:20 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Fri, 3 Feb 2017 14:32:20 -0500
Subject: [Cmb-users] 10.12 SDK and OpenCascade
Message-ID: <376D7E60-62CC-43D6-95D5-B77BEA34280D@kitware.com>

Hi All,

For those of you who are building on the Mac, I just noticed that OpenCASCADE will not compile using Xcode?s 10.12 SDK (it will work using 10.11). The issue is that Apple now defines some of the time enums used in OCE.  So if you are upgrading Xcode and want to build OpenCASCADE support make sure you have copied the 10.11 SDK and have put it in a safe place!

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/cmb-users/attachments/20170203/d8973d5e/attachment.html>

From deleeke at gmail.com  Sat Feb 11 15:40:51 2017
From: deleeke at gmail.com (Elijah DeLee)
Date: Sat, 11 Feb 2017 15:40:51 -0500
Subject: [Cmb-users] python UCS2 or UCS4
Message-ID: <CALYfLKT9nf82vZe963wEsXNMz74UXhjg9kPd6XVuY89KJQNqfw@mail.gmail.com>

Hello!

I am a student at UNC Chapel Hill and I have been working with Bob and John
over there at Kitware on creating a simulation template so IBAMR (
https://github.com/IBAMR/IBAMR/)  users can use Computational Model Builder
to set up their simulations.

I use IPython and Jupyter notebooks and would like to be able to import the
smtk module so I can explore and test out more of its functionality.

Unfortunately the python 2.7 packaged with CMB appears to have been
installed with 2-byte unicode characters:

$ /path/to/CMBpython

>>> import sysconfig
>>> sysconfig.get_config_var('Py_UNICODE_SIZE')
2


This is not compatible with my system Ipython kernel...I believe Ubuntu
14.04 and later have moved to 4-byte unicode characters.

Is there a way I can build CMB where python is compiled to use 4-byte
Unicode characters? I'm not sure how to set this option when building CMB
with CMake.

If I was building it from source myself I could install it like so:


./configure --enable-unicode=ucs4
make
make install./configure --enable-unicode=ucs4

My thought is that if it is installed with UCS4, then it will build/install
all the modules correctly and then I can access them with my system ipython
by appropriately using sys.path.append("path/to/smtk").

Thanks for your time,
Elijah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmb-users/attachments/20170211/0a239f97/attachment.html>

From david.thompson at kitware.com  Sat Feb 11 17:13:06 2017
From: david.thompson at kitware.com (David Thompson)
Date: Sat, 11 Feb 2017 17:13:06 -0500
Subject: [Cmb-users] python UCS2 or UCS4
In-Reply-To: <CALYfLKT9nf82vZe963wEsXNMz74UXhjg9kPd6XVuY89KJQNqfw@mail.gmail.com>
References: <CALYfLKT9nf82vZe963wEsXNMz74UXhjg9kPd6XVuY89KJQNqfw@mail.gmail.com>
Message-ID: <6DDA4D25-139C-4D8E-8A54-1C492894E124@kitware.com>

Hi Elijah,

> ....
> I use IPython and Jupyter notebooks and would like to be able to import the smtk module so I can explore and test out more of its functionality.
> 
> Unfortunately the python 2.7 packaged with CMB appears to have been installed with 2-byte unicode characters: ...

If you need CMB compiled with different options, you will probably need to build it yourself. There is a "superbuild" project we use to build the dependencies of CMB plus CMB itself, located on gitlab at http://gitlab.kitware.com/cmb/cmb-superbuild/ . That page has build instructions. After building, you can go into its python build dir (build/superbuild/python/build), reconfigure, and then reinstall.

You may also be able to configure the superbuild to use your system's python -- I just don't remember whether that's an option or not.

Note that we don't support Python3 yet.

    David

> 
> $ /path/to/CMBpython
> 
> >>> import sysconfig
> >>> sysconfig.get_config_var('Py_UNICODE_SIZE')
> 2
> 
> This is not compatible with my system Ipython kernel...I believe Ubuntu 14.04 and later have moved to 4-byte unicode characters.
> 
> Is there a way I can build CMB where python is compiled to use 4-byte Unicode characters? I'm not sure how to set this option when building CMB with CMake.
> 
> If I was building it from source myself I could install it like so:
> 
> ./configure --enable-unicode=ucs4
> make 
> make install./configure --enable-unicode=ucs4
> 
> My thought is that if it is installed with UCS4, then it will build/install all the modules correctly and then I can access them with my system ipython by appropriately using sys.path.append("path/to/smtk").
> 
> Thanks for your time,
> Elijah
> _______________________________________________
> Cmb-users mailing list
> Cmb-users at computationalmodelbuilder.org
> http://public.kitware.com/mailman/listinfo/cmb-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmb-users/attachments/20170211/7f1e9b66/attachment.html>

From bob.obara at kitware.com  Fri Feb 24 17:26:49 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Fri, 24 Feb 2017 17:26:49 -0500
Subject: [Cmb-users] Possible new way of dealing with color
Message-ID: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com>

Hi All,

We are in the process of cleaning up the color mechanism of CMB.  The main issue we are trying to address is the following:

Introduce ?default colors? for various model entity types (vertices, edges, faces, volumes, etc..)  - For example being able to say all edges by default are to be blue while all faces should be white
The ability to specify the color for the specific model entity 
The ability to tell default color from explicit color


The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following:
You can?t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults
The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc?  We never did follow through with this patter and as a result the icon doesn?t have a lot of meaning
Setting the color of a session or model doesn?t have an effect on rendering the geometry

My first alternative (Left Middle) was to make the icon more of a defined area my enclosing then - in fact my complete idea was to dashed the circle to indicate the fact that the color was not explicitly set and was being inherited but when I showed people it was not obvious that was what I meant

The third option removed the icon and used a simple circle to indicate color.  This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow.  Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle.

Comments?

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/cmb-users/attachments/20170224/ed6ea972/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewModelColorPanel.png
Type: image/png
Size: 112223 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmb-users/attachments/20170224/ed6ea972/attachment-0001.png>

From david.thompson at kitware.com  Sat Feb 25 18:53:34 2017
From: david.thompson at kitware.com (David Thompson)
Date: Sat, 25 Feb 2017 18:53:34 -0500
Subject: [Cmb-users] [Smtk-developers] Possible new way of dealing with
	color
In-Reply-To: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com>
References: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com>
Message-ID: <D0B60E47-4F30-41DF-AE20-D953BA6C8910@kitware.com>

> ...
> 	? Introduce ?default colors? for various model entity types (vertices, edges, faces, volumes, etc..)  - For example being able to say all edges by default are to be blue while all faces should be white
> 	? The ability to specify the color for the specific model entity 
> 	? The ability to tell default color from explicit color
> <NewModelColorPanel.png>
> 
> The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following:
> 	? You can?t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults

Agreed.

> 	? The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc?  We never did follow through with this patter and as a result the icon doesn?t have a lot of meaning

I would prefer to keep them because

1. I suspect we are about to get icons for the different entity types shortly ("Filter By" feature)

2. Because some sessions (e.g., exodus) present tessellations on groups or other entity types that may not be intuitive, the "Filter By" feature will benefit from tree views where the entity type is shown using the same icon.

3. It is a fast and simple change once we actually have the icons.

> 	? Setting the color of a session or model doesn?t have an effect on rendering the geometry
> 
> ...
> 
> The third option removed the icon and used a simple circle to indicate color.  This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow.  Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle.

I like it. However, note that the Exodus reader creates those groups ("Node Sets", "Side Sets", "Element Blocks") explicitly since they are part of the file. The "Topology View" won't always have those same groups. The "Entity List View" will, and it will be easier to attach functions that set color defaults to them compared to the Exodus session groups.

Since I believe CMB defaults to the "Entity List View," this should be fine.

Where did you want the "default" or "inheritable" colors stored? As application settings (which then belong in CMB, not SMTK), per-session settings, per-model settings, per-group settings (which is what you have shown, but we do not currently create default groups and assign entities there)?

If we use the "set entity property" operator to store the default colors (as well as per-entity colors), then it will be easier for the VTK adaptor to assign per-block colors. This would be easiest if we set default colors as properties on the model since CMB currently creates a VTK adaptor per model and groups all entities of the same type into one block of its output multiblock dataset (making it easy to discover the default color given only the VTK dataset).

	David

From bob.obara at kitware.com  Sun Feb 26 15:39:08 2017
From: bob.obara at kitware.com (Bob Obara)
Date: Sun, 26 Feb 2017 15:39:08 -0500
Subject: [Cmb-users] [Smtk-developers] Possible new way of dealing with
	color
In-Reply-To: <D0B60E47-4F30-41DF-AE20-D953BA6C8910@kitware.com>
References: <93A9211F-3041-4B13-8847-EF7FF18DDD01@kitware.com>
 <D0B60E47-4F30-41DF-AE20-D953BA6C8910@kitware.com>
Message-ID: <B9863B43-922D-47BB-8A4C-6728EDFC35A0@kitware.com>

Hey David,

You raised some good points - see below.

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 Feb 25, 2017, at 6:53 PMEST, David Thompson <david.thompson at kitware.com> wrote:
> 
>> ...
>> 	? Introduce ?default colors? for various model entity types (vertices, edges, faces, volumes, etc..)  - For example being able to say all edges by default are to be blue while all faces should be white
>> 	? The ability to specify the color for the specific model entity 
>> 	? The ability to tell default color from explicit color
>> <NewModelColorPanel.png>
>> 
>> The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following:
>> 	? You can?t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults
> 
> Agreed.
> 
>> 	? The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc?  We never did follow through with this patter and as a result the icon doesn?t have a lot of meaning
> 
> I would prefer to keep them because
> 
> 1. I suspect we are about to get icons for the different entity types shortly ("Filter By" feature)
> 
> 2. Because some sessions (e.g., exodus) present tessellations on groups or other entity types that may not be intuitive, the "Filter By" feature will benefit from tree views where the entity type is shown using the same icon.
> 

I was thinking of the Exodus Session - what do you think of having the Exodus Session create faces for each side set and a volume for each element block?  This way the session looks like all the other ones?  In the future we could create an operator that would create proper partitioned model faces (as well as creating model edges and vertices)  What do you think?

> 3. It is a fast and simple change once we actually have the icons.
> 
If we did stick with icons then we should provide the ability for a workflow to be able to swap them out - for example in Hydrology the edge symbol could be made to look like a coast line.  The one thing is that they should be B/W images)
>> 	? Setting the color of a session or model doesn?t have an effect on rendering the geometry
>> 
>> ...
>> 
>> The third option removed the icon and used a simple circle to indicate color.  This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow.  Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle.
> 
> I like it. However, note that the Exodus reader creates those groups ("Node Sets", "Side Sets", "Element Blocks") explicitly since they are part of the file. The "Topology View" won't always have those same groups. The "Entity List View" will, and it will be easier to attach functions that set color defaults to them compared to the Exodus session groups.
My suggestion above would address this.

> 
> Since I believe CMB defaults to the "Entity List View," this should be fine.
> 
> Where did you want the "default" or "inheritable" colors stored? As application settings (which then belong in CMB, not SMTK), per-session settings, per-model settings, per-group settings (which is what you have shown, but we do not currently create default groups and assign entities there)?
> 
> If we use the "set entity property" operator to store the default colors (as well as per-entity colors), then it will be easier for the VTK adaptor to assign per-block colors. This would be easiest if we set default colors as properties on the model since CMB currently creates a VTK adaptor per model and groups all entities of the same type into one block of its output multiblock dataset (making it easy to discover the default color given only the VTK dataset).

I think that the default colors should be stored in the model?s SMTK file - the application would have a preference for what the application would set the default colors would be for new models being created.  I guess we could have in the future a per session set of default colors.

> 
> 	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmb-users/attachments/20170226/11946863/attachment.html>