From david.thompson at kitware.com Mon Dec 1 09:57:09 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Dec 2014 09:57:09 -0500 Subject: [Smtk-developers] New CGM operations Message-ID: Hi all, I've pushed another batch of CGM operators to SMTK: + Copy + Reflect + Scale Since the CGM operators are becoming more numerous, I've shuffled them all into a subdirectory (smtk/bridge/cgm/operators). At some point, it would be nice to add more documentation to the XML files and include summaries of the operators in the user's guide. Are the documentation strings in attribute XML files supposed to be HTML or plain text? If the latter, we might treat them as reStructuredText for a fancier user's guide experience. David PS. The "add a bridge" tutorial is expanded and covers a good bit of the Exodus bridge's implementation. http://smtk.readthedocs.org/en/latest/tutorials/add_a_bridge/index.html From david.thompson at kitware.com Mon Dec 1 14:23:33 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 Dec 2014 14:23:33 -0500 Subject: [Smtk-developers] SMTK in Python Message-ID: <9935CE08-8C49-403A-A96A-48F1FF8BCD10@kitware.com> Hi all, I have noticed a recurring pattern to the Python model-operator tests and think there is space for a "simple" API (like paraview.simple) for model operations. If there's nothing else on the agenda for our meeting tomorrow, I'd like to put this on the agenda. Many of the tests have blocks of Python that look like this: cb = sess.op('create brick') ov = cb.findAsInt('construction method') ov.setDiscreteIndex(0) ctr = cb.findAsDouble('center') setVector(ctr, [1., 0., 0.]) cb.findAsDouble('width').setValue(0.5) res = cb.operate() Really, all of these lines could be simplified to something like: result = sess.operate('create brick', \ {'construction method':0, \ 'center': [1., 0., 0.], \ 'width':0.5}) Are there objections to adding a Python function that does this to smtk.py? Should I do like ParaView and make an smtk.simple submodule? Suggestions for improvements? I can see one issue is that if the "construction method" item above isn't the first one set, the "width" item won't be active (so all children would have to be searched, not just the active children). The method above is specific to operators, but in general it seems like a more concise method for creating and setting attributes is possible. Thanks, David From john.tourtellott at kitware.com Tue Dec 2 15:04:53 2014 From: john.tourtellott at kitware.com (John Tourtellott) Date: Tue, 2 Dec 2014 15:04:53 -0500 Subject: [Smtk-developers] Can't build SMTK python wrappers no more Message-ID: Has anyone else seen this error building python wrappers? [ 20%] Building CXX object smtk/CMakeFiles/SMTKCorePython.dir/SMTKCorePython/smtk_shared_ptr_smtk_model_bridge__wrapper.cpp.o /media/ssd/sim/cmb_core/build/testSMTK/smtk/SMTKCorePython/smtk_shared_ptr_smtk_model_bridge__wrapper.cpp: In function ?PyObject* Sbk_smtk_shared_ptr_smtk_model_Bridge_Func_findOperatorConstructor(PyObject*, PyObject*)?: /media/ssd/sim/cmb_core/build/testSMTK/smtk/SMTKCorePython/smtk_shared_ptr_smtk_model_bridge__wrapper.cpp:215:114: error: conversion from ?smtk::model::OperatorConstructor {aka std::tr1::shared_ptr (*)()}? to non-scalar type ?std::tr1::shared_ptr? requested smtk::shared_ptr< smtk::model::Operator > cppResult = cppSelf->get()->findOperatorConstructor(cppArg0); Interestingly, I find the underlying method -- smtk::model::Bridge::findOperatorConstructor() -- defined inside a #if SHIBOKEN_SKIP directive, so I wonder if I'm missing something. I also tried removing this function in the typesystem.xml, but that was NG too. - When I add a element to remove it from smtk::model::Bridge, the method still appears in the wrapper for smtk::shared_ptr, - And when I add a element to remove it from smtk::shared_ptr, shiboken crashes. Can anyone help? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Dec 2 15:09:33 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 2 Dec 2014 15:09:33 -0500 Subject: [Smtk-developers] Can't build SMTK python wrappers no more In-Reply-To: References: Message-ID: <93B03337-3FBD-4D40-86DC-FAA8D413A436@kitware.com> > Has anyone else seen this error building python wrappers? 1. Are you using the OpenGeoScience/smtk-head branch of shiboken? It is the only one that defines SHIBOKEN_SKIP. 2. Have you got SMTK headers in both your source directory and the install directory? I find it useful to rm `cat install_manifest.txt` before rebuilding. 3. I am not sure that all the dependencies are correctly computed. Sometimes after fixing #1 or #2 above, I have to forcibly remove the generated wrapper files and re-run cmake to get things going again. David From john.tourtellott at kitware.com Tue Dec 2 15:33:51 2014 From: john.tourtellott at kitware.com (John Tourtellott) Date: Tue, 2 Dec 2014 15:33:51 -0500 Subject: [Smtk-developers] Can't build SMTK python wrappers no more In-Reply-To: <93B03337-3FBD-4D40-86DC-FAA8D413A436@kitware.com> References: <93B03337-3FBD-4D40-86DC-FAA8D413A436@kitware.com> Message-ID: Yes! I had an old version of shiboken. THANKS! On Tue, Dec 2, 2014 at 3:09 PM, David Thompson wrote: > > Has anyone else seen this error building python wrappers? > > 1. Are you using the OpenGeoScience/smtk-head branch of shiboken? It is > the only one that defines SHIBOKEN_SKIP. > > 2. Have you got SMTK headers in both your source directory and the install > directory? I find it useful to > > rm `cat install_manifest.txt` > > before rebuilding. > > 3. I am not sure that all the dependencies are correctly computed. > Sometimes after fixing #1 or #2 above, I have to forcibly remove the > generated wrapper files and re-run cmake to get things going again. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Tue Dec 2 22:07:01 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Tue, 2 Dec 2014 22:07:01 -0500 Subject: [Smtk-developers] cmb_v4 update Message-ID: Hi, Just pushed something to cmb_v4, which will allow controlling display properties of model entities by right-click context menu in 3D render view. I still need to add UI components inside smtk so that user can also control visibility and setting color from the model tree view, but at least for now, you can use the context menu in the render view. Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From yumin.yuan at kitware.com Wed Dec 3 10:00:48 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Wed, 3 Dec 2014 10:00:48 -0500 Subject: [Smtk-developers] cmb_v4 update In-Reply-To: References: Message-ID: I forgot to mention that the display controls in the context menu is based on which model entity you right-clicked on in the view, if you don't click on any entity (geometry), the context menu will only contains "Show All Models". Yumin On Tue, Dec 2, 2014 at 10:07 PM, Yumin Yuan wrote: > Hi, > > Just pushed something to cmb_v4, which will allow controlling display > properties of model entities by right-click context menu in 3D render view. > I still need to add UI components inside smtk so that user can also control > visibility and setting color from the model tree view, but at least for > now, you can use the context menu in the render view. > > Yumin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Dec 3 11:40:28 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 3 Dec 2014 11:40:28 -0500 Subject: [Smtk-developers] Q: Tool vs workpiece In-Reply-To: <152F7D0A-6787-409C-916D-121F8DCDBC18@kitware.com> References: <71E498C1-A2A6-4B45-A939-FB2252DCD23D@kitware.com> <152F7D0A-6787-409C-916D-121F8DCDBC18@kitware.com> Message-ID: > Thats my mindset as well. Good, because that's what the operators now implement. :-) David > On Nov 11, 2014, at 3:38 PM, David Thompson wrote: > >> Hi Bob, >> >> Do you have a strong preference for whether the tool or the workpiece are associated with the boolean operators (as opposed to being items owned by the operator)? >> >> If you don't, I do. I am a subject-verb-object kind of a guy, and think of the subject as the piece that stays around afterwards (so pronouns can reference it)... so I vote for associating the workpiece to an operator and then adding the tool to the operator. >> >> Thanks, >> David > From david.thompson at kitware.com Wed Dec 3 11:46:19 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 3 Dec 2014 11:46:19 -0500 Subject: [Smtk-developers] Associating entities vs adding items In-Reply-To: <1973CE1B-F10C-422D-81AE-E2006CA6B0AE@kitware.com> References: <1A0F8AB1-43B0-4EDB-A527-99643A8918B2@kitware.com> <5016F9EE-D7D4-4D66-BCC1-601170716430@kitware.com> <1973CE1B-F10C-422D-81AE-E2006CA6B0AE@kitware.com> Message-ID: <2DA4C5AB-EECD-4782-82F5-D5A66F7626F7@kitware.com> I don't see where I've replied to the list, so here goes: These changes are now in SMTK. Each Definition owns a ModelEntityItemDefinition that specifies what associations are allowed. When an Attribute is created using the definition, a ModelEntityItem is created on demand when allowed. It can be obtained by calling Attribute::associations(), but be aware that it will be a NULL shared pointer if no associations are allowed. The next step is to work with Yumin on generating a UI element for it when it exists so that the model operators can have their associations modified. David On Nov 14, 2014, at 12:56 PM, David Thompson wrote: > Hi all, > >> I don't see how this would resolve anything - The simplest solution would be to have a property on the definition indicating the max number of model entities the attribute could be associated with. >> >> Give me a call and we can discuss this. > > Apparently I was able to communicate better over the phone than e-mail. :-) We will use a ModelEntityItemDefinition owned by each Definition to describe possible associations and a ModelEntityItem owned by each corresponding Attribute to store the actual list of associated entities. The API to Attribute for associating entities will stay the same but use these instances underneath the hood to do the work (eliminating duplicate code). > > The XML for indicating associations will change from having an XML attribute of AttDef named "Associations" to a child element of AttDef named "Associations". It will be parsed as if it were a ModelEntityItemDefinition. Its absence indicates that attributes are not allowed to have associations of any type. So, > > > > > > will become > > > > > > > A similar change will be made for specifying attribute instances in XML. > > By making the ModelEntityItem and ModelEntityItemDefinition instances available from the Attribute and Definition (respectively), the GUI panels can also add UI elements corresponding to associations. This is important for SMTK operators since currently things like the "union" operator do not provide any way to change or set the workpieces to process. > > These changes should go in next week some time. > > David > > >>> Yumin and I were discussing CMBv4 and Yumin mentioned that while attributes can indicate the type of entities they may be associated with, there is no way to describe limits on the number of entities (e.g., a subtract operator may support only a single workpiece at a time, but the GUI cannot infer that too many models are selected for the subtract operator). >>> >>> One way we might accommodate storing extra information about associations is to ditch the way associations are currently stored and create a special ModelEntityItem that is marked as the attribute's associations. Instead of >>> >>> >>> >>> ... >>> >>> >>> >>> we would have >>> >>> >>> >>> >>> ... >>> >>> >>> >>> >>> Any opinions? >>> David >>> _______________________________________________ >>> Smtk-developers mailing list >>> Smtk-developers at smtk.org >>> http://public.kitware.com/mailman/listinfo/smtk-developers >> > From david.thompson at kitware.com Wed Dec 3 11:51:56 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 3 Dec 2014 11:51:56 -0500 Subject: [Smtk-developers] Exodus bridge In-Reply-To: <0B83742B-3E2F-45B0-9141-B6D05A701332@kitware.com> References: <2636ABF2-3A6A-4EBF-9E25-9B0686FCF136@kitware.com>

