[Smtk-developers] Operator results with mesh changes
TJ Corona
tj.corona at kitware.com
Fri May 12 17:43:19 EDT 2017
> 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 <david.thompson at kitware.com> 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: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170512/cec29aca/attachment.html>
More information about the Smtk-developers
mailing list