Consider reversing roles of primary and secondary variables in IntegralCurve operator

[markcmiller86]

Suppose you do a Pseudocolor plot of something using IntegralCurve operator. The way you do this is go to Plots->Pseudocolor->Operators->IntegralCurve->some vector var.

The some vector var variable that is chosen does not actually impact any of the coloring of the Pseudocolor plot. It impacts the plot's geometry. It defines the pathline(s)/streamline(s) that will be computed by the operator.

The coloring in the Pseudocolor plot is effected by the IntegralCurve operator's Data value setting in the Appearance tab. Its default is Absolute time. Now, that isn't the plot's time in the time-series. It is the IntegralCurve operator's internal notion of time as is used to advect/compute the streamlines.

The way to get this kind of Pseudcolor plot to color the plot by a database variable is to choose Variable as the Data value of the IntegralCurve operator and then to select a database variable. But, this variable, once selected is not the plot's primary variable. So, I can't for example, go to the Variable menu pulldown and select a different primary to plot like I can with any other plot. If I do, the plot will fail. Because when I do, that changes the some vector variable the IntegralCurve operator is using to compute streamlines.

Compare this with something like threshold operator. That operator computes a new geometry too. Its default behavior is to threshold the primary variable that is determining the Pseudocolor plot's color. But, you can select other variables to threshold with and they become secondary variables. The primary which still control's the plot's coloring can be changed. from the Variable pulldown.

When I want to export a database with threshold applied, additional variables exported in that case are run through the pipeline as the primary variable as if those variables had simply been plotted by the user "nornally". But, I don't think we can do that with IntegralCurve operator because it is the "Data value" variable that needs to be updated to have the comparable effect.

So, it feels like the role of the primary variable and the Data value variable in IC operator should be reversed so that what you pull-down to plot in the Pseudocolor menu is Operators->IntegralCurve->some scalar var and then IntegralCurve either looks for a corresponding vector variable defined on the same mesh as some scalar var and/or requires user to specify what that vector variable is to drive the computation of the streamline/pathlines.

@ARSanderson probably has some thoughts about this.

[cyrush]

@markcmiller86 I agree this is confusing.

The problem is that the IC operator is creating a new variable, you are plotting the result of the IC operator whatever it is. It can be integration time like you said, which has no relation to any of the scalar vars that you could select from the mesh. Basically, the IC operator result is like an implicitly named expression result with a funny name ("operators/IC/vector_field").

Unlike DeferExpression you can't ask VisIt to execute the IC operator even if it's not the primary variable plotted by the PC plot.

This is a problem for all of these type of operators, the IC curve is just the most prominent case.

I do think it would be good for the IC operator to be able to select the vector field in its UI. That is the other purpose of the funny implicit name.

[markcmiller86]

The problem is that the IC operator is creating a new variable

I am not sure I follow. I mean, there certainly is not any new variable in the menus. And, if the Data Value that is plotted is indeed a database variable, then all the IC operator is doing is generating new geometry upon which to paint the selected, pre-existing database variable. And, in that case, I don't see any difference between it and something like threshold or iso-surface...geometry construction is driven by one variable and color by another.

Now, it turns out many of the options IC operator offers in the Data Value pull down are indeed new variables in that they have something to do with IC operator internals or something and are not seen anywhere else and so do indeed represent a non-variable. I hesitate to say new variable because its existence is unknown anywhere external to the IC operator itself. It cannot even be exported I don't think for example. I even wonder if many of the options provided here are in fact debugging options to help debug the IC operator itself and are rarely, if ever, used in actual practice.

So, here is what I think might be better behavior. When user does a PC plot with IC operator, the variable the user selects in main menu pull-downs determines the color of the plot. It is the primary variable.

