Vector Plot yielded no data for all zero vectors

[JustinPrivitera]

Engineering users told me that they feel the warning message "The Vector plot of variable "vel0" yielded no data." in the popup window is not the expected behavior when they have a vector field of all zero vectors.

They contend that all zero vectors is still data. Perhaps we could provide a better message? Or do this ticket: #20237

For them all zero vectors is not an error state, and the warning led to confusion.

It is easy enough to reproduce this with curv3d.silo, simply create a vector expression vel0 that is vel * 0.

[markcmiller86]

I agree with engineering users. We don't say "plot yielded no data" when we plot an all-zero scalar field in a PC plot

[brugger1]

I don't have a strong opinion on whether it is confusing or not. I will note that it is a warning, not an error.

I believe it isn't the vector plot that is the source of the message. It is not creating any geometry and then some routine further down the pipeline is detecting that nothing was generated and putting up the rather generic warning.

Here are some other situations that generate the same warning.

1. Create a contour plot of "d" and specify the level to be "10.". Since this is outside the range of the data, no geometry is created and we get the warning.
2. Create a pseudocolor plot of "d" and apply a threshold operator with the range 6 - 10. Since this is outside the range of the data, no geometry is created and we get the warning.

The issue may be that the message is too generic, perhaps a warning that the field is zero would be better in the case of the vector plot, that the contour level is out of range with the contour plot and that the threshold range is outside the range of the data. This would be much more work, but might be more satisfactory.

Just my 2 cents worth. I have no puppy in this fight.

[markcmiller86]

I wonder if it is worth drawing a distinction between a user inputting some controls that cause a plot to "go blank" versus the input data itself just being that way. So, if a user sets a control that causes no-contours, or no mesh, or disables all SIL subsets, then they probably did NOT intend that and producing an actual in-your-face warning about it may be is the right thing to do.

But, when a user plots stuff, changes time steps, etc. and the stuff alone (without any new inputs from the user) creates that condition, I think an in-your-face warning is perhaps not right. I think having some indicators in the plot window's legend for that particular plot may be the right thing.

All that being said, what is the difference between a PC plot of all zeros and one of all twos? In both cases they are constant valued. Is having a constant valued variable a warning-worthy kind of thing? I don't think it is. Specifically for glyphed plots (tensor, vector, etc), all zeros create a no-geometry condition (e.g. no data) whereas other all constant values do not.

[brugger1]

Making a distinction between changing an operator or plot value leading to the warning versus changing the time step sounds like a great idea. I've run into that before with making movies. Usually it was an error and it stopped the movie making from progressing. I don't know if this warning would result in the movie making from stopping. Some amount of history would need to be stored to allow that type of behavior (which could be as simple as a flag that says the time state was changed).

I do believe in the case of movie making having data that stops the movie generation or generates a frame wildly out of sync with the surrounding frames is super annoying.

Regarding various error states. Here are some use cases. The first two provide an indication in the legend (the pseudocolor plot is in your face, without even looking at the legend). The last two, there is no indication in the legend, but they did select values for some of the attributes that were non-default, so perhaps they would realize that might be the cause.

1. Pseudocolor plot with a constant value. Very obvious.
   
2. Vector plot with all zero values. Semi obvious.
   
3. Contour plot with out of range level. Not very obvious.
   
4. Pseudocolor plot with threshold operator with out of range range. Not very obvious.
   

[JustinPrivitera]

The right answer for the engineering folks might be to just disable warning message popups. I will check with them and see if that is sufficient. But I think there are good thoughts captured in this ticket about how to better inform users what is happening.

[markcmiller86]

Some other ways to generate what appear to be "empty plot" conditions...

• mesh plot where mesh color is same as (constant) background color (probably accidental)
• Turning off all sets in SIL (probably accidental)...this does generate the PYND warning
• Setting Image zoom in 3D view controls to some really small value or Image pan to some big value (probably accidental)
• Applying a Transform operator which has effects of translating or scaling object out of view
• Setting Font scale to zero in Label plot
• Doing a Molecule plot without apropriate database (still get valid colors and min/max in legend)
• Setting Psuedocolor plot min/max to same value...generates a warning and totally blank viewer and a red plot in the plot list but otherwise executes the plot.
• Setting stride on Vector plot to zero...no warning or anything else
• Setting Samples per ray to 1 for Ray casting: compositing renderer in Volume plot.

In walking through this exercise, I am reminded that we already have a mechanism for indicating if a plot is in a bad state...the coloring of the plots as they appear in the plot list. I think we've all seen that as sort of only about execution of the plot and not the plot's overall health.

So, we have these options for communicating to the user that there is a potential problem.

• Coloring of item in plot list
• Rendered indications in the main window (which could even include annotations on the legend or in the body of the plot)
• In-your-face warnings

[markcmiller86]

I guess another reason for listing all those cases (and I could easily list a bunch more) is that detecting all the ways a user could cause the tool to display a blank plot just so we can say "hey, there is no data...maybe you did something wrong", seems like a big ask and not necessarily the best use of resources. And, of course, we do not currently do that for the overwhelming majority of cases which are concievably as likely as the other cases we currrently do actully get that right.

Experimentalists don't expect their oscilloscopes to warn them about bad settings preventing them from seeing their data.

[cyrush]

One idea:

The legend could also show the number of zones / nodes / vectors, etc that are being plotted.

That would help folks understand if they have accidentally culled the data (w/o a pop up warning) vs just a bad view or color table.

[markcmiller86]

The legend could also show the number of zones / nodes / vectors, etc that are being plotted.

Hmmm... 🤔, what if the legend isn't currently being displayed for that plot? For plots that allow one to restrict that total number or stride through it (Label, Vector, Tensor...maybe just the glyphed plots), how is a glyph of zero size counted? Should we actually allow glyphs of zero size (I suspect they take up memory and maybe contribute to global spatial extents but do nothing else useful)? What if we are plotting point meshes and we encounter a point mesh with no points? Is that an in-your-face-warning-worthy situation? I feel like it is not.

In a movie making scenario, if we step through a time step that generates these conditions, does it wind up inserting a noticably different frame in the movie?

I do like the idea of having some way to notify a user that a plot's "health" may not be perfect. But, I am beginning to think warning popups or stuff rendered into the viewer image may not be best. I think it may be best to indicate it with color, iconography in the plot list itself...and perhaps a single green, yellow, red notifer at the top or as an outline around the plot list box. So, a red-outlined box indicates there is at least one plot in the plot list that is in an error state. Currently, we use yellow for executing. A green outline box of the plotlist indicates all plots are health. Maybe a blue or orange could be used to indicate one more plots is in a potentially funky state. Then, they can click somewhere to get more info, maybe in the output box, if they are so inclined.