https://glvis.org/live/ "load local file" doesn't seem to work (as expected)

[samuelpmish]

I'm trying to figure out if a file is a valid mfem-format mesh, so I thought I'd test it out by trying to open it with GLVis. Rather than install it locally, it seemed easier to try

https://glvis.org/live/

and use the "load local file" option. It didn't seem to load my mesh, so I concluded that my file format was incorrect, but it doesn't seem to work for any files I tried, including a half dozen random meshes taken from mfem's data/meshes directory.

---

Here's the developer console output when trying to load mfem-format and vtk-format mesh files:

[tzanio]

Can you try adding mesh as the first line in your file?

[najlkin]

Yes, it takes saved streams as input. If you want to try loading some files, just navigate to the folder tests/data/streams in glvis (it is a submodule, so you might have to init it first by git submodule update --init). There are the examples. The format is straightforward, just solution followed by the mesh and grid function, or in your case mesh followed by the mesh only 😉 .

[samuelpmish]

The format is straightforward, just solution followed by the mesh and grid function, or in your case mesh followed by the mesh only 😉 .

Supporting streams seems like a useful feature, but not supporting mesh files directly seems like a missed opportunity. My expectation as a user was that the native application and the web-based one would agree on a common file format. At the very least, some warning in the developer console ("Error: importing .vtk files is not supported") or some self-documenting change to the UI (e.g. "Load Local File" -> "Load Local .saved File") would avoid the confusion completely.

Does this imply that the web-based application doesn't support vtk/vtu/gmsh visualization?

If the fix is as simple as prepending a small string, it seems like putting that directly in glvis-js would be preferable to asking users to modify their mesh files before importing.

[najlkin]

It supports different mesh file formats, you just need to wrap them to a stream, which is as simple as prepending that mesh keyword. I definitely agree there should be some description of what files the app expects and alternative input formats like that mesh files directly or grid functions 😉 .

[tzanio]

The command-line version has different options for loading mesh and/or solution which in parallel is multiple files. We didn't want to have to load multiple files in the online version, hence the choice to use the stream instead where all of this data is serialized. This is what GLVis sees anyway in the typical client/served mode.

[najlkin]

Maybe instead of complicated loading of multiple files at the same time, it could work sequentially? Like loading (and visualizing) the mesh first and then "dressing" it by the grid function? 🤔 So two separate buttons...

[samuelpmish]

It supports different mesh file formats, you just need to wrap them to a stream, which is as simple as prepending that mesh keyword.

I can't reproduce this, if I prepend mesh\n to a bunch of different file formats and load them with glvis-js, it either aborts or dumps the file contents to the console and fails to visualize them. Here's some files I tried including mfem, paraview and gmsh formats: test_meshes.zip

Edit: it looks like mfem/glvis only supports certain kinds of vtk and gmsh files, so maybe these test files are not supported by mfem/glvis at all.

I definitely agree there should be some description of what files the app expects and alternative input formats like that mesh files directly or grid functions 😉 .

To me, the obvious thing to do is just make the web app support the same kind of things that the native app does (so, .vtk/.vtu/.g/.msh/.mesh files).

We didn't want to have to load multiple files in the online version, hence the choice to use the stream instead where all of this data is serialized.

That's fine. Just disable support for distributed/partitioned meshes, and make a note of it somewhere people will see it (or write an error message if they try).

---

I still feel pretty strongly that a webapp shouldn't require users to prepend stuff to their data files to use them, so I made a small PR fixing that behavior: https://github.com/GLVis/glvis-js/pull/21

[tzanio]

Supporting files with mesh extension by treating them as a simple mesh stream is a good idea 👍

This will "just work" for meshes in MFEM format, and probably could be extended to work for other MFEM-supported formats, but currently that will not work.

I still think a stream is the natural way to support mesh + grid function, or any parallel visualization. The interface of a webapp and a command line executable are just different.

Note that the main use of this webapp is either in server/client mode during the AWS tutorials or as a Jupyter widget. In both cases the data comes as a stream and the behavior is identical to the desktop client.

[justinlaughlin]

Fixed by https://github.com/GLVis/glvis-js/pull/21

Thanks Sam!