visit
visit copied to clipboard
visit-dav
Better Material/Slideline Organization
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.
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.
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.
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.
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.
@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.
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.
