[Smtk-developers] Operator results with mesh changes

[Robert Maynard]

>  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 <tj.corona at kitware.com> 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 <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/20170515/916e15b4/attachment.html>