[Smtk-developers] Operator results with mesh changes

[Robert Maynard]

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 <david.thompson at kitware.com>
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: <http://public.kitware.com/pipermail/smtk-developers/attachments/20170515/dc802da4/attachment.html>