<div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div>>  <span style="font-size:12.8px">smtk::mesh currently supports two “interfaces”: Moab and Json</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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 ). </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">If the client and server have a different mesh manager, then the collections must have different FileLocation information.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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".</span></div><div><br></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">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.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 12, 2017 at 5:43 PM, TJ Corona <span dir="ltr"><<a href="mailto:tj.corona@kitware.com" target="_blank">tj.corona@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite">Because I would like to be able to perform existence/location tests on the client for CMB v4.</blockquote><br></div></span><div>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.</div><div><br></div><div>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!</div><span class=""><div><br></div><div>Sincerely,</div><div>T.J.</div><br><div>
<div style="word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Thomas J. Corona, Ph.D.<br>Kitware, Inc.<br>Senior R&D Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: <a href="tel:(518)%20881-4443" value="+15188814443" target="_blank">518-881-4443</a></div></div>

</div>
<br></span><span class=""><div><blockquote type="cite"><div>On May 12, 2017, at 1:19 PM, David Thompson <<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>> wrote:</div><br class="m_-98644548238135127Apple-interchange-newline"><div><div>Hi TJ,<br><br><blockquote type="cite">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).<br></blockquote><br>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?<br><br><span class="m_-98644548238135127Apple-tab-span" style="white-space:pre-wrap">        </span>Thanks,<br><span class="m_-98644548238135127Apple-tab-span" style="white-space:pre-wrap">  </span>David</div></div></blockquote></div><br></span></div></blockquote></div><br></div>