From robert.maynard at kitware.com Fri Apr 10 14:10:13 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Apr 2015 14:10:13 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. Message-ID: As we know currently the smtk discrete bridge and and cmb have duplicate code to allow smtk to load old cmb files. Part of the duplicated code are the vtkCMBMeshServerLauncher and vtkCMBTriangleMesher classes and the supported infrastructure. What I would like to do is to remove this code duplication by requiring the VTKExtensions/Meshing requires the libvtkSMTKDiscreteExt. Does anybody have any objections to this? It would require that smtk to install all headers under bridge/discrete/extension/ From yumin.yuan at kitware.com Fri Apr 10 14:19:48 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 10 Apr 2015 14:19:48 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. In-Reply-To: References: Message-ID: Hi Rob, As long as the CMB_Plugin(VTKExtension + some client code) does not have a hard-link to smtk, I am all for it. Sometimes, we/users just want to load a reader/writer inside cmbVTKExtension to paraview, which should not require smtk. Also, the cmbsuperbuild then needs to tell smtk to build discrete session by default, which is probably already the case. Yumin On Fri, Apr 10, 2015 at 2:10 PM, Robert Maynard wrote: > As we know currently the smtk discrete bridge and and cmb have > duplicate code to allow smtk to load old cmb files. Part of the > duplicated code are the vtkCMBMeshServerLauncher and > vtkCMBTriangleMesher classes and the supported infrastructure. > > What I would like to do is to remove this code duplication by > requiring the VTKExtensions/Meshing requires the > libvtkSMTKDiscreteExt. Does anybody have any objections to this? It > would require that smtk to install all headers under > bridge/discrete/extension/ > _______________________________________________ > 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: From robert.maynard at kitware.com Fri Apr 10 14:29:04 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 10 Apr 2015 14:29:04 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. In-Reply-To: References: Message-ID: On Fri, Apr 10, 2015 at 2:19 PM, Yumin Yuan wrote: > Hi Rob, > > As long as the CMB_Plugin(VTKExtension + some client code) does not have a > hard-link to smtk, I am all for it. Sometimes, we/users just want to load a > reader/writer inside cmbVTKExtension to paraview, which should not require > smtk. > This would cause a hardlink between VTKExtension and vtkSMTKDiscreteExt, but vtkSMTKDiscreteExt doesn't require or link to any part of SMTK. > Also, the cmbsuperbuild then needs to tell smtk to build discrete session by > default, which is probably already the case. Yeap the supberbuild is currently set up to make the discrete session. > > Yumin > > On Fri, Apr 10, 2015 at 2:10 PM, Robert Maynard > wrote: >> >> As we know currently the smtk discrete bridge and and cmb have >> duplicate code to allow smtk to load old cmb files. Part of the >> duplicated code are the vtkCMBMeshServerLauncher and >> vtkCMBTriangleMesher classes and the supported infrastructure. >> >> What I would like to do is to remove this code duplication by >> requiring the VTKExtensions/Meshing requires the >> libvtkSMTKDiscreteExt. Does anybody have any objections to this? It >> would require that smtk to install all headers under >> bridge/discrete/extension/ >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers > > From david.thompson at kitware.com Fri Apr 10 14:48:56 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 10 Apr 2015 14:48:56 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. In-Reply-To: References: Message-ID: <4F137EA8-33EB-444E-8A3F-EC487917DE65@kitware.com> Hi all, I am for eliminating the code duplication. Is the desire really to not require SMTK or to not require people to use ModelBuilder to load a CMB file? David > As long as the CMB_Plugin(VTKExtension + some client code) does not have a hard-link to smtk, I am all for it. Sometimes, we/users just want to load a reader/writer inside cmbVTKExtension to paraview, which should not require smtk. > > Also, the cmbsuperbuild then needs to tell smtk to build discrete session by default, which is probably already the case. > > Yumin > > On Fri, Apr 10, 2015 at 2:10 PM, Robert Maynard wrote: > As we know currently the smtk discrete bridge and and cmb have > duplicate code to allow smtk to load old cmb files. Part of the > duplicated code are the vtkCMBMeshServerLauncher and > vtkCMBTriangleMesher classes and the supported infrastructure. > > What I would like to do is to remove this code duplication by > requiring the VTKExtensions/Meshing requires the > libvtkSMTKDiscreteExt. Does anybody have any objections to this? It > would require that smtk to install all headers under > bridge/discrete/extension/ > _______________________________________________ > 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 yumin.yuan at kitware.com Fri Apr 10 15:02:40 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 10 Apr 2015 15:02:40 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. In-Reply-To: <4F137EA8-33EB-444E-8A3F-EC487917DE65@kitware.com> References: <4F137EA8-33EB-444E-8A3F-EC487917DE65@kitware.com> Message-ID: On Fri, Apr 10, 2015 at 2:48 PM, David Thompson wrote: > Hi all, > > I am for eliminating the code duplication. Is the desire really to not > require SMTK or to not require people to use ModelBuilder to load a CMB > file? > > This is really not related to ModelBuilder. I was talking about loading a mesh (.3dm) or points (.pts) file directly into paraview, which is a common usecase for some users. This usecase really just needs cmbVTKExtension, not smtk or smtkVTKExt. Ideally, we could have a package of paraview with just cmbVTKExtension as a plugin. Yumin > David > > > As long as the CMB_Plugin(VTKExtension + some client code) does not have > a hard-link to smtk, I am all for it. Sometimes, we/users just want to load > a reader/writer inside cmbVTKExtension to paraview, which should not > require smtk. > > > > Also, the cmbsuperbuild then needs to tell smtk to build discrete > session by default, which is probably already the case. > > > > Yumin > > > > On Fri, Apr 10, 2015 at 2:10 PM, Robert Maynard < > robert.maynard at kitware.com> wrote: > > As we know currently the smtk discrete bridge and and cmb have > > duplicate code to allow smtk to load old cmb files. Part of the > > duplicated code are the vtkCMBMeshServerLauncher and > > vtkCMBTriangleMesher classes and the supported infrastructure. > > > > What I would like to do is to remove this code duplication by > > requiring the VTKExtensions/Meshing requires the > > libvtkSMTKDiscreteExt. Does anybody have any objections to this? It > > would require that smtk to install all headers under > > bridge/discrete/extension/ > > _______________________________________________ > > 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: From david.thompson at kitware.com Fri Apr 10 15:05:54 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 10 Apr 2015 15:05:54 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. In-Reply-To: References: <4F137EA8-33EB-444E-8A3F-EC487917DE65@kitware.com> Message-ID: Hi Yumin, >> I am for eliminating the code duplication. Is the desire really to not require SMTK or to not require people to use ModelBuilder to load a CMB file? > > This is really not related to ModelBuilder. I was talking about loading a mesh (.3dm) or points (.pts) file directly into paraview, which is a common usecase for some users. This usecase really just needs cmbVTKExtension, not smtk or smtkVTKExt. Ideally, we could have a package of paraview with just cmbVTKExtension as a plugin. Yes, but is there a reason the plugin should not be part of SMTK instead of part of CMB? David From yumin.yuan at kitware.com Fri Apr 10 15:33:10 2015 From: yumin.yuan at kitware.com (Yumin Yuan) Date: Fri, 10 Apr 2015 15:33:10 -0400 Subject: [Smtk-developers] Unifying Meshing helpers between smtk and cmb. In-Reply-To: References: <4F137EA8-33EB-444E-8A3F-EC487917DE65@kitware.com> Message-ID: Hi Dave, On Fri, Apr 10, 2015 at 3:05 PM, David Thompson wrote: > Hi Yumin, > > >> I am for eliminating the code duplication. Is the desire really to not > require SMTK or to not require people to use ModelBuilder to load a CMB > file? > > > > This is really not related to ModelBuilder. I was talking about loading > a mesh (.3dm) or points (.pts) file directly into paraview, which is a > common usecase for some users. This usecase really just needs > cmbVTKExtension, not smtk or smtkVTKExt. Ideally, we could have a package > of paraview with just cmbVTKExtension as a plugin. > > Yes, but is there a reason the plugin should not be part of SMTK instead > of part of CMB? > > Well, conceptually there are some classes in cmbVTKExt that are not related to simulation at all, so they do not fit inside smtk. However, we could separate those out, and only move those related to simulation over to smtk. I don't have objection to that. Frankly, I will love to see some classes in cmbVTKExt are built outside of cmb and smtk, so that they can be linked from cmb and smtk separately. For example, MeshViewer can just linked against this library without requiring smtk. Yumin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Sat Apr 18 16:59:22 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sat, 18 Apr 2015 16:59:22 -0400 Subject: [Smtk-developers] Building issue Message-ID: Hi Guys, I?m getting the following build error while trying build smtk: [ 14%] Generating Python bindings for SMTKCore shiboken: Called with wrong arguments. Note: use --help option for more information. make[2]: *** [smtk/SMTKCorePython/smtkcorepython_module_wrapper.cpp] Error 1 make[1]: *** [smtk/CMakeFiles/SMTKCorePython.dir/all] Error 2 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 yumin.yuan at kitware.com Sat Apr 18 17:38:25 2015 From: yumin.yuan at kitware.com (yumin.yuan at kitware.com) Date: Sat, 18 Apr 2015 17:38:25 -0400 Subject: [Smtk-developers] Building issue In-Reply-To: References: Message-ID: <183390CA-63D5-4646-AD82-C1578B59FC48@kitware.com> Shiboken needs to be updated. Ben has a patch for it?but I don't know that has been merged into shiboken. You can check shiboken repo. Yumin Sent from my iPhone > On Apr 18, 2015, at 4:59 PM, Robert Michael O'Bara wrote: > > Hi Guys, > > I?m getting the following build error while trying build smtk: > > [ 14%] Generating Python bindings for SMTKCore > shiboken: Called with wrong arguments. > Note: use --help option for more information. > make[2]: *** [smtk/SMTKCorePython/smtkcorepython_module_wrapper.cpp] Error 1 > make[1]: *** [smtk/CMakeFiles/SMTKCorePython.dir/all] Error 2 > > 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 > > > > > _______________________________________________ > 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: From david.thompson at kitware.com Sat Apr 18 17:41:27 2015 From: david.thompson at kitware.com (David Thompson) Date: Sat, 18 Apr 2015 17:41:27 -0400 Subject: [Smtk-developers] Building issue In-Reply-To: References: Message-ID: Hi Bob, There was a miscommunication and a pull request in shiboken (#6) was not merged before the matching PR for SMTK. The shiboken PR needs to be merged to smtk-head and then your superbuild of shiboken updated. David On Apr 18, 2015, at 16:59, Robert Michael O'Bara wrote: > Hi Guys, > > I?m getting the following build error while trying build smtk: > > [ 14%] Generating Python bindings for SMTKCore > shiboken: Called with wrong arguments. > Note: use --help option for more information. > make[2]: *** [smtk/SMTKCorePython/smtkcorepython_module_wrapper.cpp] Error 1 > make[1]: *** [smtk/CMakeFiles/SMTKCorePython.dir/all] Error 2 > > 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 > > > > > _______________________________________________ > 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: From david.thompson at kitware.com Sat Apr 18 20:52:45 2015 From: david.thompson at kitware.com (David Thompson) Date: Sat, 18 Apr 2015 20:52:45 -0400 Subject: [Smtk-developers] Building issue In-Reply-To: References: Message-ID: Hi Bob, > There was a miscommunication and a pull request in shiboken (#6) was not merged before the matching PR for SMTK. The shiboken PR needs to be merged to smtk-head and then your superbuild of shiboken updated. The shiboken PR has been merged. I reran the travis build for your PR (the Pugi XML bump) and everything was OK, so I merged it. David From bob.obara at kitware.com Sat Apr 18 22:51:36 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sat, 18 Apr 2015 22:51:36 -0400 Subject: [Smtk-developers] Views Message-ID: Hi All, As you know I?m changing how Views are specified - my original idea is to store the view information as a XML string that will then be decoded by the View Widget. Alternatively I could define the Views as a set of Attribute/Definitions/Instances and therefore the View Widgets would not need to do any XML parsing. The one drawback to this approach is that the View Attributes/Definitions would be mixed in with the analysis Attributes/Definitions. On the plus side all information (Views included) would be modeled as attributes. Any 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: From bob.obara at kitware.com Sun Apr 19 15:29:54 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Sun, 19 Apr 2015 15:29:54 -0400 Subject: [Smtk-developers] Building issue In-Reply-To: References: Message-ID: Thanks David! Bob Sent from my iPad > On Apr 18, 2015, at 8:52 PM, David Thompson wrote: > > Hi Bob, > >> There was a miscommunication and a pull request in shiboken (#6) was not merged before the matching PR for SMTK. The shiboken PR needs to be merged to smtk-head and then your superbuild of shiboken updated. > > The shiboken PR has been merged. I reran the travis build for your PR (the Pugi XML bump) and everything was OK, so I merged it. > > David From david.thompson at kitware.com Tue Apr 21 20:09:35 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 21 Apr 2015 20:09:35 -0400 Subject: [Smtk-developers] Large bump in the rug Message-ID: <16387D47-C065-4021-90DC-520F64D665B7@kitware.com> Hi all, I've just merged a change to SMTK that requires changes to CMB's superbuild and CMB. It renames many libraries and CMake options so that the names are consistent across SMTK. See https://github.com/Kitware/SMTK/issues/85 for all the name changes. The general principle is that all SMTK libraries start with "smtk" just like VTK libraries start with "vtk". All libraries implementing a session end with "Session". So, SMTKCore is now smtkCore. CMake options in SMTK now have names like: + SMTK_ENABLE_XXX_SUPPORT where XXX is an external dependency (e.g., Remus, VTK) + SMTK_ENABLE_XXX_SESSION where XXX is the name of a modeling kernel. I've put in merge requests for the CMB side of things: + https://gitlab.kitware.com/cmb/cmb-superbuild/merge_requests/24 + https://gitlab.kitware.com/cmb/cmb/merge_requests/21 David From david.thompson at kitware.com Tue Apr 21 21:56:55 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 21 Apr 2015 21:56:55 -0400 Subject: [Smtk-developers] Part-way to VTK Python wrapping Message-ID: <32DC6830-B546-4D43-BAC3-FEC782592B2F@kitware.com> Hi all, The most recent pull request also included a change that wraps SMTK's VTK classes using VTK's python wrapping. The only problem is that there is not a way to pass the shiboken-wrapped SMTK model manager shared-pointer to the VTK-wrapped vtkModelMultiBlockSource instance. Does anyone have thoughts on how to tie these 2 together? It would be really nice to write Python scripts that pop up VTK render windows populated with SMTK models because it would open the door to better image-baseline tests (and simple example/tutorial applications). Thanks, David From david.thompson at kitware.com Wed Apr 22 12:12:00 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 22 Apr 2015 12:12:00 -0400 Subject: [Smtk-developers] Rebased smtk_mesh Message-ID: <26C539DB-D93E-4DAF-8C12-2B62645E1305@kitware.com> Hi Rob, I've pushed a rebased-and-patched version of your smtk_mesh branch to https://github.com/vibraphone/SMTK/tree/smtk_mesh_rebased It builds against SMTK's master branch that has renamed libraries and options. However, it seems to make CGM tests die with segfaults (deep inside CGM/OpenCascade) so I have not merged it yet. Valgrind has not revealed anything useful (other than dereferencing NULL as the cause of the segfault). David From robert.maynard at kitware.com Wed Apr 22 13:07:39 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 22 Apr 2015 13:07:39 -0400 Subject: [Smtk-developers] Rebased smtk_mesh In-Reply-To: <26C539DB-D93E-4DAF-8C12-2B62645E1305@kitware.com> References: <26C539DB-D93E-4DAF-8C12-2B62645E1305@kitware.com> Message-ID: I don't know if I ever tested with the CGM session enabled. Does the non rebased branch work with CGM? I have a few updates to the smtk::mesh::Manager to make it aware of the model to mesh associations, once I am finished the work I will send you a PR. On Wed, Apr 22, 2015 at 12:12 PM, David Thompson wrote: > Hi Rob, > > I've pushed a rebased-and-patched version of your smtk_mesh branch to > > https://github.com/vibraphone/SMTK/tree/smtk_mesh_rebased > > It builds against SMTK's master branch that has renamed libraries and options. However, it seems to make CGM tests die with segfaults (deep inside CGM/OpenCascade) so I have not merged it yet. Valgrind has not revealed anything useful (other than dereferencing NULL as the cause of the segfault). > > David From david.thompson at kitware.com Wed Apr 22 13:31:22 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 22 Apr 2015 13:31:22 -0400 Subject: [Smtk-developers] Rebased smtk_mesh In-Reply-To: References: <26C539DB-D93E-4DAF-8C12-2B62645E1305@kitware.com> Message-ID: <756F5815-C3C5-4A51-9EA1-3721077D367B@kitware.com> > I don't know if I ever tested with the CGM session enabled. Does the > non rebased branch work with CGM? Yes. The following tests fail. They seem unrelated to the mesh subsystem but fail on the smtk_mesh branch but not master: test-operators (SEGFAULT) cgmSolidModelingPy (SEGFAULT) cgmTransformsPy (SEGFAULT) cgmReadFilePy (SEGFAULT) > I have a few updates to the smtk::mesh::Manager to make it aware of > the model to mesh associations, once I am finished the work I will > send you a PR. OK. David From bob.obara at kitware.com Thu Apr 23 11:17:49 2015 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Thu, 23 Apr 2015 11:17:49 -0400 Subject: [Smtk-developers] View (Continued) Message-ID: <43BD8C0E-6F82-4A74-B923-7854F6011A12@kitware.com> Hi All, In the new design for Views I had failed to take into consideration the fact that Views might be defined within a C++ piece of code and not just through XML. In order to avoid developers having to create XML document strings in their code to create a View I modified the proposed View class to no longer just contain a XML string. Instead it now looks like the following structure which can capture the information in the XML description without forcing XML to spread in the code base. I also included examples as to how Views could be constructed in C++. Let me know what you think. Bob #include #include #include class View { public: class Component { public: Component(const std::string &myName) : m_name(myName) {} ~Component() { for(std::size_t i = 0; i < this->m_children.size(); ++i) { delete this->m_children[i]; } } const std::string &name() const {return this->m_name;} const std::string &contents() const {return this->m_contents;} void setContents(const std::string &c) {this->m_contents = c;} void setAttribute(const std::string &name, const std::string &value) {this->m_attributes[name] = value;} const std::string &attribute(const std::string &name) {return this->m_attributes[name];} // YES I know we need to see if the name is there first Component *addChild(const std::string &childName) { Component *c = new Component(childName); this->m_children.push_back(c); return c; } std::size_t numberOfChildren() const { return this->m_children.size();} Component *child(std::size_t i) const {return this->m_children[i];} protected: std::string m_name; std::string m_contents; std::map m_attributes; std::vector m_children; }; View(const std::string &myType, const std::string &myTitle) : m_type(myType), m_title(myTitle) { this->m_details = new Component("Details");} ~View() {delete this->m_details;} const std::string &title() const {return this->m_title;} const std::string &type() const {return this->m_type;} Component *details() const {return this->m_details;} protected: std::string m_title; std::string m_type; Component *m_details; }; int main() { View::Component *c; View sview("SimpleExpression", "Functions"); sview.details()->setContents("PolyLinearFunction"); View aview("Attribute", "BoundaryConditions"); aview.details()->setAttribute("ModelEntityFilter", "f"); aview.details()->addChild("SpecifiedHead"); aview.details()->addChild("SpecifiedFlux"); aview.details()->addChild("FlowInjectionWell"); aview.details()->addChild("METData"); aview.details()->addChild("GroundSurfaceHeatFlux"); aview.details()->addChild("UseMETData"); aview.details()->addChild("RayCaster"); aview.details()->addChild("BottomBoundaryTemp"); View iview("Instanced", "Time"); c = iview.details()->addChild("Instance"); c->setAttribute("Type", "Time"); c->setContents("Time"); View rview("Root", "SimBuilder"); c = rview.details()->addChild("DefaultColor"); c->setContents("1., 1., 0.5, 1."); c = rview.details()->addChild("InvalidColor"); c->setContents("1., 0.5, 0.5, 1."); c = rview.details()->addChild("Views"); c->addChild("Functions"); c->addChild("BoundaryConditions"); c->addChild("Time"); } 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 robert.maynard at kitware.com Thu Apr 23 11:27:46 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 23 Apr 2015 11:27:46 -0400 Subject: [Smtk-developers] View (Continued) In-Reply-To: <43BD8C0E-6F82-4A74-B923-7854F6011A12@kitware.com> References: <43BD8C0E-6F82-4A74-B923-7854F6011A12@kitware.com> Message-ID: Side note: I don't see any reason why Components are Heap based. If they are stack based the classes simplify nicely: class Component { public: Component(const std::string &myName) : m_name(myName) {} const std::string &name() const {return this->m_name;} const std::string &contents() const {return this->m_contents;} void setContents(const std::string &c) {this->m_contents = c;} void setAttribute(const std::string &name, const std::string &value) {this->m_attributes[name] = value;} const std::string &attribute(const std::string &name) {return this->m_attributes[name];} // YES I know we need to see if the name is there first const Component& addChild(const std::string &childName) { this->m_children.push_back( Component(childName) ); return this->m_children.back(); } std::size_t numberOfChildren() const { return this->m_children.size();} const Component& child(std::size_t i) const {return this->m_children[i];} protected: std::string m_name; std::string m_contents; std::map m_attributes; std::vector m_children; }; View(const std::string &myType, const std::string &myTitle) : m_type(myType), m_title(myTitle), m_details("Details") { } const std::string &title() const {return this->m_title;} const std::string &type() const {return this->m_type;} const Component& details() const {return this->m_details;} protected: std::string m_title; std::string m_type; Component m_details; }; As far as actually using the new views, I would have to spend some time with john to look at how the old instanced viewer worked and if this can replace it. On Thu, Apr 23, 2015 at 11:17 AM, Robert Michael O'Bara wrote: > Hi All, > > In the new design for Views I had failed to take into consideration the fact > that Views might be defined within a C++ piece of code and not just through > XML. In order to avoid developers having to create XML document strings in > their code to create a View I modified the proposed View class to no longer > just contain a XML string. Instead it now looks like the following > structure which can capture the information in the XML description without > forcing XML to spread in the code base. I also included examples as to how > Views could be constructed in C++. > > Let me know what you think. > > Bob > > #include > #include > #include > > class View > { > public: > class Component > { > public: > Component(const std::string &myName) : m_name(myName) > {} > > ~Component() > { > for(std::size_t i = 0; i < this->m_children.size(); ++i) > { > delete this->m_children[i]; > } > } > > const std::string &name() const > {return this->m_name;} > > const std::string &contents() const > {return this->m_contents;} > void setContents(const std::string &c) > {this->m_contents = c;} > > void setAttribute(const std::string &name, const std::string &value) > {this->m_attributes[name] = value;} > > const std::string &attribute(const std::string &name) > {return this->m_attributes[name];} // YES I know we need to see if the > name is there first > > Component *addChild(const std::string &childName) > { > Component *c = new Component(childName); > this->m_children.push_back(c); > return c; > } > std::size_t numberOfChildren() const > { return this->m_children.size();} > Component *child(std::size_t i) const > {return this->m_children[i];} > > protected: > std::string m_name; > std::string m_contents; > std::map m_attributes; > std::vector m_children; > }; > > View(const std::string &myType, const std::string &myTitle) : > m_type(myType), m_title(myTitle) > { this->m_details = new Component("Details");} > > ~View() > {delete this->m_details;} > > const std::string &title() const > {return this->m_title;} > > const std::string &type() const > {return this->m_type;} > > Component *details() const > {return this->m_details;} > > protected: > std::string m_title; > std::string m_type; > Component *m_details; > }; > > int main() > { > View::Component *c; > View sview("SimpleExpression", "Functions"); > sview.details()->setContents("PolyLinearFunction"); > > View aview("Attribute", "BoundaryConditions"); > aview.details()->setAttribute("ModelEntityFilter", "f"); > aview.details()->addChild("SpecifiedHead"); > aview.details()->addChild("SpecifiedFlux"); > aview.details()->addChild("FlowInjectionWell"); > aview.details()->addChild("METData"); > aview.details()->addChild("GroundSurfaceHeatFlux"); > aview.details()->addChild("UseMETData"); > aview.details()->addChild("RayCaster"); > aview.details()->addChild("BottomBoundaryTemp"); > > View iview("Instanced", "Time"); > c = iview.details()->addChild("Instance"); > c->setAttribute("Type", "Time"); > c->setContents("Time"); > > View rview("Root", "SimBuilder"); > c = rview.details()->addChild("DefaultColor"); > c->setContents("1., 1., 0.5, 1."); > c = rview.details()->addChild("InvalidColor"); > c->setContents("1., 0.5, 0.5, 1."); > c = rview.details()->addChild("Views"); > c->addChild("Functions"); > c->addChild("BoundaryConditions"); > c->addChild("Time"); > } > > 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 > > > > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > From david.thompson at kitware.com Thu Apr 23 16:23:32 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 23 Apr 2015 16:23:32 -0400 Subject: [Smtk-developers] Rebased smtk_mesh In-Reply-To: <26C539DB-D93E-4DAF-8C12-2B62645E1305@kitware.com> References: <26C539DB-D93E-4DAF-8C12-2B62645E1305@kitware.com> Message-ID: Hi Rob, To follow up on the test issues: they appear unrelated to the smtk mesh branch. Instead, when I did a clean rebuild of the CMB superbuild (which includes the OCE and CGM builds SMTK links to), it overwrote my OCE 6.8.0 install with the superbuild version which is significantly older and has problems. So... I have no objection to merging in the rebased smtk mesh branch. David > I've pushed a rebased-and-patched version of your smtk_mesh branch to > > https://github.com/vibraphone/SMTK/tree/smtk_mesh_rebased > > It builds against SMTK's master branch that has renamed libraries and options. However, it seems to make CGM tests die with segfaults (deep inside CGM/OpenCascade) so I have not merged it yet. Valgrind has not revealed anything useful (other than dereferencing NULL as the cause of the segfault). From david.thompson at kitware.com Fri Apr 24 02:55:44 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 24 Apr 2015 02:55:44 -0400 Subject: [Smtk-developers] View (Continued) In-Reply-To: <43BD8C0E-6F82-4A74-B923-7854F6011A12@kitware.com> References: <43BD8C0E-6F82-4A74-B923-7854F6011A12@kitware.com> Message-ID: Hi Bob, I agree with Rob... if the Components are not ever going to be subclassed, they should be stored by value. Also, for your C++ construction example, I would consider changing the API a little to make it easier to construct views manually: int main() { View sview = View("SimpleExpression", "Functions") .setContents("PolyLinearFunction"); View aview = View("Attribute", "BoundaryConditions") .setAttribute("ModelEntityFilter", "f") .addChildren( "SpecifiedHead", "SpecifiedFlux", FlowInjectionWell", "METData", "GroundSurfaceHeatFlux", "UseMETData", "RayCaster", BottomBoundaryTemp"); View iview = View("Instanced", "Time") .setAttribute("Type", "Time") .setContents("Time") .addChild("Instance"); View rview = View("Root", "SimBuilder"); rview.addChild("DefaultColor").setContents("1., 1., 0.5, 1."); rview.addChild("InvalidColor").setContents("1., 0.5, 0.5, 1."); rview.addChildren("Views", "Functions", "BoundaryConditions", "Time"); } and programmatically int main() { View sview = // ... same as above ... std::vector childNames; View aview = View("Attribute", "BoundaryConditions") .setAttribute("ModelEntityFilter", "f") .addChildren(childNames); // ... View rview = View("Root", "SimBuilder"); rview.addChild("DefaultColor").append() << 1. << 1. << 0.5 << 1.; rview.addChild("InvalidColor").append() << 1. << 0.5 << 0.5 << 1.; rview.addChildren("Views", "Functions", "BoundaryConditions", "Time"); }