• If the selected variable is a scalar variable, then what should happen is the color gets driven by that variable and the streamlines get driven by the divergence of that variable.
• If the selected variable is a vector variable, then what should happen is the color gets driven by vector magnitude and the IC operator's streamlines get driven by the vector field itself.
• If the variable is a tensor variable, follow option in bullet 2 above using the tensor primary axis.
• Alternatively, we decide not to permit non-scalars anywhere in PC plot pull down menus and so only the behavior in bullet 1 is allowed. To change vector field driving streamlines, user must bring up the IC operator attributes and select it.
• The above represent default behaviors. The user can of course bring up the IC operator attributes and adjust the field used to drive computations of the streamlines. The user can change the variable driving the coloring following same processes used everywhere else.
• In particular, to export a number of variables onto the IC operator's geometry, they would simply get added to the list of variables in the export db. Presently, there is no way to export multiple variables with an IC plot because of its current design.
• to support the internal variable options currently provided for in the IC operators Data Value pull down (if these indeed are not solely for debugging), these become operator-defined expressions like any other similar expression.
  • For example, Absolute Time is indeed an expression variable whose definition is perhaps such that it is only an option for the IntegralCurve pull down.

The above behaviors identically and in particular the sense of primary and secondary variables are IMHO much more consistent with rest of VisIt and similar operations.

[cyrush]

Again, I think this is confusing. The "new" variable is the funny name you have to pick, that includes the vector field. This funny name is problematic in other cases as well (DataBinning), b/c you can't nest operators given the funny name. But the primary field of these type of operators is the funny named thing (they also make new meshes, etc) -- but that is why they are different than other operators. The funny name is the new field after the operator. It can be exported, however there might be brittleness there. If you selected abs time, it will be the "funny" named field in an exported VTK file.

Many of these special fields are important properties of the streamlines, not just for debugging. They convey new info that helps you understand the streamlines. Interpolating the original field is only one useful way to color them. I don't know of UI way to really have folks select these streamline specific cases, bending it to do so will breaks our UI construct.

When a user is looking for streamlines, the main input they are trying to explore is a vector field.

I don't think having the streamlines be calced on the divergence of the input scalar is an expected use case -- why not the gradient? I also don't see a special case for input tensors as intuitive.

Users don't think about streamlines of a scalar field, or streamlines of a tensor. What do those constructs really mean? We can define them, but I don't think that helps make it easier.

For non-vector-at-the-start use cases, better to let the user create an expression for the vector field they want the streamlines of.

When we had the Streamline plot, it was much more initiative b/c you made a streamline plot of a vector var.

Another aspect:

Creating an expression fits best with our pipelines when we want to create new vars. In the case of connected components, it is simple enough to be defined as an expression, (input mesh and a few options are passed) -- using the Connected Components Operator isn't really a good option.

In the case of IC, there are many many many many options, we couldn't or wouldn't want to specify those in an expression. Atts via a UI window, or Python are much more tractable.

[markcmiller86]

Again, I think this is confusing

Hmm. I think I may be confused becuase I don't honestly know what this in the above statement refers to. And, I worry you may have missed my main point.

1. I find it confusing to be doing a PC plot of a vector variable via the IC operator's sub-menu pulldown. Why don't vector variables appear in the PC plot's main pull-down? Because they are not scalars. But, there they are in the IC operator's sub-menu pulldown.
2. I also find it confusing that I cannot then use the Variable menu pulldown to change the coloring variable I have plotted in a resulting PC plot created through the IC operator's sub-menu pulldown. Try it. It will result in an error and red plot. Everything else works that way ok.
3. I find it confusing that I have no idea where to go to control coloring of an IC operator created PC plot and I find its default coloring to be wholly unrelated to the variable I actually pulled down to in the menus when creating the PC plot to begin with.
4. I find it even more confusing that I cannot list multiple variables in the export db involving such a plot and have VisIt export them on the IC operator created geometry.
5. I find it confusing that if the special fields internal to IC operator are useful, that none of them are available outside of it. I can't create expressions involving them. I can use them only to drive coloring of the IC operator.