<4842C793-90AC-4248-A838-97CD6D0B5770@kitware.com> <0B83742B-3E2F-45B0-9141-B6D05A701332@kitware.com> Message-ID: <729F5B46-3A13-406C-813F-7C0F6B3CDBCA@kitware.com> > If I understand you correctly, Actually the association should pay attention to the group bits. It did not but does now. However, there are still some corner cases left. For instance, an empty group without either MODEL_DOMAIN or MODEL_BOUNDARY set will be shown and allowed to associate with the attribute. But there are no checks to prevent you from adding the wrong type of entity (from the attribute's point of view) to the group later. We need to implement that still. David > On Nov 17, 2014, at 10:20 PM, Yumin Yuan wrote: > >> Hi Dave, >> >> On Mon, Nov 17, 2014 at 9:55 PM, David Thompson wrote: >> Hi Yumin, >> >> You are correct; the Exodus bridge doesn't create faces or volumes inside the groups. However it does mark the groups as MODEL_DOMAIN or MODEL_BOUNDARY depending on whether they contain volumes or faces/edges/nodes, respectively. We could (1) change the bridge to create either a single volume or face per group; or (2) add some logic to associations so that they pay attention to group constraint bits like those above; or (3) do #2 but with dimension-specific constraint bits (like "this group may only hold 1-d and 2-d cells"). >> >> It would not be simple to change the bridge to expose every element side or node as a separate model entity because the numbering in Exodus files is painfully complex. At that point, we are better off reviving more discrete model functionality from v3 to v4. >> >> >> I agree, and (2) or (3) options above sound reasonable to me. >> >> Yumin >> >> David >> >> On Nov 17, 2014, at 17:55, Yumin Yuan wrote: >> >>> >>> >>> On Mon, Nov 17, 2014 at 5:43 PM, David Thompson wrote: >>> Hi all, >>> >>> I've merged some changes to master that store element block, side set, and node set IDs on the SMTK model entities. So, in Python you can >>> >>> # ... load file as in script below ... >>> result = rdr.operate() >>> model = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >>> for group in model.groups(): >>> print group.name(), group.stringProperty('exodus type'), group.integerProperty('exodus id') >>> >>> and get >>> >>> Unnamed block ID: 1 Type: HEX ['element block'] [1] >>> Unnamed block ID: 2 Type: HEX ['element block'] [2] >>> Unnamed set ID: 4 ['side set'] [4] >>> Unnamed set ID: 1 ['node set'] [1] >>> Unnamed set ID: 100 ['node set'] [100] >>> >>> >>> Nice! >>> >>> I am about halfway through modernizing the Hydra Python exporter script to use the new model. Once I'm done and Yumin has the association widget working we should have an end-to-end demo. (!!!) >>> >>> >>> >>> The association widget is working now. I have to change the template file a little bit. >>> Associations="f" ==> Associations="g" // for group >>> Associations="r" ==> Associations="m" // for model to assign material, I guess the "Exodus" reader-parser did not construct a volume. >>> >>> Caveat, there are some runtime warnings from cmb_v4 related to "duplicate command function". I think this is happening when loading CMB_plugin, and erdcAppCommon is also linking against CMB_plugin. I will track this down later. >>> >>> >>> Yumin >>> >>> David >>> >>> > ... >>> > I can certainly help with the exporter part. I will call you to discuss a bit. >>> > >>> > Yumin >>> > >>> > On Mon, Nov 17, 2014 at 11:29 AM, David Thompson wrote: >>> > Hi Yumin, >>> > >>> > I've pushed a simple example bridge to SMTK master that uses VTK's Exodus reader to read side and node set information in as groups. No cells (volumes/faces/edges/vertices) are included, but the blocks and sets have tessellation information. You can do this: >>> > >>> > import smtk >>> > mgr = smtk.model.Manager.create() >>> > sess = mgr.createSession('exodus') >>> > rdr = sess.op('read') >>> > rdr.findAsFile('filename').setValue('can.ex2') >>> > res = rdr.operate() >>> > me = smtk.model.ModelEntity(res.findModelEntity('model').value(0)) >>> > print '\n'.join([x.name() for x in me.groups()]) >>> > >>> > which will print this: >>> > >>> > Unnamed block ID: 1 Type: HEX >>> > Unnamed block ID: 2 Type: HEX >>> > Unnamed set ID: 4 >>> > Unnamed set ID: 1 >>> > Unnamed set ID: 100 >>> > >>> > Because each group has a Tessellation associated with it you should be able to render the side and node sets as well as element blocks. There are a few things left to do and then we will have an end-to-end example of simulation preparation using (unaltered) Exodus files. >>> > >>> > 1. Verify that the vtkModelMultiBlockSource properly includes the tessellation information attached to the side and node sets. >>> > 2. Add properties to the groups from the Exodus reader's metadata (describing set IDs). >>> > 3. Adapt an exporter to the new model. >>> > >>> > I can do #1-2, but will need some help with #3. >>> > >>> > David >>> > >>> >>> >> > From david.thompson at kitware.com Thu Dec 4 21:02:59 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 4 Dec 2014 21:02:59 -0500 Subject: [Smtk-developers] "Universal" operators Message-ID: Hi all, I've pushed some changes to SMTK that allow "universal" operators (i.e., operators that may be invoked on any bridge). The impetus for this was 1. Exporters may now be operators that do not care about the types of models being processed. 2. The "set property" operator is now provided as a universal operator. It can be used to change the name or color of any model entity (or any other values stored using the model property system) without regard to the bridge type. Unlike methods on the cursor classes that allow changes to be made, this operator works with remote bridges as well -- changes on the client should be propagated to the server. Note that this also required a small change to CMBv4, so you will need to update both repositories if you update either. David From david.thompson at kitware.com Thu Dec 4 21:07:08 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 4 Dec 2014 21:07:08 -0500 Subject: [Smtk-developers] cmb_v4 update In-Reply-To: References:

Message-ID: <0A83D74A-42A1-4B4C-96C6-9C307872D822@kitware.com> Hi Yumin, >> Just pushed something to cmb_v4, which will allow controlling display properties of model entities by right-click context menu in 3D render view. I still need to add UI components inside smtk so that user can also control visibility and setting color from the model tree view, but at least for now, you can use the context menu in the render view. >> > I forgot to mention that the display controls in the context menu is based on which model entity you right-clicked on in the view, if you don't click on any entity (geometry), the context menu will only contains "Show All Models". This looks great! And the "universal operators" branch I've merged into SMTK includes a model operator ("set property") that can be used to change the color and other modeling-entity properties, even across remote bridges. So it should be possible to keep the Qt UI and ParaView UI in sync, although that will also require redraw events to be emitted when the operator is run. I would have changed pqModelBuilderViewContextMenuBehavior::setBlockColor (and the other methods that change the visibility and opacity) so that they invoke the operator, but I don't see how to obtain the SMTK UUID associated the block in question. Can you give me a call tomorrow so we can discuss how to make that work? Thanks, David From yumin.yuan at kitware.com Thu Dec 4 21:48:49 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Thu, 4 Dec 2014 21:48:49 -0500 Subject: [Smtk-developers] cmb_v4 update In-Reply-To: <0A83D74A-42A1-4B4C-96C6-9C307872D822@kitware.com> References:

<0A83D74A-42A1-4B4C-96C6-9C307872D822@kitware.com> Message-ID: Hi Dave, On Thu, Dec 4, 2014 at 9:07 PM, David Thompson wrote: > Hi Yumin, > > > I forgot to mention that the display controls in the context menu is > based on which model entity you right-clicked on in the view, if you don't > click on any entity (geometry), the context menu will only contains "Show > All Models". > > This looks great! And the "universal operators" branch I've merged into > SMTK includes a model operator ("set property") that can be used to change > the color and other modeling-entity properties, even across remote bridges. > So it should be possible to keep the Qt UI and ParaView UI in sync, > although that will also require redraw events to be emitted when the > operator is run. > > That makes sense. Also, do you think a "group" operator should be the "universal operators" ? Basically, this will be the operator to allow user to group entities based on some constraints or no constraints, such as face-group or edge-group in discrete bridge. I would have changed pqModelBuilderViewContextMenuBehavior::setBlockColor > (and the other methods that change the visibility and opacity) so that they > invoke the operator, but I don't see how to obtain the SMTK UUID associated > the block in question. Can you give me a call tomorrow so we can discuss > how to make that work? > > Sure, I will call you tomorrow morning. BTW, I am very close to get some UI working for ModelEntityItem, hopefully you could give me some feedbacks on that. Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Dec 4 21:58:19 2014 From: david.thompson at kitware.com (David Thompson) Date: Thu, 4 Dec 2014 21:58:19 -0500 Subject: [Smtk-developers] cmb_v4 update In-Reply-To: References:

<0A83D74A-42A1-4B4C-96C6-9C307872D822@kitware.com> Message-ID: > ... do you think a "group" operator should be the "universal operators" ? Basically, this will be the operator to allow user to group entities based on some constraints or no constraints, such as face-group or edge-group in discrete bridge. We could go either way but there is a caveat. If we make creating groups a "universal" operation, they would exist in the SMTK model Manager instance but not in the modeling kernel. So if we save entities back to a CAD file, the groups will not be preserved. On the other hand, I can see that it would allow grouping even when a bridge didn't support creating groups. I haven't tested it, but it's possible we could create a universal "create group" operator and then override it on bridges that support the creation of groups. The thing that worries me about this is what we would do when someone asked for the modeling-kernel handle for the SMTK-only group... >> I would have changed pqModelBuilderViewContextMenuBehavior::setBlockColor (and the other methods that change the visibility and opacity) so that they invoke the operator, but I don't see how to obtain the SMTK UUID associated the block in question. Can you give me a call tomorrow so we can discuss how to make that work? > > Sure, I will call you tomorrow morning. BTW, I am very close to get some UI working for ModelEntityItem, hopefully you could give me some feedbacks on that. Cool. See you then, David From david.thompson at kitware.com Fri Dec 5 20:10:32 2014 From: david.thompson at kitware.com (David Thompson) Date: Fri, 5 Dec 2014 20:10:32 -0500 Subject: [Smtk-developers] Q: default for vector value possible? In-Reply-To: <2F65F363-5864-4494-841F-6FDFC18C8D70@kitware.com> References: <2F65F363-5864-4494-841F-6FDFC18C8D70@kitware.com> Message-ID: <96FB8E99-7CC1-44A2-925A-92676039909E@kitware.com> Hi all, > No - it would be relatively simple to put this in but care needs to be taken to keep things consistent when the item definition is modified: > > ? The item must be non-extensible > ? When the Number of min required values is modified, the default array would also need to be updated > ? In the case of an extensible I'm guessing that the default array must be of size 1 and represents the value of newly added values. > > Does this make sense? Yup, it is now implemented and merged into SMTK/master. The "create brick" operator in SMTK now provides vector defaults for the brick axes. David From david.thompson at kitware.com Tue Dec 9 10:40:20 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 9 Dec 2014 10:40:20 -0500 Subject: [Smtk-developers] Instantiators? Message-ID: <1E9B4B6B-0917-4BDD-87D9-63DF0DB54D7E@kitware.com> Hi all (but especially Yumin), I've tried building SMTK against ParaView master recently and run into issues because VTK instantiators are broken (and deprecated) but smtk/extensions and smtk/bridge/discrete both force VTK_MAKE_INSTANTIATORS to ON. Is there any reason to force this? If not, I will remove this so things build properly. Thanks, David From yumin.yuan at kitware.com Tue Dec 9 11:00:39 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Tue, 9 Dec 2014 11:00:39 -0500 Subject: [Smtk-developers] Instantiators? In-Reply-To: <1E9B4B6B-0917-4BDD-87D9-63DF0DB54D7E@kitware.com> References: <1E9B4B6B-0917-4BDD-87D9-63DF0DB54D7E@kitware.com> Message-ID: Hi Dave, That is inherited from the old cmb code, and I don't remember why it was forced ON. Things (Paraview/VTK CMake stuff) have changed so much since then, and even IF it was really required before, it must be obsolete now, so I will say go ahead and remove it. Yumin On Tue, Dec 9, 2014 at 10:40 AM, David Thompson wrote: > Hi all (but especially Yumin), > > I've tried building SMTK against ParaView master recently and run into > issues because VTK instantiators are broken (and deprecated) but > smtk/extensions and smtk/bridge/discrete both force VTK_MAKE_INSTANTIATORS > to ON. Is there any reason to force this? If not, I will remove this so > things build properly. > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Dec 9 14:30:11 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 9 Dec 2014 14:30:11 -0500 Subject: [Smtk-developers] Tests on endor passing Message-ID: Hi all, It looks like the X server on endor is dead ("browseModel: cannot connect to X server :0"). Can someone with access verify, or should I just reboot it remotely? Also, I've pushed a fix for setting environment variables so the Python tests run properly on endor (and elsewhere). Please let me know if it breaks anything for you. Thanks, David From david.thompson at kitware.com Tue Dec 16 19:43:36 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 16 Dec 2014 19:43:36 -0500 Subject: [Smtk-developers] Repository now on github Message-ID: Hi all, The official SMTK repository is now on github at: https://github.com/Kitware/SMTK The original repository URL is now a clone of the github repo, synchronized every 10 minutes by a robot. Push access by humans to the old repo is now disabled. All future changes should be pull requests submitted to github as pull requests. David From robert.maynard at kitware.com Wed Dec 17 08:38:49 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 17 Dec 2014 08:38:49 -0500 Subject: [Smtk-developers] Repository now on github In-Reply-To: References: Message-ID: Awesome! The readme looks great but can we remove the suggestion to manually edit the CMakeCache file to find boost please. On Tue, Dec 16, 2014 at 7:43 PM, David Thompson wrote: > Hi all, > > The official SMTK repository is now on github at: > > https://github.com/Kitware/SMTK > > The original repository URL is now a clone of the github repo, synchronized every 10 minutes by a robot. Push access by humans to the old repo is now disabled. > > All future changes should be pull requests submitted to github as pull requests. > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From david.thompson at kitware.com Wed Dec 17 14:59:50 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 17 Dec 2014 14:59:50 -0500 Subject: [Smtk-developers] Operators and changes to Logger Message-ID: Hi all, Last night I pushed changes to master that add some methods to smtk::io::Logger for easier debugging as well as inter-process communication of operator results: + void setFlushToStream( std::ostream* output, bool ownFile, bool includePast); + bool setFlushToFile( std::string filename, bool includePast); + void setFlushToStdout(bool includePast); + void setFlushToStderr(bool includePast); Each Logger now stores an ostream* (which it may own and delete when modified). If non-NULL, then each time a record is added or another Logger is appended, the new records are printed to the stream and the stream flushed. Thus a logger created at startup and set to flush to a temporary file can be used for debugging. The changes also modify the model manager so that it owns a logger. Model operators now record results of modeling operations to their manager's log and these are automatically appended to the OperatorResult attribute's "log" item (a StringItem). Finally, the smtk::io::{Import,Export}JSON classes can serialize/deserialize log records to/from JSON. Applications wishing to present informational or error messages from Operators can: OperatorPtr op; // = model->op("set property"), for instance. OperatorResult res = op->operate(); StringItemPtr opmsg = res->findString("log"); if (opmsg->numberOfValues() > 0) { Logger oplog; ImportJSON::ofLogger(cJSON_Parse(opmsg->value()), oplog); // Now display oplog entries in the GUI } David From david.thompson at kitware.com Wed Dec 17 15:15:08 2014 From: david.thompson at kitware.com (David Thompson) Date: Wed, 17 Dec 2014 15:15:08 -0500 Subject: [Smtk-developers] Omitting properties from the Qt tree view Message-ID: Hi Yumin, We had talked about omitting the "visibility" property from the Qt tree view... please edit smtk::model::SimpleModelSubphrases::shouldOmitProperty() to return true for the "visibility" property, as is already done for the "color" and "name" properties. David From yumin.yuan at kitware.com Mon Dec 22 09:59:41 2014 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Mon, 22 Dec 2014 09:59:41 -0500 Subject: [Smtk-developers] smtk and cmb_v4 update Message-ID: Just relay some info from another email thread. Now there is a wiki page (internal to Kitware currently) for building cmb_v4 https://www.kitware.com/ERDC_Hydro/index.php/Build_CMB_v4#Using_SuperBuild Marcus pushed his cmb_v4 updates for paraview master, and I fixed a small build issue on Mac, so cmb_v4 should be happy now with paraview master. I also added some logic in smtk and cmb_v4, so now the annoying behavior (the whole tree redrew itself when changing color or visibility from the tree view) is gone. You need to update smtk and cmb_v4. Marcus is also working on updating cmb_v4 cmake scripts for OpenGL2 since now it compiles against paraview master. This is very exciting! Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Mon Dec 22 17:06:24 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 22 Dec 2014 17:06:24 -0500 Subject: [Smtk-developers] Added Solid Test Models Message-ID: <0306545D-BBB5-4322-839A-69DD8DEABD83@kitware.com> Hi All, I?ve added some test models including the disk brake and the a320 airbus (each take awhile to load). to the SMTK Test Data Repo. 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: From bob.obara at kitware.com Mon Dec 22 17:51:49 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 22 Dec 2014 17:51:49 -0500 Subject: [Smtk-developers] CGM Tessellation Message-ID: Where in the code is the face geometry tessellated? 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: From david.thompson at kitware.com Mon Dec 22 17:54:23 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 22 Dec 2014 17:54:23 -0500 Subject: [Smtk-developers] CGM Tessellation In-Reply-To: References: Message-ID: Hi Bob, > Where in the code is the face geometry tessellated? The CGM version is in smtk::bridge::cgm::Bridge::addTessellation (which calls some templated methods and eventually get_graphics() on a CGM entity). David From david.thompson at kitware.com Mon Dec 22 18:03:07 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 22 Dec 2014 18:03:07 -0500 Subject: [Smtk-developers] Loading in STP Models In-Reply-To: References: Message-ID: <2718D568-D5DC-4B98-8ECA-4E39B82E05EC@kitware.com> Hi Bob, > I?ve got another model that so far has been loading for 40 min - maybe we could have it output 10% status updates so I know its doing something and not lost? The problem is that the the model is being traversed by depth-first search (bodies, volumes, faces, edges, vertices) so it is unclear how much work remains at any given point. The tessellation information is added as each entity is encountered without a clear idea of how many entities remain. I think it would be easier to profile and improve tessellation than generate progress (and the progress signals might slow things down even more). For CGM, it appears possible to call GeometryQueryTool::get_graphics with a CGM Body* and get back primitives for all of the body's faces and edges at once (with offsets into the primitives for each)... but the method is not documented and not suited to the way the SMTK bridge is set up to do on-demand transcription of entities so I did not investigate it initially. However, I suspect it will be much faster than the current technique. David From bob.obara at kitware.com Mon Dec 22 20:33:11 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 22 Dec 2014 20:33:11 -0500 Subject: [Smtk-developers] Loading in STP Models In-Reply-To: <2718D568-D5DC-4B98-8ECA-4E39B82E05EC@kitware.com> References: <2718D568-D5DC-4B98-8ECA-4E39B82E05EC@kitware.com> Message-ID: <30A81637-F0D1-4782-A0A9-6AC6DBA11322@kitware.com> Hi David, I?m assuming that we are only tessellating the faces, edges, and vertices correct? Not the bodies themselves since that could cause things to get tessellated twice - Can we get the total number of entities in the file? If we could then the status could be number of ents processed / total ents. 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 Dec 22, 2014, at 6:03 PM, David Thompson wrote: > > Hi Bob, > >> I?ve got another model that so far has been loading for 40 min - maybe we could have it output 10% status updates so I know its doing something and not lost? > > The problem is that the the model is being traversed by depth-first search (bodies, volumes, faces, edges, vertices) so it is unclear how much work remains at any given point. The tessellation information is added as each entity is encountered without a clear idea of how many entities remain. > > I think it would be easier to profile and improve tessellation than generate progress (and the progress signals might slow things down even more). > > For CGM, it appears possible to call GeometryQueryTool::get_graphics with a CGM Body* and get back primitives for all of the body's faces and edges at once (with offsets into the primitives for each)... but the method is not documented and not suited to the way the SMTK bridge is set up to do on-demand transcription of entities so I did not investigate it initially. However, I suspect it will be much faster than the current technique. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Dec 22 20:35:36 2014 From: david.thompson at kitware.com (David Thompson) Date: Mon, 22 Dec 2014 20:35:36 -0500 Subject: [Smtk-developers] Loading in STP Models In-Reply-To: <30A81637-F0D1-4782-A0A9-6AC6DBA11322@kitware.com> References: <2718D568-D5DC-4B98-8ECA-4E39B82E05EC@kitware.com> <30A81637-F0D1-4782-A0A9-6AC6DBA11322@kitware.com> Message-ID: <9F2A204E-0F9D-4E10-8EE7-7E29F6317C95@kitware.com> Hi Bob, > I?m assuming that we are only tessellating the faces, edges, and vertices correct? Correct. > Not the bodies themselves since that could cause things to get tessellated twice Right, but CGM provides a method to obtain a tessellation of a body at once. It may be faster. > - Can we get the total number of entities in the file? Not without iterating over the topology twice (once to count, once to transcribe/tessellate). David From bob.obara at kitware.com Mon Dec 22 21:08:33 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Mon, 22 Dec 2014 21:08:33 -0500 Subject: [Smtk-developers] Loading in STP Models In-Reply-To: <9F2A204E-0F9D-4E10-8EE7-7E29F6317C95@kitware.com> References: <2718D568-D5DC-4B98-8ECA-4E39B82E05EC@kitware.com> <30A81637-F0D1-4782-A0A9-6AC6DBA11322@kitware.com> <9F2A204E-0F9D-4E10-8EE7-7E29F6317C95@kitware.com> Message-ID: <0F3985B3-CCE0-4D81-901E-53126FCB4CE5@kitware.com> Hi All, I think I can show we are no getting the correct topology - Load in Engine-block.igs and you can see we are getting a lot of volumetric bodies which are not volumes (they could be sheet bodies but they definitely not volumetric - this is one of the ?volumes?. 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 Dec 22, 2014, at 8:35 PM, David Thompson wrote: > > Hi Bob, > >> I?m assuming that we are only tessellating the faces, edges, and vertices correct? > > Correct. > >> Not the bodies themselves since that could cause things to get tessellated twice > > Right, but CGM provides a method to obtain a tessellation of a body at once. It may be faster. > >> - Can we get the total number of entities in the file? > > Not without iterating over the topology twice (once to count, once to transcribe/tessellate). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Voila_Capture 2014-12-22_09-05-11_PM.png Type: image/png Size: 93400 bytes Desc: not available URL: From david.thompson at kitware.com Tue Dec 23 15:28:02 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 23 Dec 2014 15:28:02 -0500 Subject: [Smtk-developers] Tessellation experiments Message-ID: Hi all, I've explored the option of asking for all the tessellation info in a single call instead of one call per edge and face... and discovered that CGM's OpenCascade engine does not implement the method. Furthermore, when loading the Audi_7.stp file with no tessellations computed, it takes 115 seconds on my machine (a debug build using a modified version of smtk/bridge/cgm/testing/python/cgmLoadFile.py). Of this, 93% of the time is spent inside 2 functions in OpenCascade's STEP importer. The remaining 7% is overhead added by CGM and SMTK. So even without tessellation, the bulk of the time importing STEP files appears to be in OpenCascade. I have not tried loading the Audi model with tessellation enabled (yet). The Audi has 2539 "volumes" (probably sheet bodies) according to some OCC log messages and SMTK reports 36138 entities total (includes verts, edges, faces, volumes, and models). I can import the Audi model into Cubit 14.1 in roughly 2 minutes, of which I *suspect* ACIS spends about 1 minute tessellating faces and edges (based on the fact that the progress bar suddenly starts moving about 1 minute into the load). It appears that the OCC STEP translator is about half the speed of the Cubit one (although my OCC build is in debug mode) but that tessellation is really slow since it took Bob 40 minutes to get the model displayed in ModelBuilder. I suspect a good bit of that is OCC but some of it is certainly SMTK since it copies the triangulations into its own format and then again into a VTK dataset. David From david.thompson at kitware.com Tue Dec 23 17:53:54 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 23 Dec 2014 17:53:54 -0500 Subject: [Smtk-developers] Build failures Message-ID: Hi all, Now that the discrete bridge is built on endor, it looks like there are some issues. Can someone take a look at: https://www.kitware.com/CDash/viewBuildError.php?buildid=532496 as it looks like a real error to me, not a fussy compiler. Thanks, David From david.thompson at kitware.com Tue Dec 23 19:08:53 2014 From: david.thompson at kitware.com (David Thompson) Date: Tue, 23 Dec 2014 19:08:53 -0500 Subject: [Smtk-developers] More performance info Message-ID: Hi Bob (et al.), The vast majority of the time spent after the STEP import (i.e, obtaining the tessellation) is in OpenCascade (75-85%). CGM and SMTK spend the remainder translating the topology and evaluating "measure()" on each CGM face in order to determine a per-face chord error limit. The "measure()" call accounts for 10% of the post-import time. So if we can get by without calling it, it would be nice. However, in terms of real speedups, it does not look like much is available outside of improvements to OpenCascade. David From bob.obara at kitware.com Wed Dec 24 07:34:50 2014 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Wed, 24 Dec 2014 07:34:50 -0500 Subject: [Smtk-developers] More performance info In-Reply-To: References: Message-ID: <1322CE5A-4118-4934-B2E8-261BC9288C2D@kitware.com> Hey Dave, Sounds like the only way to improve the speed is to reduce the number of tessellants being produce (especially since it looks like we are over tessellating in some parts. Bob Sent from my iPad > On Dec 23, 2014, at 7:08 PM, David Thompson wrote: > > Hi Bob (et al.), > > The vast majority of the time spent after the STEP import (i.e, obtaining the tessellation) is in OpenCascade (75-85%). CGM and SMTK spend the remainder translating the topology and evaluating "measure()" on each CGM face in order to determine a per-face chord error limit. The "measure()" call accounts for 10% of the post-import time. So if we can get by without calling it, it would be nice. However, in terms of real speedups, it does not look like much is available outside of improvements to OpenCascade. > > David