Mili integration point advancement

[aowen87]

At some point, we will need to let users choose which integration points are displayed in visit. Because of how the mili data is organized, accessed, and displayed, this is a surprisingly difficult task. There are some discussions on this topic in issue #3370.

[aowen87]

Originally, we were planning on using the array_decompose expression to allow users to set integration points. Unfortunately, this doesn't really work out for reasons outlined here: #3370 (comment)

Some other potential avenues that come to mind:

1. Update VisIt to allow creating mutable database expressions (able to be manipulated by users), and have the Mili plugin create mutable expressions for each available class as constant mesh scalars representing the desired integration point for that class, and the user could update/change the integration point through the expression definition. The plugin would then check the expression list to determine which integration point is desired for a given class. One downside to this is that we would be creating an entire field to represent a single variable. It also just feels like a bit of a hack.
2. Create a SetAuxiliaryData method within the database plugin infrastructure. This would be similar to GetAuxiliaryData, except it would send information to the database plugin rather than retrieve information from it. If this was in place, we could create some kind of interface that allows users to send strings of information to the current plugin to try to interpret. In the Mili case, we could just allow the same commands that are used in Griz (something like set_ipt number).

[markcmiller86]

Why not just introduce a new expression function that is similar to array_decompose except it is designed (and named) to handle integration points. The new function might be, select_integration_points(<varname>, [str0,str1,...], [p00, p01,...],[p10,p11,...]) where varname is a VisIt variable name, [str0,str1 is a list of arbitrary strings (but strings like brick, shell, etc. are recognized), and the lists [p00,p01...] is the list of integration point lists to handle on each class. if the variable is not shared, the classname arg can be "" some other proxy for don't care.

We should take care to generalize away from Mili-specific verbiage and so maybe instead of treating those strings as classnames we treat them as element type names and use something more VTK-esque or VisIt-esque such as hex (instead of brick) and quad(instead of shell -- though shell may in fact be more general because most users I believe think quad is a 2D object whereas a shell can really exist in a 3D geometric space (and has thickness).

[aowen87]

Yeah, something like that could work. It seems a bit strange, though, because the variable in <varname> would have nothing to do with setting the integration points.

[markcmiller86]

I am not sure I get that. I mean, refering to the comment you ref above, in the example of a shared variable, it would be Primal/shared/bar and then the expression would be selecting the integration points to display from this variable for each class it is defined on. In the case of a non-shared variable, it would be something like Primarl/Bricks/foo and the expression would be selecting integration points for that variable, though the syntax of the expression function for that case could be simplified a bit.

[markcmiller86]

So, the approach I suggest would get problematic if you happened to have a number of shared variables and you wanted to display them all with one set of integration points and then make a change in IPs and display them all again. That would be a lot of expression editing.

So, if we stay away from handling this in varable world and instead seek a way to handle it in mesh land, then it starts to feel much more like a SIL controls issue...to specify which "parts" (ips) of the mesh we want served up each time we request variable(s). This is more like your suggestion b above, except that it gets codified somehow in the SIL. I can't remember...did we already go down that path and beat it to death before we abandon it?

[aowen87]

I am not sure I get that. I mean, refering to the comment you ref above, in the example of a shared variable, it would be Primal/shared/bar and then the expression would be selecting the integration points to display from this variable for each class it is defined on. In the case of a non-shared variable, it would be something like Primarl/Bricks/foo and the expression would be selecting integration points for that variable, though the syntax of the expression function for that case could be simplified a bit.

Kind of, except setting the integration point for 'Primal/Bricks/foo' would actually set the integration point for all element sets belonging to Bricks, not just foo (at least that's how it's current setup in Griz world).