IMHO, this is all because the IC operator is treating the pulled-down (e.g. ordinarily the primary variable in a PC plot and the variable that controls PC plot coloring) as something else. Its just backwards. And, all this will remain true regardless of the other aspects you mention and regardless of whether by default we can do something sane with atypically typed variables (scalars or tensors) which is really orthogonal to this whole discussion.

Don't wanna handle tensors or scalars as proposed? No problem...I included only because as currently designed we are handling vector variables in the PC plot pull down which is by itself IMHO confusing. How does a vector variable map to a color? In the past (and perhaps even now in the code), we've arguded that doing a PC plot of a vector should maybe implicitly mean to color by vector magnitude. So, the default behavior I proposed for tensors and scalars was merely to remain consistent with that. If not desirable, ignore those aspects of what I was describing. They are not really relevant to the core issue. Side Note: IMHO, having something behave sanely by default is a good practice, even if it isn't necessarily a common case. I view treating non-standard variable types (e.g. scalar or tensor) in a sane way if they ever happen to be attempted as a way of improving user experience. Also, sorry, I did mean default to using vector field of gradient and not divergence for scalar inputs.

[cyrush]

this == "IC" operator and these style of operators. The same applies for all of them, an actually it can be more confusing for some: Input variables have no meaning for some operators (CCL, some cases of IC, data binning).

[ARSanderson]

Hi,

A few thoughts that are a tangent but addresses some of the issue. Why do we have separate plots for scalar, vector, and tensor data. Should there not be one plot for all? Now one may say yes as the data is different. However, I would argue is a vector glyph any different from a point glyph?? Further, within the scalar data we have points, lines, surfaces. Currently with the PS plot if one is rendering a surface the points and lines geometry UI is inactive. What if I have point data and I want to put a vector on them? I cannot do that within the PS plot. I should, should I not??

Further, there is a lot of duplicity between the three plots. Namely the data limits, scaling, and color table. Combine all that and what is left. A couple of tabs specifically for vector and tensor glyphs, add those tabs to the current PS plot and viola Mark some of your concern is solved.

That said, Mark I understand some of your other concerns. As Cyrus noted when using the integral curve the primary interest is the vector field. As such, it really is the primary variable. How it is colored is secondary. That color value maybe a variable from the data base or a value generated by the IC system. Those values are important. For instance, the Poincare operator generates many values related to the analysis.

I do agree that down stream there an issue. But I have no answer, other than to say the IC are a one off square peg/round hole.

Cheers,

Allen

Allen Sanderson SCI Institute University of Utah

[ARSanderson]

Hi,

After helping a user this past week who was having problems with the IC operator I submitted this bug report:

https://github.com/visit-dav/visit/issues/4341

Nutshell, they created a vector plot to first see their vectors, then added the Integral Curve operator. That does not work with a vector plot as the output data is scalar. They were drawing a blank on the Pseudocolor->operator->PICS->IC->variable.

In the mean time over the past two days I basically collated the vector and tensor plots. Not into one but to make them have the same functionality. Eric and Kathleen are reviewing my changes before merging them into the trunk. As I noted to Eric, with a small amount of work over the course of a day or two I could probably merge the vector and tensor plots into a single plot. There is no difference other than the glyph being used.

As such, I am going to raise my hand again to say I think it would be really good to look at having one plot for scalars, vectors, and tensors. There is so much overlap now.

I think going forward there are going to be more operators the change the data type and trying to do the plot->operator-> thing is going to be a bane. especially as it adds additional menu items.

Cheers,

Allen

On Dec 5, 2019, at 5:13 PM, Allen Sanderson allen@sci.utah.edu wrote:

Hi,

A few thoughts that are a tangent but addresses some of the issue. Why do we have separate plots for scalar, vector, and tensor data. Should there not be one plot for all? Now one may say yes as the data is different. However, I would argue is a vector glyph any different from a point glyph?? Further, within the scalar data we have points, lines, surfaces. Currently with the PS plot if one is rendering a surface the points and lines geometry UI is inactive. What if I have point data and I want to put a vector on them? I cannot do that within the PS plot. I should, should I not??

