Better Material/Slideline Organization

[JustinPrivitera]

[markcmiller86]

Because engineering doesn't use mixed materials, we have no obligation to serve up material data from Mili as avtMaterial data. We could, instead, serve up as enumerated scalar. The reason this could be a good idea is that there is functionality for hierarchical data in enumerated scalar (parent-child relationships). That said, we don't have any cases that test that and there may be some bugs or missing iimplementation in it.

But, my first advice would be to adjust Mili plugin to server up material data as enum scalar with hierachy and see what we get or still need to do to make work properly.

[brugger1]

Mark is going to investigate the effort involved.

[brugger1]

Kevin Durrenberger is looking into creating a class in the mili file that groups the slide lines so that we can group them in the interface. Right now they are just additional materials in the material list, so we don't actually know they are slide lines.

[markcmiller86]

Kevin Durrenberger is looking into creating a class in the mili file that groups the slide lines so that we can group them in the interface. Right now they are just additional materials in the material list, so we don't actually know they are slide lines.

It isn't entirely clear to me why Mili itself requires modification. I mean, if that is really what Kevin wants to do, great. But, I suspect he can achieve what he needs to by adjusting the Mili plugin, possibly creating an enumerated scalar in the plugin for slide lines.

I mean, if the plugin is already doing something with slide lines and we just don't like specifically what it is doing, we can solve that by changing the Mili plugin itself...not the Mili library. Or, maybe I am misunderstanding.

[brugger1]

When we looked at the file created by makemili the slide surfaces were only listed under the materials and there was no way to tell that they were slide surfaces. I believe that is why he wanted to modify Mili to tag those and then the plugin could serve those up differently.

[markcmiller86]

Ah, ok. So, the json bootstrap makemili is producing isn't distinguishing slides from other stuff.

On the VisIt side, we should probably support as enumerated scalar.

On the makemili json side, maybe its enough just to adopt a conventional naming for slide type entries.

[brugger1]

@durrenberger1 mentioned that having the codes change how they are outputting slide line names will be quite a bit of work and that going with the solution the @markcmiller86 suggested to modify the mili reader to change the names so that they display properly is probably the best solution for now.

[durrenberger1]

As I am working through this and marking the slide surface I am not sure what would be best for Visit. To be honest, The slide surfaces are just materials. They should have been "parts" but that may happen some time in the future. As Visit reads in the elements it will need to check if the element is defined as being part of a slide surface or not. As we cycle through the classes around approximately line 1074 in avtMiliFileFormat.C. I can provide a marker via makemili_driver for the materials to mark them as surfaces and whether they are master or slave. I would not want to start listing the cells in the json file as it can become a database size read upon init and we are trying to avoid that.

[JustinPrivitera]

Notes from 09/12 discussion:

• It would be nice if the s_* slideline information was turned off by default. There can be up to 300 of these. Users have to turn these off manually each time. Maybe we should do this instead of thinking of other ways to organize.
• A python script or external file would be nice, but it is annoying to have to bring them around.
• It would be interesting if we could store information in config file that tells the mili plugin how to turn things on and off.
• Could we put information in the Command window with a new startup tab that can get run when we start up?
• Other food for thought: https://visit-sphinx-github-user-manual.readthedocs.io/en/develop/using_visit/CommandWindow/Macros.html
• A python script that acted in a manner similar to the config files would be ideal. Config file references a python script like a startup script location.
• I think the Command window is the way to go here. I will discuss with other @visit-dav/visit-developers members.

[markcmiller86]

There is a way to hierarchically organize the members of an enumerated scalar. So, for those 300 slide lines, if they have some hierarchical organization, that can be represented in the enumerated scalar. Then, when you turn things on and off, you can turn whole groups of slide lines.

Can the python script be stored in the Mili database?

I think the Mili header (json) file could be used to capture some of the default settings you may seek. It would be up to either data producer or maybe Mili library developers to offer a means to do that.

[JustinPrivitera]

If you think there is a good way to introduce more organization for this then I think we should go ahead with that.

The discussion today centered mostly around the difficulty with turning off everything that they want to turn off, and that it would be nice if things could be automatically off based on some kind of configuration file or script that VisIt reads. Maybe the best thing would be for the data producer to put something in the Mili header, or we could write up a simple script to turn off subsets of the data that are not wanted and have them paste that into the command window each time. I think it's worth discussing this more generally with the whole team because our combined knowledge base is greater than my own.

[markcmiller86]

We won't adjust current Mili plugin variables for handling materials. We'll leave them as avtMaterial (for now). But, we can investigate crafting some python VisIt macro code that is generalized enough such that each user could pass an argument and have it produce the SIL restriction each user wants.

[cyrush]

We will work to provide a macro that simplifies turning off groups of slides by name.

[markcmiller86]

Understanding that we'll handle this with one or more macros, I just wanted to add an extra note here and that is, we don't have a SIL selection "stack" (like we do have for views for examle) or a set of named SIL selection configurations. If we did, we could do things like have SIL selections read from a database, stored in a settings file, etc.