From david.thompson at kitware.com Mon May 1 11:59:44 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 May 2017 11:59:44 -0400 Subject: [Smtk-developers] CMB dashboard and SMTK Message-ID: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> Hi all, I committed some changes to SMTK that should fix the **CMB** failure on talosiv, but it's unclear to me how I should tell CMB to use the new SMTK... is it supposed to be magic? Can I provide hints? Thanks, David From haocheng.liu at kitware.com Mon May 1 12:08:08 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Mon, 1 May 2017 12:08:08 -0400 Subject: [Smtk-developers] [Cmb-users] CMB dashboard and SMTK In-Reply-To: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> References: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> Message-ID: If I remember it correctly, After SMTK master moves if within 45-minute interval SMTK master does not have new things merged in, then CMB would build against SMTK new master. If new things are merged in, then the timer would be reset. On Mon, May 1, 2017 at 11:59 AM, David Thompson wrote: > Hi all, > > I committed some changes to SMTK that should fix the **CMB** failure on > talosiv, but it's unclear to me how I should tell CMB to use the new > SMTK... is it supposed to be magic? Can I provide hints? > > Thanks, > David > _______________________________________________ > Cmb-users mailing list > Cmb-users at computationalmodelbuilder.org > http://public.kitware.com/mailman/listinfo/cmb-users > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 1 12:45:07 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 May 2017 12:45:07 -0400 Subject: [Smtk-developers] [Cmb-users] CMB dashboard and SMTK In-Reply-To: References: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> Message-ID: <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> >> I committed some changes to SMTK that should fix the **CMB** failure on talosiv, but it's unclear to me how I should tell CMB to use the new SMTK... is it supposed to be magic? Can I provide hints? >> > If I remember it correctly, After SMTK master moves if within 45-minute interval SMTK master does not have new things merged in, then CMB would build against SMTK new master. If new things are merged in, then the timer would be reset. Which type of build is started? One in buildbot-packages? master? latest-master? I'm still not clear on what all the CDash headings mean and don't see any documentation for them. Thanks, David From haocheng.liu at kitware.com Mon May 1 13:04:46 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Mon, 1 May 2017 13:04:46 -0400 Subject: [Smtk-developers] [Cmb-users] CMB dashboard and SMTK In-Reply-To: <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> References: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> Message-ID: On Mon, May 1, 2017 at 12:45 PM, David Thompson wrote: > >> I committed some changes to SMTK that should fix the **CMB** failure on > talosiv, but it's unclear to me how I should tell CMB to use the new > SMTK... is it supposed to be magic? Can I provide hints? > >> > > If I remember it correctly, After SMTK master moves if within 45-minute > interval SMTK master does not have new things merged in, then CMB would > build against SMTK new master. If new things are merged in, then the timer > would be reset. > > Which type of build is started? One in buildbot-packages? master? > latest-master? I'm still not clear on what all the CDash headings mean and > don't see any documentation for them. > > I think it's buildbot-packages. > Thanks, > David -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon May 1 13:08:53 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 1 May 2017 13:08:53 -0400 Subject: [Smtk-developers] [Cmb-users] CMB dashboard and SMTK In-Reply-To: <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> References: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> Message-ID: <20170501170853.GA14654@megas.kitware.com> On Mon, May 01, 2017 at 12:45:07 -0400, David Thompson wrote: > > If I remember it correctly, After SMTK master moves if within > > 45-minute interval SMTK master does not have new things merged in, > > then CMB would build against SMTK new master. If new things are > > merged in, then the timer would be reset. It's that if SMTK master hasn't changed in 45 minutes, a CMB Superbuild build is *queued*. It still can be deferred by other work the machines have pending. > Which type of build is started? One in buildbot-packages? master? > latest-master? I'm still not clear on what all the CDash headings mean > and don't see any documentation for them. It should be master-packages on CMB. The `latest` sections are just the most recent `master` or `package` builds (never a merge request build). --Ben From david.thompson at kitware.com Mon May 1 13:15:10 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 1 May 2017 13:15:10 -0400 Subject: [Smtk-developers] [Cmb-users] CMB dashboard and SMTK In-Reply-To: <20170501170853.GA14654@megas.kitware.com> References: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> <20170501170853.GA14654@megas.kitware.com> Message-ID: <1C1A09E8-A75E-4E80-8753-ACA26541DF23@kitware.com> Hi Ben, >>> If I remember it correctly, After SMTK master moves if within >>> 45-minute interval SMTK master does not have new things merged in, >>> then CMB would build against SMTK new master. If new things are >>> merged in, then the timer would be reset. > > It's that if SMTK master hasn't changed in 45 minutes, a CMB Superbuild > build is *queued*. It still can be deferred by other work the machines > have pending. Does the CMB superbuild include CMB? or queue a CMB build? Or do we need to twiddle something to get a CMB "master" to build after this? >> Which type of build is started? One in buildbot-packages? master? >> latest-master? I'm still not clear on what all the CDash headings mean >> and don't see any documentation for them. > > It should be master-packages on CMB. The `latest` sections are just the > most recent `master` or `package` builds (never a merge request build). Thanks! David From ben.boeckel at kitware.com Mon May 1 13:48:35 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 1 May 2017 13:48:35 -0400 Subject: [Smtk-developers] [Cmb-users] CMB dashboard and SMTK In-Reply-To: <1C1A09E8-A75E-4E80-8753-ACA26541DF23@kitware.com> References: <4A67013B-8FBE-47F8-A9C6-FDC92207159A@kitware.com> <1994A97E-E996-42C1-B257-D97D87EE1622@kitware.com> <20170501170853.GA14654@megas.kitware.com> <1C1A09E8-A75E-4E80-8753-ACA26541DF23@kitware.com> Message-ID: <20170501174835.GA16568@megas.kitware.com> On Mon, May 01, 2017 at 13:15:10 -0400, David Thompson wrote: > Does the CMB superbuild include CMB? or queue a CMB build? Or do we > need to twiddle something to get a CMB "master" to build after this? It does build CMB. If the build fails, the developer install is not (re)created though. --Ben From david.thompson at kitware.com Thu May 4 17:39:18 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 4 May 2017 17:39:18 -0400 Subject: [Smtk-developers] qtFileItem and/or FileItem Message-ID: <7F5FCF5B-5B22-4FB4-B042-AC9A9DE40B31@kitware.com> Hi all, I believe that some changes have recently been made to either qtFileItem or FileItem (or FileSystemItem?) that only accept files with a given suffix. That appears to have a small bug in qtFileItem's behavior: Upon typing an initial filename, the QLineEdit's background is colored red until the proper extension is added. However, changing the filename afterwards by removing the extension does not mark the background red until the filename is completely empty. This would not be so bad except that the underlying FileItem does not accept the edits, so users have no visual feedback that what they've entered is not reflected in the underlying attribute. Should I file an issue for this in the tracker? If so, who may I assign it to (besides myself :-)? Thanks, David From tj.corona at kitware.com Thu May 4 17:50:45 2017 From: tj.corona at kitware.com (T.J. Corona) Date: Thu, 4 May 2017 17:50:45 -0400 Subject: [Smtk-developers] qtFileItem and/or FileItem In-Reply-To: <7F5FCF5B-5B22-4FB4-B042-AC9A9DE40B31@kitware.com> References: <7F5FCF5B-5B22-4FB4-B042-AC9A9DE40B31@kitware.com> Message-ID: <02A0C793-4308-486A-911D-92C70430E76A@kitware.com> That was me. I can look into it. Sent from my iPhone > On May 4, 2017, at 5:39 PM, David Thompson wrote: > > Hi all, > > I believe that some changes have recently been made to either qtFileItem or FileItem (or FileSystemItem?) that only accept files with a given suffix. That appears to have a small bug in qtFileItem's behavior: > > Upon typing an initial filename, the QLineEdit's background is colored red until the proper extension is added. However, changing the filename afterwards by removing the extension does not mark the background red until the filename is completely empty. This would not be so bad except that the underlying FileItem does not accept the edits, so users have no visual feedback that what they've entered is not reflected in the underlying attribute. > > Should I file an issue for this in the tracker? If so, who may I assign it to (besides myself :-)? > > Thanks, > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers From tj.corona at kitware.com Fri May 5 10:05:29 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 5 May 2017 10:05:29 -0400 Subject: [Smtk-developers] qtFileItem and/or FileItem In-Reply-To: <02A0C793-4308-486A-911D-92C70430E76A@kitware.com> References: <7F5FCF5B-5B22-4FB4-B042-AC9A9DE40B31@kitware.com> <02A0C793-4308-486A-911D-92C70430E76A@kitware.com> Message-ID: <657FAE8E-9FBC-42EB-A311-A65B1AC71141@kitware.com> The fix for this issue can be found here: https://gitlab.kitware.com/cmb/smtk/merge_requests/593 Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 4, 2017, at 5:50 PM, T.J. Corona wrote: > > That was me. I can look into it. > > Sent from my iPhone > >> On May 4, 2017, at 5:39 PM, David Thompson wrote: >> >> Hi all, >> >> I believe that some changes have recently been made to either qtFileItem or FileItem (or FileSystemItem?) that only accept files with a given suffix. That appears to have a small bug in qtFileItem's behavior: >> >> Upon typing an initial filename, the QLineEdit's background is colored red until the proper extension is added. However, changing the filename afterwards by removing the extension does not mark the background red until the filename is completely empty. This would not be so bad except that the underlying FileItem does not accept the edits, so users have no visual feedback that what they've entered is not reflected in the underlying attribute. >> >> Should I file an issue for this in the tracker? If so, who may I assign it to (besides myself :-)? >> >> Thanks, >> David >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Tue May 9 17:27:20 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 9 May 2017 16:27:20 -0500 Subject: [Smtk-developers] Static build of smtk Message-ID: <1E2F4A1B-B8CA-4016-BCEA-FD03E9F05F6E@kitware.com> Hi all, Before I go down a rabbit hole, I just wanted to check with the list: can I build smtk with static linkage and with vtk + python bindings? Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue May 9 17:41:28 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 9 May 2017 17:41:28 -0400 Subject: [Smtk-developers] Static build of smtk In-Reply-To: <1E2F4A1B-B8CA-4016-BCEA-FD03E9F05F6E@kitware.com> References: <1E2F4A1B-B8CA-4016-BCEA-FD03E9F05F6E@kitware.com> Message-ID: Hi TJ, > Before I go down a rabbit hole, I just wanted to check with the list: can I build smtk with static linkage and with vtk + python bindings? While in theory this might be possible, I suspect the rabbit hole is deep enough to puncture the mantle. I doubt that SMTK is set up to build python modules dynamically when told to do a static build (in which case you would have to create a "frozen" python interpreter like PV does on some HPC systems). Even if SMTK created dynamic Python modules and static libraries, I think there would be other issues based on vague memories of some MR comments a while back (maybe some improper dependencies, maybe more). David From tj.corona at kitware.com Tue May 9 17:43:04 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 9 May 2017 16:43:04 -0500 Subject: [Smtk-developers] Static build of smtk In-Reply-To: References: <1E2F4A1B-B8CA-4016-BCEA-FD03E9F05F6E@kitware.com> Message-ID: <807188E7-EE8B-49B0-8691-29973CA0E6F3@kitware.com> Thanks for the quick reply! You saved me an evening of torment. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 9, 2017, at 4:41 PM, David Thompson wrote: > > Hi TJ, > >> Before I go down a rabbit hole, I just wanted to check with the list: can I build smtk with static linkage and with vtk + python bindings? > > While in theory this might be possible, I suspect the rabbit hole is deep enough to puncture the mantle. I doubt that SMTK is set up to build python modules dynamically when told to do a static build (in which case you would have to create a "frozen" python interpreter like PV does on some HPC systems). Even if SMTK created dynamic Python modules and static libraries, I think there would be other issues based on vague memories of some MR comments a while back (maybe some improper dependencies, maybe more). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue May 9 18:02:22 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 9 May 2017 18:02:22 -0400 Subject: [Smtk-developers] Static build of smtk In-Reply-To: References: <1E2F4A1B-B8CA-4016-BCEA-FD03E9F05F6E@kitware.com> Message-ID: <20170509220222.GA31426@megas.kitware.com> On Tue, May 09, 2017 at 17:41:28 -0400, David Thompson wrote: > While in theory this might be possible, I suspect the rabbit hole is > deep enough to puncture the mantle. I doubt that SMTK is set up to > build python modules dynamically when told to do a static build (in > which case you would have to create a "frozen" python interpreter like > PV does on some HPC systems). Even if SMTK created dynamic Python > modules and static libraries, I think there would be other issues > based on vague memories of some MR comments a while back (maybe some > improper dependencies, maybe more). "Frozen" python only embeds `.py` modules. Compiled modules are imported via the builtin table (and builtin modules which are under frozen modules or packages need a patch to the interpreter to not give up after not finding it in the frozen table). To support using a static SMTK from a shared build, either exactly one shared library can link SMTK or SMTK cannot have any global state (statics, etc.) otherwise each shared library which links to the static libraries gets their own copy of that static. --Ben From david.thompson at kitware.com Thu May 11 14:04:54 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 11 May 2017 14:04:54 -0400 Subject: [Smtk-developers] Operator results with mesh changes Message-ID: Hi TJ (et al.), As part of changing the "save smtk model" operator, mesh collections may be assigned a new URL on the server (e.g., a mesh is packaged with an SMTK file). Is there a way to store this information in the operator's result? If not, how would you go about it? I see smtk::attribute::MeshItem, but this is only for MeshSets, not MeshCollections. I could (hackishly) use smtk::attribute::StringItem and encode the collection's UUID and URL in separate values of the same item. Or, is there a better way? David From tj.corona at kitware.com Thu May 11 14:25:54 2017 From: tj.corona at kitware.com (TJ Corona) Date: Thu, 11 May 2017 13:25:54 -0500 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: References: Message-ID: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> Hi David, Just curious: why do you want to store the collection?s URL in the operator result? A collection holds its read and write locations, and you are free to change the collection?s write location (I think you automatically do so when you write a collection to disk). If you wish to flag that a collection?s write location has been changed, I?m not sure what component would need to decode this information. Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 11, 2017, at 1:04 PM, David Thompson wrote: > > Hi TJ (et al.), > > As part of changing the "save smtk model" operator, mesh collections may be assigned a new URL on the server (e.g., a mesh is packaged with an SMTK file). Is there a way to store this information in the operator's result? If not, how would you go about it? I see smtk::attribute::MeshItem, but this is only for MeshSets, not MeshCollections. I could (hackishly) use smtk::attribute::StringItem and encode the collection's UUID and URL in separate values of the same item. Or, is there a better way? > > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri May 12 14:19:09 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 12 May 2017 14:19:09 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> Message-ID: <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> Hi TJ, > Just curious: why do you want to store the collection?s URL in the operator result? A collection holds its read and write locations, and you are free to change the collection?s write location (I think you automatically do so when you write a collection to disk). Because I would like to be able to perform existence/location tests on the client for CMB v4. There is not a way for operator views to do a trial run of an operation on the server without triggering the result-handling stuff which prevents the "save smtk model" operator from running on the server. If the client and server have a different mesh manager, then the collections must have different FileLocation information. I was under the impression that the mesh manager tracked collections and meshsets on the client but did so without copying actual mesh data. Is that not so? Thanks, David From tj.corona at kitware.com Fri May 12 17:43:19 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 12 May 2017 16:43:19 -0500 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> Message-ID: <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> > Because I would like to be able to perform existence/location tests on the client for CMB v4. Ah, that?s a very good reason! I?ve cc?d Robert because he?s the guy to ask, but I can give you my version of an answer. smtk::mesh currently supports two ?interfaces?: Moab and Json. The Moab interface is the one that runs on the server, has the database, and does all of the actual work. The Json interface runs on the client, and it nulls out the database calls and only carries metainformation about mesh collections, mesh sets, etc. It looks as though these two are kept in sync somewhere in SaveJson, but the code is rather squirrely (maybe try SaveJSON::forManagerMeshes? The mesh info gets updated if JSON_MESHES is one of the flags passed to SaveJSON::forManager). Hope this helps! Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 12, 2017, at 1:19 PM, David Thompson wrote: > > Hi TJ, > >> Just curious: why do you want to store the collection?s URL in the operator result? A collection holds its read and write locations, and you are free to change the collection?s write location (I think you automatically do so when you write a collection to disk). > > Because I would like to be able to perform existence/location tests on the client for CMB v4. There is not a way for operator views to do a trial run of an operation on the server without triggering the result-handling stuff which prevents the "save smtk model" operator from running on the server. If the client and server have a different mesh manager, then the collections must have different FileLocation information. I was under the impression that the mesh manager tracked collections and meshsets on the client but did so without copying actual mesh data. Is that not so? > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 15 09:34:08 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 15 May 2017 09:34:08 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> Message-ID: <42EDA7D8-2426-4D67-84B5-12FF9C87EDC0@kitware.com> Hi TJ, >> Because I would like to be able to perform existence/location tests on the client for CMB v4. > > Ah, that?s a very good reason! I?ve cc?d Robert because he?s the guy to ask, but I can give you my version of an answer. > > smtk::mesh currently supports two ?interfaces?: Moab and Json. The Moab interface is the one that runs on the server, has the database, and does all of the actual work. The Json interface runs on the client, and it nulls out the database calls and only carries metainformation about mesh collections, mesh sets, etc. It looks as though these two are kept in sync somewhere in SaveJson, but the code is rather squirrely (maybe try SaveJSON::forManagerMeshes? The mesh info gets updated if JSON_MESHES is one of the flags passed to SaveJSON::forManager). Hope this helps! This helps, but it appears to have a missing piece or two. In particular, 1. The "mesh" operator itself always clears the read+write locations (so that, according to comments, it appears that the mesh has not been saved by the mesh worker but is instead an in-server-memory-only mesh), so the JSON mesh interface on the client initially has no location information. This is kinda clunky since the mesh must be rewritten, but OK. At least it appears that the result-attribute of this operation includes the "mesh_created" item so the client knows to ask for an update of the JSON interface. 2. The "write mesh" operator does not update the collection's writeLocation. This is an easy fix: --- a/smtk/io/WriteMesh.cxx +++ b/smtk/io/WriteMesh.cxx @@ -66,7 +66,12 @@ bool WriteMesh::operator()( format.Extensions.end()) { // write the collection - return writer->write(filePath, collection, subset); + bool didWrite = writer->write(filePath, collection, subset); + if (didWrite) + { + collection->writeLocation(filePath); + } + return didWrite; } } } 3. The "write mesh" operator does not contain any items in the result attribute indicating what collections were actually written to disk, so there is no way to know what meshes need to be written. While it looks like the "mesh_modified" item exists for this purpose (SaveJSON::forOperatorResult() adds the JSON metadata when it is present), the "mesh_modified" item is expected to be an instance of smtk::attribute::MeshItem, which holds MeshSets not Collections. Are we intended to use this by creating empty meshsets whose parent is the collection with the modified URL? David From robert.maynard at kitware.com Mon May 15 09:38:59 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 15 May 2017 09:38:59 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> Message-ID: > smtk::mesh currently supports two ?interfaces?: Moab and Json TJ is correct, smtk::mesh has two backends, with the JSON version being used as a proxy read only version on the client that only stores the meta information ( point ids and cell ids on a per mesh basis, material sets, etc ) but doesn't have any real coordinate or topology information. This allows it to do all the mesh query / subsetting ( including queries on if a meshset contains a certain type of cell ). > If the client and server have a different mesh manager, then the collections must have different FileLocation information. Yes this is correct, the client JSON file location will not be the same as the servers. I would need to re-verify the code but I expect that it has no file location at all, as it was generated "in memory". > There is not a way for operator views to do a trial run of an operation on the server without triggering the result-handling stuff which prevents the "save smtk model" operator from running on the server. I am not following this information. In effect what you want is some way to run an operator and cache the results? Is that correct? Do you want the mesh flushed to disk at all? I know that remus has logic to properly determine an unique file location in temporary memory ( this is how remus mesh operators send meshes ), maybe that could be leveraged. On Fri, May 12, 2017 at 5:43 PM, TJ Corona wrote: > Because I would like to be able to perform existence/location tests on the > client for CMB v4. > > > Ah, that?s a very good reason! I?ve cc?d Robert because he?s the guy to > ask, but I can give you my version of an answer. > > smtk::mesh currently supports two ?interfaces?: Moab and Json. The Moab > interface is the one that runs on the server, has the database, and does > all of the actual work. The Json interface runs on the client, and it nulls > out the database calls and only carries metainformation about mesh > collections, mesh sets, etc. It looks as though these two are kept in sync > somewhere in SaveJson, but the code is rather squirrely (maybe try > SaveJSON::forManagerMeshes? The mesh info gets updated if JSON_MESHES is > one of the flags passed to SaveJSON::forManager). Hope this helps! > > Sincerely, > T.J. > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 <(518)%20881-4443> > > On May 12, 2017, at 1:19 PM, David Thompson > wrote: > > Hi TJ, > > Just curious: why do you want to store the collection?s URL in the > operator result? A collection holds its read and write locations, and you > are free to change the collection?s write location (I think you > automatically do so when you write a collection to disk). > > > Because I would like to be able to perform existence/location tests on the > client for CMB v4. There is not a way for operator views to do a trial run > of an operation on the server without triggering the result-handling stuff > which prevents the "save smtk model" operator from running on the server. > If the client and server have a different mesh manager, then the > collections must have different FileLocation information. I was under the > impression that the mesh manager tracked collections and meshsets on the > client but did so without copying actual mesh data. Is that not so? > > Thanks, > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon May 15 09:47:03 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 15 May 2017 09:47:03 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <42EDA7D8-2426-4D67-84B5-12FF9C87EDC0@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> <42EDA7D8-2426-4D67-84B5-12FF9C87EDC0@kitware.com> Message-ID: Looks like you posted while I was writing my post. 1. Yes this is desired as the results of a mesh operation are really temporary, and currently use a temporary file since Remus has been updated to do automatic file transportation. With the locations currently being inside a system temporary directory, they should never be considered to be valid files for long term purposes. If we ever cycle back to remote mesh operators, this system will have to overhauled, and very possibly the results of the mesh operator will never have a file backing. 2. I haven't did a deep look into WriteMesh, but we need to confirm that we have a clear understanding of Export, Write, and WriteAs handled properly. I am concerned that saving the location to writeLocation could change a subsequent model write in the future by mistake. Now if these changes are correct, you should specify the writeLocation before calling write, as that will allow you to us the unspecified writer->write api IIRC. On Mon, May 15, 2017 at 9:34 AM, David Thompson wrote: > Hi TJ, > > >> Because I would like to be able to perform existence/location tests on > the client for CMB v4. > > > > Ah, that?s a very good reason! I?ve cc?d Robert because he?s the guy to > ask, but I can give you my version of an answer. > > > > smtk::mesh currently supports two ?interfaces?: Moab and Json. The Moab > interface is the one that runs on the server, has the database, and does > all of the actual work. The Json interface runs on the client, and it nulls > out the database calls and only carries metainformation about mesh > collections, mesh sets, etc. It looks as though these two are kept in sync > somewhere in SaveJson, but the code is rather squirrely (maybe try > SaveJSON::forManagerMeshes? The mesh info gets updated if JSON_MESHES is > one of the flags passed to SaveJSON::forManager). Hope this helps! > > This helps, but it appears to have a missing piece or two. In particular, > > 1. The "mesh" operator itself always clears the read+write locations (so > that, according to comments, it appears that the mesh has not been saved by > the mesh worker but is instead an in-server-memory-only mesh), so the JSON > mesh interface on the client initially has no location information. This is > kinda clunky since the mesh must be rewritten, but OK. At least it appears > that the result-attribute of this operation includes the "mesh_created" > item so the client knows to ask for an update of the JSON interface. > > 2. The "write mesh" operator does not update the collection's > writeLocation. This is an easy fix: > --- a/smtk/io/WriteMesh.cxx > +++ b/smtk/io/WriteMesh.cxx > @@ -66,7 +66,12 @@ bool WriteMesh::operator()( > format.Extensions.end()) > { > // write the collection > - return writer->write(filePath, collection, subset); > + bool didWrite = writer->write(filePath, collection, subset); > + if (didWrite) > + { > + collection->writeLocation(filePath); > + } > + return didWrite; > } > } > } > > 3. The "write mesh" operator does not contain any items in the result > attribute indicating what collections were actually written to disk, so > there is no way to know what meshes need to be written. While it looks like > the "mesh_modified" item exists for this purpose > (SaveJSON::forOperatorResult() adds the JSON metadata when it is present), > the "mesh_modified" item is expected to be an instance of > smtk::attribute::MeshItem, which holds MeshSets not Collections. Are we > intended to use this by creating empty meshsets whose parent is the > collection with the modified URL? > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 15 09:56:46 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 15 May 2017 09:56:46 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> <42EDA7D8-2426-4D67-84B5-12FF9C87EDC0@kitware.com> Message-ID: <9F058BB2-BD97-42C3-9C13-D078EF960E72@kitware.com> Hi Rob, > Looks like you posted while I was writing my post. Yup. :-) > 1. Yes this is desired ... I am fine with it for now (although I guess it will change when someone starts creating really large meshes) but wanted to make sure I understood the assumptions being made. > 2. I haven't did a deep look into WriteMesh, but we need to confirm that we have a clear understanding of Export, Write, and WriteAs handled properly. I am concerned that saving the location to writeLocation could change a subsequent model write in the future by mistake. You're saying that we should instead do: collection->writeLocation(filePath); return writer->write(collection, subset); > Now if these changes are correct, you should specify the writeLocation before calling write, as that will allow you to us the unspecified writer->write api IIRC. I am fine with changing the order inside the operator as above, but want to be sure the filename is preserved in the collection so that saving the SMTK model will result in updates to the mesh (such as changes in the classification) get preserved. David From robert.maynard at kitware.com Mon May 15 10:20:35 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 15 May 2017 10:20:35 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <9F058BB2-BD97-42C3-9C13-D078EF960E72@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> <42EDA7D8-2426-4D67-84B5-12FF9C87EDC0@kitware.com> <9F058BB2-BD97-42C3-9C13-D078EF960E72@kitware.com> Message-ID: Yes once you specify a writeLocation that location is preserved in the collection, and will be used for all future writes ( till it is cleared ). On Mon, May 15, 2017 at 9:56 AM, David Thompson wrote: > Hi Rob, > > > Looks like you posted while I was writing my post. > > Yup. :-) > > > 1. Yes this is desired ... > > I am fine with it for now (although I guess it will change when someone > starts creating really large meshes) but wanted to make sure I understood > the assumptions being made. > > > 2. I haven't did a deep look into WriteMesh, but we need to confirm that > we have a clear understanding of Export, Write, and WriteAs handled > properly. I am concerned that saving the location to writeLocation could > change a subsequent model write in the future by mistake. > > You're saying that we should instead do: > > collection->writeLocation(filePath); > return writer->write(collection, subset); > > > Now if these changes are correct, you should specify the writeLocation > before calling write, as that will allow you to us the unspecified > writer->write api IIRC. > > I am fine with changing the order inside the operator as above, but want > to be sure the filename is preserved in the collection so that saving the > SMTK model will result in updates to the mesh (such as changes in the > classification) get preserved. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon May 15 10:32:34 2017 From: david.thompson at kitware.com (David Thompson) Date: Mon, 15 May 2017 10:32:34 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> Message-ID: <92BA23E2-3928-4D4A-94C0-2BA0D7A7E7EE@kitware.com> Hi TJ, > >> Because I would like to be able to perform existence/location tests on the client for CMB v4. > > Ah, that?s a very good reason! I?ve cc?d Robert because he?s the guy to ask, but I can give you my version of an answer. Also, do mesh Collections have a clean/dirty flag anywhere to indicate that they've been modified since the last write? If so, the WriteMesh operator should probably add this to its result-definition: to indicate that the "mesh_modified" entries should be marked clean. (This convention is used by model operators such as SaveSMTKModel and LoadSMTKModel.) David From robert.maynard at kitware.com Mon May 15 11:18:02 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 15 May 2017 11:18:02 -0400 Subject: [Smtk-developers] Operator results with mesh changes In-Reply-To: <92BA23E2-3928-4D4A-94C0-2BA0D7A7E7EE@kitware.com> References: <0307A935-C084-41A1-91BB-4C77826AFAC6@kitware.com> <0E4DB54F-251D-4A89-9029-A56B45B433C4@kitware.com> <52506DD2-AC9B-4A9C-A9B0-C90C051F12ED@kitware.com> <92BA23E2-3928-4D4A-94C0-2BA0D7A7E7EE@kitware.com> Message-ID: Yes Collections have a modified flag, and writing it does set it to false. You can query it with "isModified" On Mon, May 15, 2017 at 10:32 AM, David Thompson wrote: > Hi TJ, > > > > >> Because I would like to be able to perform existence/location tests on > the client for CMB v4. > > > > Ah, that?s a very good reason! I?ve cc?d Robert because he?s the guy to > ask, but I can give you my version of an answer. > > Also, do mesh Collections have a clean/dirty flag anywhere to indicate > that they've been modified since the last write? > > If so, the WriteMesh operator should probably add this to its > result-definition: > > > > to indicate that the "mesh_modified" entries should be marked clean. (This > convention is used by model operators such as SaveSMTKModel and > LoadSMTKModel.) > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From kriolog at gmail.com Tue May 16 13:01:32 2017 From: kriolog at gmail.com (Maxim Torgonskiy) Date: Tue, 16 May 2017 13:01:32 -0400 Subject: [Smtk-developers] (no subject) Message-ID: Hello, I'm trying to build cmb-superbuild with moab (gcc version 6.3.0 20170425 (Debian 6.3.0-16)) and I have the following error: CMake Error at /home/kriolog/local/lib/cmb-superbuild_build/install/lib/cmake/MOAB/MOABConfig.cmake:45 (include): include could not find load file: cmb-superbuild_build/install/lib/cmake/MOAB/MOABTargets.cmake I've checked the repos smtk (branch master) and moab (branch for/smtk), there's no such file 'MOABTargets.cmake'. Please give me some guidelines about how to fix it. Regards, Maxi, From ben.boeckel at kitware.com Tue May 16 17:13:40 2017 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 16 May 2017 17:13:40 -0400 Subject: [Smtk-developers] (no subject) In-Reply-To: References: Message-ID: <20170516211340.GA3063@megas.kitware.com> On Tue, May 16, 2017 at 13:01:32 -0400, Maxim Torgonskiy wrote: > include could not find load file: > cmb-superbuild_build/install/lib/cmake/MOAB/MOABTargets.cmake > > I've checked the repos smtk (branch master) and moab (branch > for/smtk), there's no such file 'MOABTargets.cmake'. This file is generated during the build; they won't exist in the source directories at all. What else is in the install/lib/cmake/* directories? --Ben From david.thompson at kitware.com Tue May 23 14:13:51 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 23 May 2017 14:13:51 -0400 Subject: [Smtk-developers] Exodus session changes Message-ID: <3569C8C9-F7EA-45AC-8492-3D244A57C1AA@kitware.com> Hi Bob, Here's what I think it will take to change the Exodus session so that some blocks may be presented as cells (volumes, faces, edges, ...) instead of groups. In smtk/bridge/exodus/Session.cxx: 1. lines 310--327 will need to change so that insertCellOfDimension(dim) is called instead of insertGroup(). 2. lines 387--390 will need to change how children are added to their parents 3. lines 419, 424, 429 (which call setMembershipMask) on SMTK group entities need to be removed since the SMTK entities will now be cells. I'm not sure of all the side effects, but that should get you to the next step. David From david.thompson at kitware.com Wed May 24 17:18:45 2017 From: david.thompson at kitware.com (David Thompson) Date: Wed, 24 May 2017 17:18:45 -0400 Subject: [Smtk-developers] Breaking change Message-ID: Hi all, I've merged a change to the "save smtk model" operator in SMTK that breaks CMB/ModelBuilder. The corresponding CMB merge request should be tested and merged later this evening. Don't update SMTK unless you are ready for breakage in the meantime. David From david.thompson at kitware.com Thu May 25 15:54:20 2017 From: david.thompson at kitware.com (David Thompson) Date: Thu, 25 May 2017 15:54:20 -0400 Subject: [Smtk-developers] Breaking change In-Reply-To: References: Message-ID: <379221BF-9507-46ED-BBD0-1258B5C3300A@kitware.com> Hi all, > I've merged a change to the "save smtk model" operator in SMTK that breaks CMB/ModelBuilder. The corresponding CMB merge request should be tested and merged later this evening. > > Don't update SMTK unless you are ready for breakage in the meantime. Both CMB and SMTK changes have been merged. Changes for CMB users: + The "Model - Save" operator now has options that affect how data is saved: + The _save_ option will only work if every model's data has a pre-existing filename *and* you have saved the model to an SMTK file before. It will overwrite any pre-existing files with what's in memory. After saving, the models in memory will be "clean" so you can quit without an alert popup. + The _save as_ option requires you to choose an SMTK file (and should ask you if you want to overwrite should it already exist). After saving, the models in memory will be "clean" so you can quit without an alert popup. + The _save a package/copy_ option requires you to choose an SMTK file. After saving, any changes to model names and URLs are reverted so that you can keep a backup copy of your work without accidentally overwriting it the next time you save. + The _file_ menu now has _Save_, _Save As_, and _Save a Package_ menu items with keyboard shortcuts Cmd-S/Ctrl-S for Save and Shift-Cmd-S/Shift-Ctrl-S for Save As. Changes for SMTK developers: + The "save smtk model" operator no longer has options for "embed data" and "rename models". Instead, it contains items that let you specify a set of string-property edits to take place on model entities and URL changes for mesh collections. These changes can be reverted (when "undo edits" is enabled) after the save operation to enable "save a copy" mode. + Use the SaveJSON::prepareToSave method to obtain property changes for any of the options described above in the CMB section. These changes make using the operator via C++ more difficult but also add significant flexibility. David From david.thompson at kitware.com Fri May 26 11:42:29 2017 From: david.thompson at kitware.com (David Thompson) Date: Fri, 26 May 2017 11:42:29 -0400 Subject: [Smtk-developers] Weird pybind warning Message-ID: Hi all (but esp. TJ), Any idea what could cause this strange pybind warning on kerbin? https://open.cdash.org/viewBuildError.php?type=1&buildid=4914442 David From tj.corona at kitware.com Fri May 26 12:04:27 2017 From: tj.corona at kitware.com (TJ Corona) Date: Fri, 26 May 2017 12:04:27 -0400 Subject: [Smtk-developers] Weird pybind warning In-Reply-To: References: Message-ID: <27874533-626A-4638-BEFB-04B75B9D4ADB@kitware.com> Nope, but I can look into it. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 26, 2017, at 11:42 AM, David Thompson wrote: > > Hi all (but esp. TJ), > > Any idea what could cause this strange pybind warning on kerbin? > > https://open.cdash.org/viewBuildError.php?type=1&buildid=4914442 > > David > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From tj.corona at kitware.com Tue May 30 09:28:13 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 30 May 2017 09:28:13 -0400 Subject: [Smtk-developers] Unhappy dashboards Message-ID: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> Hi all, This weekend was not great for our dashboard system. Something took down all of our machines except for Kerbin. I have been able to bring back Moho and TalosIV, but Endor, Junction and Praxis are still not responsive. I will continue to look into how to get everything back up and running, but I don?t have a ton of experience with this part of our testing infrastructure. Any advice would be greatly appreciated! Sincerely, T.J. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Tue May 30 09:45:26 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Tue, 30 May 2017 09:45:26 -0400 Subject: [Smtk-developers] Unhappy dashboards In-Reply-To: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> References: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> Message-ID: Hi TJ, On Tue, May 30, 2017 at 9:28 AM, TJ Corona wrote: > Hi all, > > This weekend was not great for our dashboard system. Something took down > all of our machines except for Kerbin. I have been able to bring back Moho > and TalosIV, but Endor, Junction and Praxis are still not responsive. I > will continue to look into how to get everything back up and running, but I > don?t have a ton of experience with this part of our testing > infrastructure. Any advice would be greatly appreciated! > > I just have a naive idea, would restart bring these machines back online? > Sincerely, > T.J. > > Thomas J. Corona, Ph.D. > Kitware, Inc. > Senior R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4443 <(518)%20881-4443> > > > _______________________________________________ > Smtk-developers mailing list > Smtk-developers at smtk.org > http://public.kitware.com/mailman/listinfo/smtk-developers > > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.obara at kitware.com Tue May 30 10:10:12 2017 From: bob.obara at kitware.com (Robert Michael O'Bara) Date: Tue, 30 May 2017 10:10:12 -0400 Subject: [Smtk-developers] Unhappy dashboards In-Reply-To: References: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> Message-ID: Do you mean the buildbot is not running? If that is the case I know what's wrong! Bob Sent from my iPhone > On May 30, 2017, at 9:45 AM, Haocheng Liu wrote: > > Hi TJ, > >> On Tue, May 30, 2017 at 9:28 AM, TJ Corona wrote: >> Hi all, >> >> This weekend was not great for our dashboard system. Something took down all of our machines except for Kerbin. I have been able to bring back Moho and TalosIV, but Endor, Junction and Praxis are still not responsive. I will continue to look into how to get everything back up and running, but I don?t have a ton of experience with this part of our testing infrastructure. Any advice would be greatly appreciated! >> > I just have a naive idea, would restart bring these machines back online? >> Sincerely, >> T.J. >> >> Thomas J. Corona, Ph.D. >> Kitware, Inc. >> Senior R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4443 >> >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers >> > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4421 > _______________________________________________ > 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 tj.corona at kitware.com Tue May 30 10:37:48 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 30 May 2017 10:37:48 -0400 Subject: [Smtk-developers] Unhappy dashboards In-Reply-To: References: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> Message-ID: <27978598-EDEF-49CB-8E72-9114240D6AE5@kitware.com> Here is the current situation: Kerbin: working Moho: working Praxis: working TalosIV: working Junction: idle, perhaps the build slave isn?t running? It says "no current builds" Endor: unresponsive (I can ping, I can log in, but it isn?t showing up on any buildbot/cdash pages) I don?t think Endor is critical, since all of its results are uploaded to ?experimental? at this point anyway. Bob: if you have an idea about how to get Junction back, I?d love to hear it! > Next, try re-installing Windows. 8-) (Shudder) Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 30, 2017, at 10:10 AM, Robert Michael O'Bara wrote: > > Do you mean the buildbot is not running? > > If that is the case I know what's wrong! > > Bob > > Sent from my iPhone > > On May 30, 2017, at 9:45 AM, Haocheng Liu > wrote: > >> Hi TJ, >> >> On Tue, May 30, 2017 at 9:28 AM, TJ Corona > wrote: >> Hi all, >> >> This weekend was not great for our dashboard system. Something took down all of our machines except for Kerbin. I have been able to bring back Moho and TalosIV, but Endor, Junction and Praxis are still not responsive. I will continue to look into how to get everything back up and running, but I don?t have a ton of experience with this part of our testing infrastructure. Any advice would be greatly appreciated! >> >> I just have a naive idea, would restart bring these machines back online? >> Sincerely, >> T.J. >> >> Thomas J. Corona, Ph.D. >> Kitware, Inc. >> Senior R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4443 >> >> _______________________________________________ >> Smtk-developers mailing list >> Smtk-developers at smtk.org >> http://public.kitware.com/mailman/listinfo/smtk-developers >> >> >> >> >> -- >> Best regards >> Haocheng >> >> Haocheng LIU >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4421 >> _______________________________________________ >> 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 Tue May 30 10:54:28 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 May 2017 10:54:28 -0400 Subject: [Smtk-developers] Unhappy dashboards In-Reply-To: <27978598-EDEF-49CB-8E72-9114240D6AE5@kitware.com> References: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> <27978598-EDEF-49CB-8E72-9114240D6AE5@kitware.com> Message-ID: <9EAE2867-6C8A-4CB9-A137-8190C926FC5B@kitware.com> Hi TJ, > Junction: idle, perhaps the build slave isn?t running? It says "no current builds" > Endor: unresponsive (I can ping, I can log in, but it isn?t showing up on any buildbot/cdash pages) I see here: https://buildbot.kitware.com/buildslaves/junction that there haven't been any connections in the last hour, but also that there are no pending builds. If you can verify that a "buildslave" process is running and not hung, then it looks like junction is fine. David From david.thompson at kitware.com Tue May 30 11:00:39 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 May 2017 11:00:39 -0400 Subject: [Smtk-developers] Unhappy dashboards In-Reply-To: <9EAE2867-6C8A-4CB9-A137-8190C926FC5B@kitware.com> References: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> <27978598-EDEF-49CB-8E72-9114240D6AE5@kitware.com> <9EAE2867-6C8A-4CB9-A137-8190C926FC5B@kitware.com> Message-ID: >> Junction: idle, perhaps the build slave isn?t running? It says "no current builds" >> Endor: unresponsive (I can ping, I can log in, but it isn?t showing up on any buildbot/cdash pages) > > I see here: https://buildbot.kitware.com/buildslaves/junction that there haven't been any connections in the last hour, but also that there are no pending builds. If you can verify that a "buildslave" process is running and not hung, then it looks like junction is fine. I take that back. Apparently, the buildslave page does not report pending builds and there are pending builds requested (at least https://buildbot.kitware.com/builders/smtk-junction-osx-shared-release%2Bpybind11 ). So, if you log in to junction, what does "ps ax | grep buildslave" say? Is it a zombie process or just not started? Do you know if Ben was using launchctl to start the buildslave? David From tj.corona at kitware.com Tue May 30 11:14:35 2017 From: tj.corona at kitware.com (TJ Corona) Date: Tue, 30 May 2017 11:14:35 -0400 Subject: [Smtk-developers] Unhappy dashboards In-Reply-To: References: <688FE8C3-7870-41EC-B584-CC1F9BD89B2B@kitware.com> <27978598-EDEF-49CB-8E72-9114240D6AE5@kitware.com> <9EAE2867-6C8A-4CB9-A137-8190C926FC5B@kitware.com> Message-ID: <62EA3975-A7AF-40A7-8ED2-486FF96D8C7E@kitware.com> Thanks for the tips David! Bob has stopped by and rebooted Junction (required admin privileges), so we are now in good shape. Thomas J. Corona, Ph.D. Kitware, Inc. Senior R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4443 > On May 30, 2017, at 11:00 AM, David Thompson wrote: > >>> Junction: idle, perhaps the build slave isn?t running? It says "no current builds" >>> Endor: unresponsive (I can ping, I can log in, but it isn?t showing up on any buildbot/cdash pages) >> >> I see here: https://buildbot.kitware.com/buildslaves/junction that there haven't been any connections in the last hour, but also that there are no pending builds. If you can verify that a "buildslave" process is running and not hung, then it looks like junction is fine. > > I take that back. Apparently, the buildslave page does not report pending builds and there are pending builds requested (at least https://buildbot.kitware.com/builders/smtk-junction-osx-shared-release%2Bpybind11 ). > > So, if you log in to junction, what does "ps ax | grep buildslave" say? Is it a zombie process or just not started? Do you know if Ben was using launchctl to start the buildslave? > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From kriolog at gmail.com Tue May 30 12:35:34 2017 From: kriolog at gmail.com (Maxim Torgonskiy) Date: Tue, 30 May 2017 12:35:34 -0400 Subject: [Smtk-developers] (no subject) In-Reply-To: <20170516211340.GA3063@megas.kitware.com> References: <20170516211340.GA3063@megas.kitware.com> Message-ID: Hi Ben, I've created a docker image (debian stretch) for the cmb compilation to be sure that the build is clean and the error is reproducible. Could you please take a look at it? The config is the following: ==================================== #Dockerfile FROM debian:stretch MAINTAINER Maxim Torgonskiy RUN export DEBIAN_FRONTEND=noninteractive # Add user jenkins to the image RUN useradd -m -d /home/jenkins -s /bin/sh jenkins # Set password for the jenkins user (you may want to alter this). RUN echo "jenkins:jenkins" | chpasswd # Make sure the package repository is up to date. RUN apt-get update RUN apt-get -y upgrade # Install development tools (gcc, make, etc.) RUN apt-get install -y build-essential # Install SSH server RUN apt-get install -y openssh-server RUN sed -i 's|session required pam_loginuid.so|session optional pam_loginuid.so|g' /etc/pam.d/sshd RUN mkdir -p /var/run/sshd # Install JDK 8 RUN apt-get install -y openjdk-8-jdk # Install Git RUN apt-get install -y git # Install dependencies RUN apt-get install -y build-essential RUN apt-get install -y m4 RUN apt-get install -y git RUN apt-get install -y cmake RUN apt-get install -y qt4-qmake libqt4-dev qt4-dev-tools RUN apt-get install -y libxt-dev RUN apt-get install -y gfortran # Standard SSH port EXPOSE 22 CMD ["/usr/sbin/sshd", "-D"] ==================================== I build the project (https://gitlab.kitware.com/cmb/cmb-superbuild.git , branch master) with the following arguments: ==================================== -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_TESTING:BOOL=OFF -DENABLE_cmb:BOOL=OFF -DENABLE_smtk:BOOL=ON -DENABLE_moab:BOOL=ON -DENABLE_cgm:BOOL=ON -DENABLE_oce:BOOL=ON -DENABLE_qt4:BOOL=ON -DENABLE_qt5:BOOL=OFF -DUSE_SYSTEM_qt4:BOOL=ON -DUSE_SYSTEM_qt5:BOOL=OFF ==================================== The error is the same: ==================================== [ 98%] Performing configure step for 'smtk' ... -- Found MOAB: /home/jenkins/workspace/CMBDockerLinux/cmb_superbuild_build/install/include CMake Error at /home/jenkins/workspace/CMBDockerLinux/cmb_superbuild_build/install/lib/cmake/MOAB/MOABConfig.cmake:45 (include): include could not find load file: /home/jenkins/workspace/CMBDockerLinux/cmb_superbuild_build/install/lib/cmake/MOAB/MOABTargets.cmake Call Stack (most recent call first): CMake/FindMOAB.cmake:55 (include) CMakeLists.txt:241 (find_package) CMake Error at CMake/FindMOAB.cmake:56 (include): include could not find load file: /home/jenkins/workspace/CMBDockerLinux/cmb_superbuild_build/install/lib/cmake/MOAB/MOABTargets.cmake Call Stack (most recent call first): CMakeLists.txt:241 (find_package) CMake Error at CMake/FindMOAB.cmake:70 (set_target_properties): set_target_properties Can not find target to add properties to: MOAB Call Stack (most recent call first): CMakeLists.txt:241 (find_package) ==================================== The full build log is here: https://gist.githubusercontent.com/kriolog/80021835822ffc519f009b15cb9ecf70/raw/ec5753d5976abcec6e71fecdea50af6bda0e552f/cmb-superbuild_build_log Thanks, Maxim 2017-05-18 16:45 GMT-04:00 Maxim Torgonskiy : > Today I've successfully built smtk with the following options: > ccmake \ > -DBoost_INCLUDE_DIR:PATH=/usr/include \ > -DBOOST_LIBRARYDIR:PATH=/usr/lib/x86_64-linux-gnu \ > -DSMTK_ENABLE_PARAVIEW_SUPPORT:BOOL=ON \ > -DParaView_DIR:PATH=path/to/ParaView-v5.3.0/build \ > -DSMTK_ENABLE_QT_SUPPORT:BOOL=ON \ > -DSMTK_QT_VERSION:STRING=5 \ > -DSMTK_IGNORE_MOAB_WARNINGS:BOOL=OFF\ > /path/to/src > > 2017-05-16 17:26 GMT-04:00 Maxim Torgonskiy : >> Thanks Ben, >> >> Here is the output for the cmb-superbuild. I'll also try to build >> standalone smtk. >> >> ? tree cmb-superbuild_build/install/lib/cmake/ >> cmb-superbuild_build/install/lib/cmake/ >> ??? CGM >> ? ??? CGMConfig.cmake >> ? ??? CGMTargets.cmake >> ? ??? CGMTargets-release.cmake >> ? ??? FindCUBIT.cmake >> ??? FTGL >> ? ??? FTGLConfig.cmake >> ? ??? FTGL-targets.cmake >> ? ??? FTGL-targets-release.cmake >> ??? MOAB >> ? ??? MOABConfig.cmake >> ??? paraview-5.4 >> ? ??? branded_paraview_initializer.cxx.in >> ? ??? branded_paraview_initializer.h.in >> ? ??? branded_paraview_main.cxx.in >> ? ??? BundleUtilities.cmake >> ? ??? CheckFortran.cmake >> ? ??? CTestCustom.cmake.in >> ? ??? ExternalData.cmake >> ? ??? ExternalData_config.cmake.in >> ? ??? FindATP.cmake >> ? ??? FindCGNS.cmake >> ? ??? FindGenericIO.cmake >> ? ??? FindJSDuck.cmake >> ? ??? Findpugixml.cmake >> ? ??? FindSeleniumDrivers.cmake >> ? ??? FindSILO.cmake >> ? ??? FindTCL.cmake >> ? ??? generate_category_rw.xsl >> ? ??? generate_proxydocumentation.cmake >> ? ??? generate_qhp.cmake >> ? ??? MacOSXBundleInfo.plist.in.in >> ? ??? Modules >> ? ? ??? CinemaPython.cmake >> ? ? ??? pqApplicationComponents.cmake >> ? ? ??? pqComponents.cmake >> ? ? ??? pqCore.cmake >> ? ? ??? pqPython.cmake >> ? ? ??? pqWidgets.cmake >> ? ? ??? Pygments.cmake >> ? ? ??? smTestDriver.cmake >> ? ? ??? vtkalglib.cmake >> ? ? ??? vtkcgns.cmake >> ? ? ??? vtkChartsCore.cmake >> ? ? ??? vtkChartsCoreHierarchy.txt >> ? ? ??? vtkClientServer.cmake >> ? ? ??? vtkCommonColor.cmake >> ? ? ??? vtkCommonColorHierarchy.txt >> ? ? ??? vtkCommonComputationalGeometry.cmake >> ? ? ??? vtkCommonComputationalGeometryHierarchy.txt >> ? ? ??? vtkCommonCore.cmake >> ? ? ??? vtkCommonCoreHierarchy.txt >> ? ? ??? vtkCommonDataModel.cmake >> ? ? ??? vtkCommonDataModelHierarchy.txt >> ? ? ??? vtkCommonExecutionModel.cmake >> ? ? ??? vtkCommonExecutionModelHierarchy.txt >> ? ? ??? vtkCommonMath.cmake >> ? ? ??? vtkCommonMathHierarchy.txt >> ? ? ??? vtkCommonMisc.cmake >> ? ? ??? vtkCommonMiscHierarchy.txt >> ? ? ??? vtkCommonSystem.cmake >> ? ? ??? vtkCommonSystemHierarchy.txt >> ? ? ??? vtkCommonTransforms.cmake >> ? ? ??? vtkCommonTransformsHierarchy.txt >> ? ? ??? vtkDICOMParser.cmake >> ? ? ??? vtkDomainsChemistry.cmake >> ? ? ??? vtkDomainsChemistryHierarchy.txt >> ? ? ??? vtkDomainsChemistryOpenGL2.cmake >> ? ? ??? vtkDomainsChemistryOpenGL2Hierarchy.txt >> ? ? ??? vtkexodusII.cmake >> ? ? ??? vtkexpat.cmake >> ? ? ??? vtkFiltersAMR.cmake >> ? ? ??? vtkFiltersAMRHierarchy.txt >> ? ? ??? vtkFiltersCore.cmake >> ? ? ??? vtkFiltersCoreHierarchy.txt >> ? ? ??? vtkFiltersExtraction.cmake >> ? ? ??? vtkFiltersExtractionHierarchy.txt >> ? ? ??? vtkFiltersFlowPaths.cmake >> ? ? ??? vtkFiltersFlowPathsHierarchy.txt >> ? ? ??? vtkFiltersGeneral.cmake >> ? ? ??? vtkFiltersGeneralHierarchy.txt >> ? ? ??? vtkFiltersGeneric.cmake >> ? ? ??? vtkFiltersGenericHierarchy.txt >> ? ? ??? vtkFiltersGeometry.cmake >> ? ? ??? vtkFiltersGeometryHierarchy.txt >> ? ? ??? vtkFiltersHybrid.cmake >> ? ? ??? vtkFiltersHybridHierarchy.txt >> ? ? ??? vtkFiltersHyperTree.cmake >> ? ? ??? vtkFiltersHyperTreeHierarchy.txt >> ? ? ??? vtkFiltersImaging.cmake >> ? ? ??? vtkFiltersImagingHierarchy.txt >> ? ? ??? vtkFiltersModeling.cmake >> ? ? ??? vtkFiltersModelingHierarchy.txt >> ? ? ??? vtkFiltersParallel.cmake >> ? ? ??? vtkFiltersParallelHierarchy.txt >> ? ? ??? vtkFiltersParallelStatistics.cmake >> ? ? ??? vtkFiltersParallelStatisticsHierarchy.txt >> ? ? ??? vtkFiltersPoints.cmake >> ? ? ??? vtkFiltersPointsHierarchy.txt >> ? ? ??? vtkFiltersProgrammable.cmake >> ? ? ??? vtkFiltersProgrammableHierarchy.txt >> ? ? ??? vtkFiltersPython.cmake >> ? ? ??? vtkFiltersPythonHierarchy.txt >> ? ? ??? vtkFiltersSources.cmake >> ? ? ??? vtkFiltersSourcesHierarchy.txt >> ? ? ??? vtkFiltersStatistics.cmake >> ? ? ??? vtkFiltersStatisticsHierarchy.txt >> ? ? ??? vtkFiltersTexture.cmake >> ? ? ??? vtkFiltersTextureHierarchy.txt >> ? ? ??? vtkFiltersVerdict.cmake >> ? ? ??? vtkFiltersVerdictHierarchy.txt >> ? ? ??? vtkfreetype.cmake >> ? ? ??? vtkGeovisCore.cmake >> ? ? ??? vtkGeovisCoreHierarchy.txt >> ? ? ??? vtkgl2ps.cmake >> ? ? ??? vtkglew.cmake >> ? ? ??? vtkGUISupportQt.cmake >> ? ? ??? vtkhdf5.cmake >> ? ? ??? vtkImagingColor.cmake >> ? ? ??? vtkImagingColorHierarchy.txt >> ? ? ??? vtkImagingCore.cmake >> ? ? ??? vtkImagingCoreHierarchy.txt >> ? ? ??? vtkImagingFourier.cmake >> ? ? ??? vtkImagingFourierHierarchy.txt >> ? ? ??? vtkImagingGeneral.cmake >> ? ? ??? vtkImagingGeneralHierarchy.txt >> ? ? ??? vtkImagingHybrid.cmake >> ? ? ??? vtkImagingHybridHierarchy.txt >> ? ? ??? vtkImagingMath.cmake >> ? ? ??? vtkImagingMathHierarchy.txt >> ? ? ??? vtkImagingMorphological.cmake >> ? ? ??? vtkImagingMorphologicalHierarchy.txt >> ? ? ??? vtkImagingSources.cmake >> ? ? ??? vtkImagingSourcesHierarchy.txt >> ? ? ??? vtkInfovisCore.cmake >> ? ? ??? vtkInfovisCoreHierarchy.txt >> ? ? ??? vtkInfovisLayout.cmake >> ? ? ??? vtkInfovisLayoutHierarchy.txt >> ? ? ??? vtkInteractionImage.cmake >> ? ? ??? vtkInteractionImageHierarchy.txt >> ? ? ??? vtkInteractionStyle.cmake >> ? ? ??? vtkInteractionStyleHierarchy.txt >> ? ? ??? vtkInteractionWidgets.cmake >> ? ? ??? vtkInteractionWidgetsHierarchy.txt >> ? ? ??? vtkIOAMR.cmake >> ? ? ??? vtkIOAMRHierarchy.txt >> ? ? ??? vtkIOCore.cmake >> ? ? ??? vtkIOCoreHierarchy.txt >> ? ? ??? vtkIOEnSight.cmake >> ? ? ??? vtkIOEnSightHierarchy.txt >> ? ? ??? vtkIOExodus.cmake >> ? ? ??? vtkIOExodusHierarchy.txt >> ? ? ??? vtkIOExport.cmake >> ? ? ??? vtkIOExportHierarchy.txt >> ? ? ??? vtkIOExportOpenGL2.cmake >> ? ? ??? vtkIOExportOpenGL2Hierarchy.txt >> ? ? ??? vtkIOGDAL.cmake >> ? ? ??? vtkIOGDALHierarchy.txt >> ? ? ??? vtkIOGeometry.cmake >> ? ? ??? vtkIOGeometryHierarchy.txt >> ? ? ??? vtkIOImage.cmake >> ? ? ??? vtkIOImageHierarchy.txt >> ? ? ??? vtkIOImport.cmake >> ? ? ??? vtkIOImportHierarchy.txt >> ? ? ??? vtkIOInfovis.cmake >> ? ? ??? vtkIOInfovisHierarchy.txt >> ? ? ??? vtkIOLegacy.cmake >> ? ? ??? vtkIOLegacyHierarchy.txt >> ? ? ??? vtkIOLSDyna.cmake >> ? ? ??? vtkIOLSDynaHierarchy.txt >> ? ? ??? vtkIOMovie.cmake >> ? ? ??? vtkIOMovieHierarchy.txt >> ? ? ??? vtkIONetCDF.cmake >> ? ? ??? vtkIONetCDFHierarchy.txt >> ? ? ??? vtkIOParallel.cmake >> ? ? ??? vtkIOParallelExodus.cmake >> ? ? ??? vtkIOParallelExodusHierarchy.txt >> ? ? ??? vtkIOParallelHierarchy.txt >> ? ? ??? vtkIOParallelLSDyna.cmake >> ? ? ??? vtkIOParallelLSDynaHierarchy.txt >> ? ? ??? vtkIOParallelXML.cmake >> ? ? ??? vtkIOParallelXMLHierarchy.txt >> ? ? ??? vtkIOPLY.cmake >> ? ? ??? vtkIOPLYHierarchy.txt >> ? ? ??? vtkIOTecplotTable.cmake >> ? ? ??? vtkIOTecplotTableHierarchy.txt >> ? ? ??? vtkIOTRUCHAS.cmake >> ? ? ??? vtkIOTRUCHASHierarchy.txt >> ? ? ??? vtkIOVPIC.cmake >> ? ? ??? vtkIOVPICHierarchy.txt >> ? ? ??? vtkIOXdmf2.cmake >> ? ? ??? vtkIOXdmf2Hierarchy.txt >> ? ? ??? vtkIOXML.cmake >> ? ? ??? vtkIOXMLHierarchy.txt >> ? ? ??? vtkIOXMLParser.cmake >> ? ? ??? vtkIOXMLParserHierarchy.txt >> ? ? ??? vtkjpeg.cmake >> ? ? ??? vtkjsoncpp.cmake >> ? ? ??? vtkkwiml.cmake >> ? ? ??? vtklibproj4.cmake >> ? ? ??? vtklibxml2.cmake >> ? ? ??? vtklz4.cmake >> ? ? ??? vtkMetaIO.cmake >> ? ? ??? vtknetcdf.cmake >> ? ? ??? vtknetcdfcpp.cmake >> ? ? ??? vtkoggtheora.cmake >> ? ? ??? vtkParallelCore.cmake >> ? ? ??? vtkParallelCoreHierarchy.txt >> ? ? ??? vtkpng.cmake >> ? ? ??? vtkprotobuf.cmake >> ? ? ??? vtkpugixml.cmake >> ? ? ??? vtkPVAnimation.cmake >> ? ? ??? vtkPVAnimationHierarchy.txt >> ? ? ??? vtkPVCinemaReader.cmake >> ? ? ??? vtkPVCinemaReaderHierarchy.txt >> ? ? ??? vtkPVClientServerCoreCore.cmake >> ? ? ??? vtkPVClientServerCoreCoreHierarchy.txt >> ? ? ??? vtkPVClientServerCoreCore_HINTS >> ? ? ??? vtkPVClientServerCoreDefault.cmake >> ? ? ??? vtkPVClientServerCoreDefaultHierarchy.txt >> ? ? ??? vtkPVClientServerCoreRendering.cmake >> ? ? ??? vtkPVClientServerCoreRenderingHierarchy.txt >> ? ? ??? vtkPVClientServerCoreRendering_HINTS >> ? ? ??? vtkPVCommon.cmake >> ? ? ??? vtkPVCommonHierarchy.txt >> ? ? ??? vtkPVServerImplementationCore.cmake >> ? ? ??? vtkPVServerImplementationCoreHierarchy.txt >> ? ? ??? vtkPVServerImplementationRendering.cmake >> ? ? ??? vtkPVServerImplementationRenderingHierarchy.txt >> ? ? ??? vtkPVServerManagerApplication.cmake >> ? ? ??? vtkPVServerManagerApplicationHierarchy.txt >> ? ? ??? vtkPVServerManagerCore.cmake >> ? ? ??? vtkPVServerManagerCoreHierarchy.txt >> ? ? ??? vtkPVServerManagerDefault.cmake >> ? ? ??? vtkPVServerManagerDefaultHierarchy.txt >> ? ? ??? vtkPVServerManagerRendering.cmake >> ? ? ??? vtkPVServerManagerRenderingHierarchy.txt >> ? ? ??? vtkPVVTKExtensionsCGNSReader.cmake >> ? ? ??? vtkPVVTKExtensionsCGNSReaderHierarchy.txt >> ? ? ??? vtkPVVTKExtensionsCore.cmake >> ? ? ??? vtkPVVTKExtensionsCoreHierarchy.txt >> ? ? ??? vtkPVVTKExtensionsDefault.cmake >> ? ? ??? vtkPVVTKExtensionsDefaultHierarchy.txt >> ? ? ??? vtkPVVTKExtensionsDefault_HINTS >> ? ? ??? vtkPVVTKExtensionsH5PartReader.cmake >> ? ? ??? vtkPVVTKExtensionsH5PartReaderHierarchy.txt >> ? ? ??? vtkPVVTKExtensionsPoints.cmake >> ? ? ??? vtkPVVTKExtensionsPointsHierarchy.txt >> ? ? ??? vtkPVVTKExtensionsRendering.cmake >> ? ? ??? vtkPVVTKExtensionsRenderingHierarchy.txt >> ? ? ??? vtkPython.cmake >> ? ? ??? vtkPythonInterpreter.cmake >> ? ? ??? vtkPythonInterpreterHierarchy.txt >> ? ? ??? vtkqttesting.cmake >> ? ? ??? vtkRenderingAnnotation.cmake >> ? ? ??? vtkRenderingAnnotationHierarchy.txt >> ? ? ??? vtkRenderingContext2D.cmake >> ? ? ??? vtkRenderingContext2DHierarchy.txt >> ? ? ??? vtkRenderingContextOpenGL2.cmake >> ? ? ??? vtkRenderingContextOpenGL2Hierarchy.txt >> ? ? ??? vtkRenderingCore.cmake >> ? ? ??? vtkRenderingCoreHierarchy.txt >> ? ? ??? vtkRenderingFreeType.cmake >> ? ? ??? vtkRenderingFreeTypeHierarchy.txt >> ? ? ??? vtkRenderingGL2PSOpenGL2.cmake >> ? ? ??? vtkRenderingGL2PSOpenGL2Hierarchy.txt >> ? ? ??? vtkRenderingLabel.cmake >> ? ? ??? vtkRenderingLabelHierarchy.txt >> ? ? ??? vtkRenderingLICOpenGL2.cmake >> ? ? ??? vtkRenderingLICOpenGL2Hierarchy.txt >> ? ? ??? vtkRenderingLOD.cmake >> ? ? ??? vtkRenderingLODHierarchy.txt >> ? ? ??? vtkRenderingMatplotlib.cmake >> ? ? ??? vtkRenderingMatplotlibHierarchy.txt >> ? ? ??? vtkRenderingOpenGL2.cmake >> ? ? ??? vtkRenderingOpenGL2Hierarchy.txt >> ? ? ??? vtkRenderingParallel.cmake >> ? ? ??? vtkRenderingParallelHierarchy.txt >> ? ? ??? vtkRenderingVolumeAMR.cmake >> ? ? ??? vtkRenderingVolumeAMRHierarchy.txt >> ? ? ??? vtkRenderingVolume.cmake >> ? ? ??? vtkRenderingVolumeHierarchy.txt >> ? ? ??? vtkRenderingVolumeOpenGL2.cmake >> ? ? ??? vtkRenderingVolumeOpenGL2Hierarchy.txt >> ? ? ??? vtksys.cmake >> ? ? ??? vtkTestingCore.cmake >> ? ? ??? vtkTestingRendering.cmake >> ? ? ??? vtkTestingRenderingHierarchy.txt >> ? ? ??? vtktiff.cmake >> ? ? ??? vtkUtilitiesEncodeString.cmake >> ? ? ??? vtkUtilitiesHashSource.cmake >> ? ? ??? vtkUtilitiesLegacyColorMapXMLToJSON.cmake >> ? ? ??? vtkUtilitiesProcessXML.cmake >> ? ? ??? vtkUtilitiesPythonInitializer.cmake >> ? ? ??? vtkUtilitiesWrapClientServer.cmake >> ? ? ??? vtkverdict.cmake >> ? ? ??? vtkViewsContext2D.cmake >> ? ? ??? vtkViewsContext2DHierarchy.txt >> ? ? ??? vtkViewsCore.cmake >> ? ? ??? vtkViewsCoreHierarchy.txt >> ? ? ??? vtkViewsInfovis.cmake >> ? ? ??? vtkViewsInfovisHierarchy.txt >> ? ? ??? vtkVPIC.cmake >> ? ? ??? vtkWrappingPythonCore.cmake >> ? ? ??? vtkWrappingTools.cmake >> ? ? ??? vtkxdmf2.cmake >> ? ? ??? vtkzlib.cmake >> ? ??? ParaViewBranding.cmake >> ? ??? ParaViewBrandingCPack.cmake >> ? ??? ParaViewBrandingInstallApp.cmake >> ? ??? ParaViewCheckSourceTree.cmake >> ? ??? ParaViewConfig.cmake >> ? ??? ParaViewConfigVersion.cmake >> ? ??? ParaViewCPackOptions.cmake.in >> ? ??? ParaViewDetermineVersion.cmake >> ? ??? ParaViewExternalData.cmake >> ? ??? ParaViewMacros.cmake >> ? ??? ParaViewModuleTop.cmake >> ? ??? ParaViewPluginPackaging.cmake >> ? ??? ParaViewPlugins.cmake >> ? ??? ParaViewPluginsMacros.cmake >> ? ??? ParaViewQt.cmake >> ? ??? ParaViewTargets.cmake >> ? ??? ParaViewTargets-release.cmake >> ? ??? ParaViewTestingMacros.cmake >> ? ??? ParaViewTestInstall.cmake >> ? ??? ParaViewValgrindSuppressions.supp >> ? ??? pqActionGroupImplementation.cxx.in >> ? ??? pqActionGroupImplementation.h.in >> ? ??? pqAutoStartImplementation.cxx.in >> ? ??? pqAutoStartImplementation.h.in >> ? ??? pqDisplayPanelImplementation.cxx.in >> ? ??? pqDisplayPanelImplementation.h.in >> ? ??? pqDockWindowImplementation.cxx.in >> ? ??? pqDockWindowImplementation.h.in >> ? ??? pqGraphLayoutStrategyImplementation.cxx.in >> ? ??? pqGraphLayoutStrategyImplementation.h.in >> ? ??? pqParaViewPlugin.cxx.in >> ? ??? pqParaViewPlugin.h.in >> ? ??? pqPropertyWidgetInterface.cxx.in >> ? ??? pqPropertyWidgetInterface.h.in >> ? ??? pqServerManagerModelImplementation.cxx.in >> ? ??? pqServerManagerModelImplementation.h.in >> ? ??? pqTreeLayoutStrategyImplementation.cxx.in >> ? ??? pqTreeLayoutStrategyImplementation.h.in >> ? ??? pqViewFrameActionGroupImplementation.cxx.in >> ? ??? pqViewFrameActionGroupImplementation.h.in >> ? ??? pre-commit >> ? ??? pv-forward.c.in >> ? ??? pvForwardingExecutable.cmake >> ? ??? pythonmodules.h.in >> ? ??? Qt4Macros-CMake2.8.7.cmake >> ? ??? smxml_to_xml.xsl >> ? ??? TopologicalSort.cmake >> ? ??? TryRunResults-ParaView3-bgl-gcc.cmake >> ? ??? TryRunResults-ParaView3-bgl-xlc.cmake >> ? ??? TryRunResults-ParaView3-catamount-gcc.cmake >> ? ??? TryRunResults-ParaView3-catamount-pgi.cmake >> ? ??? TryRunResults-ParaView3-cnl-gcc.cmake >> ? ??? TryRunResults-ParaView3-cnl-pgi.cmake >> ? ??? UseParaView.cmake >> ? ??? UseVTK.cmake >> ? ??? vtkClientServerWrapping.cmake >> ? ??? VTKConfig.cmake >> ? ??? VTKConfigVersion.cmake >> ? ??? vtkexportheader.cmake.in >> ? ??? vtkExternalModuleMacros.cmake >> ? ??? vtk-forward.c.in >> ? ??? vtkForwardingExecutable.cmake >> ? ??? VTKGenerateExportHeader.cmake >> ? ??? vtkGroups.cmake >> ? ??? vtkJavaWrapping.cmake >> ? ??? vtkMakeInstantiator.cmake >> ? ??? vtkMakeInstantiator.cxx.in >> ? ??? vtkMakeInstantiator.h.in >> ? ??? vtkModuleAPI.cmake >> ? ??? vtkModuleHeaders.cmake.in >> ? ??? vtkModuleInfo.cmake.in >> ? ??? vtkModuleMacros.cmake >> ? ??? vtkModuleMacrosPython.cmake >> ? ??? VTKModules.cmake >> ? ??? vtkMPI.cmake >> ? ??? vtkObjectFactory.cxx.in >> ? ??? vtkObjectFactory.h.in >> ? ??? vtkPythonPackages.cmake >> ? ??? vtkPythonWrapping.cmake >> ? ??? vtkTargetLinkLibrariesWithDynamicLookup.cmake >> ? ??? vtkTclTkMacros.cmake >> ? ??? vtkTclWrapping.cmake >> ? ??? vtkThirdParty.cmake >> ? ??? vtkWrapClientServer.cmake >> ? ??? vtkWrapClientServer.cxx.in >> ? ??? vtkWrapHierarchy.cmake >> ? ??? vtkWrapJava.cmake >> ? ??? vtkWrapperInit.data.in >> ? ??? vtkWrapping.cmake >> ? ??? vtkWrapPython.cmake >> ? ??? vtkWrapPythonSIP.cmake >> ? ??? vtkWrapPython.sip.in >> ? ??? vtkWrapTcl.cmake >> ? ??? xml_to_html.xsl >> ? ??? xml_to_wiki.xsl.in >> ??? qttesting >> ? ??? ParaViewTargets.cmake >> ? ??? ParaViewTargets-release.cmake >> ? ??? QtTestingConfig.cmake >> ??? Remus >> ? ??? FindZeroMQ.cmake >> ? ??? RemusConfig.cmake >> ? ??? RemusRegisterWorker.cmake >> ? ??? Remus-targets.cmake >> ? ??? Remus-targets-release.cmake >> ??? Shiboken-1.2.1 >> ??? ShibokenConfig.cmake >> ??? ShibokenConfig-python2.7.cmake >> ??? ShibokenConfigVersion.cmake >> >> >> 2017-05-16 17:13 GMT-04:00 Ben Boeckel : >>> On Tue, May 16, 2017 at 13:01:32 -0400, Maxim Torgonskiy wrote: >>>> include could not find load file: >>>> cmb-superbuild_build/install/lib/cmake/MOAB/MOABTargets.cmake >>>> >>>> I've checked the repos smtk (branch master) and moab (branch >>>> for/smtk), there's no such file 'MOABTargets.cmake'. >>> >>> This file is generated during the build; they won't exist in the source >>> directories at all. What else is in the install/lib/cmake/* directories? >>> >>> --Ben 2017-05-16 17:13 GMT-04:00 Ben Boeckel : > On Tue, May 16, 2017 at 13:01:32 -0400, Maxim Torgonskiy wrote: >> include could not find load file: >> cmb-superbuild_build/install/lib/cmake/MOAB/MOABTargets.cmake >> >> I've checked the repos smtk (branch master) and moab (branch >> for/smtk), there's no such file 'MOABTargets.cmake'. > > This file is generated during the build; they won't exist in the source > directories at all. What else is in the install/lib/cmake/* directories? > > --Ben From david.thompson at kitware.com Tue May 30 15:32:23 2017 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 May 2017 15:32:23 -0400 Subject: [Smtk-developers] Tests in CMB Message-ID: Hi Jie, Below is a list of polygon-session functionality that would be nice to test in ModelBuilder. If there are things that aren't clear, please let me know. It would also be nice to test the model-entity to attribute association widgets, but that will take some thought as to how to verify the results. David + "Faces - Create All" + Create a face from a single edge loop + Create multiple, disjoint faces from several edge loops. + Create nested faces from several edge loops. + With overlap: + Create overlapping edge loops + Run the "Geometry - Clean" operator on all edges + Run "Faces - Create All" + Select some faces in the tree view so that the test image shows the tessellation is proper (non-overlapping) + Using elevation data: + Run "Model - Add Image" and choose dem/ChesapeakeBay100x100.vti data in the CMB test repo + Create edges with "Edge - Create from Contours" + Create all faces + Using image data: + Run "Model - Add Image" and choose image/geotiff/Aerial_utm.tif data in the CMB test repo + Create edges with "Edge - Create from Image Surfaces" + Use "Edge - Create Interactively" and "Edge - Create from vertices" to create a closed loop for the largest section. + Run "Faces - Create all" + [Extra Credit]: Also test saving/loading image mask and line data in the "Edge - Create from Image Surfaces" step. + "Edge - Split" + Load in an SMTK polygon model from the CMB test repo (we should put a couple more modern ones there) that has faces. + Run "Edge - Split" + [Extra Credit]: It would be nice to run an export script at this point and verify that pedigree IDs are preserved, but that would be a lot of work; ask John about how to proceed. + "Edge - Create from Points" + Manually specify a simple (triangle or quadrilateral) by specifying point coordinates. + "Model - Add Auxiliary Geometry" + Run this operator several times to verify that we can import: + VTK XML polydata (".vtp") files + Wavefront (".obj") files + Stanford triangle format (".ply") files + Point cloud (".xyz") files + We will need to find examples for some of these formats.