Further, there is a lot of duplicity between the three plots. Namely the data limits, scaling, and color table. Combine all that and what is left. A couple of tabs specifically for vector and tensor glyphs, add those tabs to the current PS plot and viola Mark some of your concern is solved.

That said, Mark I understand some of your other concerns. As Cyrus noted when using the integral curve the primary interest is the vector field. As such, it really is the primary variable. How it is colored is secondary. That color value maybe a variable from the data base or a value generated by the IC system. Those values are important. For instance, the Poincare operator generates many values related to the analysis.

I do agree that down stream there an issue. But I have no answer, other than to say the IC are a one off square peg/round hole.

Cheers,

Allen

Allen Sanderson SCI Institute University of Utah

[markcmiller86]

If there is a lot in common among the three types of plots, that is definitely an argument for finding some way to implement them with shared code but not necessarily an argument that they should also be collapsed to a single uber plot type in the user interface.

Currently, the way plot plugins work, I am not sure there is a way for them to easily share common pieces. Maybe being able to have plots plugins inherit from each other? Maybe a layer just above plot plugins into which common sub-pieces can go (bg/fg color selections, color table selections, glyphing type selection, glyph sizing controls, glyph features, wireframe, geometry smoothing) would help to reduce code duplication?

At any rate, I think @ARSanderson is making a software engineering argument to suggest a change in the user interface and I just want to raise the observation that I think these are two separate issues. @ARSanderson which is more important to you...reducing code duplication (e.g. the software engineering) or changing the user interface, or both?

[ARSanderson]

Mark,

Good observations. IMHO, both are important. From the code side the maintenance gets more involved. For instance, in the Pseudocolor plot Kathleen implemented the option to color values outside the min/max. A great option that I have already made use of. Conversely, the Vector/Tensor plots have the option of a single color. Also useful. I want it all in all the plots. Setting up the GUI for all of these requires code in three places. And while we can coalesce things like this into a common GUI that makes using it a bit easier it is still needed in three places.

As for the plots functionality. From the first day I started using VisIt one of the things that has always bugged me is number of plots. Hank convinced me the reasoning and in general I see the logic. There are exceptions, for instance the contour plot is really a Pseudocolor plot with an iso-contour operator built in and a semi-hard coded color table. But the biggest exception is the Scalar/Vector/Tensor plots which in my mind all produce “glyphs" of one sort of another. And if treated that way I think it could greatly simply things without making the GUI more complex. I think it is a worthy in depth discussion.

Cheers,

Allen

Allen Sanderson SCI Institute University of Utah

On Feb 7, 2020, at 7:46 PM, Mark C. Miller notifications@github.com wrote:

If there is a lot in common among the three types of plots, that is definitely an argument for finding some way to implement them with shared code but not necessarily an argument that they should also be collapsed to a single uber plot type in the user interface.

Currently, the way plot plugins work, I am not sure there is a way for them to easily share common pieces. Maybe being able to have plots plugins inherit from each other? Maybe a layer just above plot plugins into which common sub-pieces can go (bg/fg color selections, color table selections, glyphing type selection, glyph sizing controls, glyph features, wireframe, geometry smoothing) would help to reduce code duplication?

At any rate, I think @ARSanderson https://github.com/ARSanderson is making a software engineering argument to suggest a change in the user interface and I just want to raise the observation that I think these are two separate issues. @ARSanderson https://github.com/ARSanderson which is more important to you...reducing code duplication (e.g. the software engineering) or changing the user interface, or both?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/visit-dav/visit/issues/3995?email_source=notifications&email_token=AGHBOILUW7RVJZRU2L4GPADRBYMG7A5CNFSM4JFJDCF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELFHTBY#issuecomment-583694727, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHBOINQM6D6PSGHRZEQ2S3RBYMG7ANCNFSM4JFJDCFQ.