Per-instance instead of Per-db-type read options

[markcmiller86]

Is your feature request related to a problem?

MOAB developers have database read options that the use to filter element types from their stored database. For example, they may have both hexahedra and the faces of the (or some) hexahedra and they use database read options to tell the MOAB plugin to read only the faces or only the hexes. Ok, that works great!

The problem is that there appears to be one read options instance per database type and not per database instance. So, if you open two MOAB databases and switch back and forth between then, it remembers the db read options setting from the last database opened which may not be appropriate for the next.

It would be better to have db read options on a per-instance basis.

This may not be easily achieved in current design. So, can anyone suggest a MOAB-specific coded solution? Can we do something down in the plugin itself that would effectly always copy to a local (static) map of read options and then always check that map first for a pre-existing instance of read options before making a new copy from the one and only db read options instance VisIt is managing? Also, how would the plugin then set the options VisIt is using from its local copies in this case?

@iulian787

[markcmiller86]

Adding @vijaysm

[brugger1]

@biagas believes your proposed solution within the MOAB plugin will work.

[vijaysm]

Attaching some mesh files (2d and 3d) to replicate the problem workflow. mesh_files.tar.gz

[markcmiller86]

@biagas and @brugger1, the more I am looking at this, I don't know when the right opportunities are for the MOAB plugin to copy its read options to what VisIt thinks is the one and only global copy and when to copy VisIt's instance into the plugin.

[biagas]

I think we were confused as to when the read options becomes a problem. Detailed reproducer instructions would be helpful.

The read options are passed to the avtMOABFileFormat's constructor and then stored in the class. I assume the FileFormat's constructor is called for each new database being opened. Is it the case that after setting the Read options to open one MOAB database, the same options are used to open a second? If so, we need to find where else that first set of options are stored besides the FileFormat class.

Or is it the case that the options used to open the database get lost when 'reopen' is used?

[vijaysm]

@biagas The issue is that when I have say a 2D and 3D mesh opened in two seperate windows, and if I have a different set of options during file open, then refreshing using "reopen" imposes the last set of options that were used to open a database. This is often not what the user wants/expects. What would be ideal is to have a set of options associated to a database name such that a reopen will still retain the original set of options that were used to open the file. This is currently not the case.

[biagas]

@vijaysm thanks for the clarification, that definitely helps to direct our efforts.

@markcmiller86, @brugger1 Based on this information, it seems the format's constructor is called anew for a 'reopen'. If this is indeed the case, I don't think it would be possible to store any more information in the format regarding it's instance's read options, even if associated with a filename. That would have to happen where the options are saved and sent to the format.

[markcmiller86]

Yeah, so I wasn't sure what a VisIt Reopen operation is. Is there anything that goes on during a Reopen that is not the equivalent of a Close followed immediately by an Open of the same database?

[markcmiller86]

@iulian787 and @markcmiller86 will work to fix this for 3.4.2

[markcmiller86]

@vijaysm and @iulian787 I am running into some conceptual challenges here. And, I am wondering if we're really using the read options in the way they are intended. I think the need to switch back and forth between the cases is what is puzzling me a bit.

In order for read options to have any effect, a database must be opened (or reopened). I can kinda sorta achieve the "switching" behavior you describe on a single database if I do the following steps...

1. Select MOAB plugin in Open file as type pulldown of File open window.
2. Press Set default file open options button bringing up Default file open options for MOAB reader window.
3. Select various options and hit the ok button.
4. Open a MOAB file and draw a mesh plot.
5. Repeat steps 2 and 3 except selecting different options and then hit the Reopen button. That has the effect of quickly switching the currently plotted mesh plot to match whatever the most recently set MOAB options are.

One observation just in the above use case is that it is not as easy as it could be to just adjust options and re-open. Thats because when the options window is open, VisIt cannot take input gestures from anything else. One must hit the ok button there, closing the options window, before the rest of the GUI is again active. So, to switch things quickly, it involves a cycle of hit Select default open options (bringing up the options window), adjust options, hit ok (closing the options window), hit re-open. If the options could remain open throughout this cycle, that would be easier.

Next, if I am going to engage in this process with more than a single database, it gets a tad trickier because only the last options setting are remembered. So, if you want to change the Active source during a switch cycle, you won't be presented with the options used the last time that source was opened. You will see the options used the last time the options were set for any sources. But, if we make it somehow remember options used for each source, I am not sure how much this improves the process of switching.

So, I am wondering if a better solution to this whole thing is to NOT use Database Read Options and instead publish in the VisIt GUI menus various versions of the mesh. Or, create an enumerated scalar subsetting variable that allows you to specify which elements you want to see.

Going the GUI menu approach, you would publish mesh names like....

• mesh/points
• mesh/edges
• mesh/faces
• mesh/solids

For all those cases that the currently active database actually supports. If the current database doesn't, for example, support any edge elements, you would NOT publish mesh/edges. Then VisIt calls avtMOABFileFormat::GetMesh(...) and the mesh name is mesh/edges would you know that the plugin needs to interrogate the MOAB instance and return the edge elements.

Alternatively, you would only publish mesh but define an enumerated scalar subsetting variable maybe named ElementTypes. A call from VisIt to avtMOABFileFormat::GetVar(...) for ElementTypes would return a field defined on all the different elements (point, edge, face, solid) elements in the MOAB instance with a value of say 0 for the point elements, 1 for the edge elements, etc. Then, when a user goes to the subsetting window and selects from the ElementTypes subset, solids, they would see only the solid elements of the mesh.

I think either of the above two approaches is a preferred approach to handling all the different ways MOAB can load up a mesh instead of via read options.

Thoughts?

[markcmiller86]

For an example of switch between options with multiple databases, see...

https://github.com/user-attachments/assets/66832d93-7e0f-4408-a430-df9ee500a338

[vijaysm]

@markcmiller86 Thanks for the detailed explanation. Yes, I am aware of the difficulties in this workflow since I go through it almost every day (and perhaps have gotten used to the approach at the moment!). However, I like the suggestion to use the publisher model that queries the database for available entities and exposes only those. This way, the subset selection can be made simultaneously i.e., one could visualize volumetric and say edge fields simultaneously instead of opening multiple visit instances (which is what I do currently).

I also want to point out that in the video, around 45 seconds, when you select the "Edge" for the 3D database, there isn't any available "explicitly". One could create the edges for the 3D mesh by generating the adjacencies as needed. Still, we do not modify the in-memory database and only expose what is available in the mesh loaded from the disk.

[markcmiller86]

We met and concluded the modification of VisIt's database read options is not the right solution to the issues presented. We will leave the read options in place as is for now but agree that handling MOAB's element-rank meshes will be done via multiple menu entries. That is, of a MOAB database is opened with 0-dimensional and 2-dimensional entities, two meshes will be defined to VisIt. Variables will be associated with their respective meshes. A variable, foo, defined on 1-dimensional entities will be available in the Pseudocolor menu, for example, as Psuedocolor->foo->edges. A variable defined on all dimensional entities (e.g. global ids), will wind up having four entries in the menu...

• Pseudocolor->foo->points
• Pseudocolor->foo->edges
• Pseudocolor->foo->faces
• Pseudocolor->foo->volumes