Curves are not really treated like other meshes...but they should be

[markcmiller86]

Is your feature request related to a problem?

Ordinarily, in a 2D or 3D mesh, we have both nodes (points) and zones (cells or elements). And we can have mesh variables that are node-centered (e.g. associated with each node) or zone-centered (e.g. associated with each zone).

Curves are (or rather they should be) treated like any other mesh...just a special case of a mesh in 1 dimension. Because they are one dimesional, we needn't worry about UNstructured vs. structured topology. We can just think of it as structured...rectilinear in fact. And we do use vtkRectilinearGrid objects to implement them internally in VisIt.

But, we don't support zone-centered quantities on curves. At least, not that I can tell. If I try to plot zonetype(<somecurve>) expression, VisIt cores. I believe because its not expecting to have to plot something that is not node-centered for a curve. Now, zone-type for a curve might be boring but it is also valid and we can't do it.

I was trying to do revolved_volume() for a curve. Its a minor swizzle on existing code for revolved_volume. But, the result also is zone-centered. We also can't do Lable plot or FilledBoundar which, again, might be somewhat boring but are valid. How about a contour plot of a curve...which would produce a bunch of points where the curve passes through the specified value(s) and IMHO a pretty useful thing...especially being able to compute with precision (e.g. mid-zone) the x-values of those crossings.

For curves consisting of high order elements, I think the value in treating them like real meshes is even potentially more important because the cases get more interesting.

I suspect we have a ton of special-case logic to single out curves and treat them like second class citizens in various places and/or can easily crash if someone does the "wrong" thing with a curve. Unifying things would likely simplify logic and reduce code and improve robustness.

[markcmiller86]

I've been thinking more about this and something else occurred to me. What really is a Curve plot? How is it constructed? How is it like or not like other things we do with other dimensionality meshes?

Using parlance we use elsewhere in VisIt, a Curve plot is pretty much just an Elevate operation applied to an otherwise ordinary 1D mesh...where we use a field (mesh variable) as to influence geometry of the shape being drawn.

In general, curves can have more geometric dimensions though too. We don't really support that either. Well, 3D lineouts are kinda sorta the simplest form of something like that.

But, we can envison paths (a bunch of connected lineal segments) in 2 and 3 dimensions (engineering users do this a lot I think) upon which fields are defined. Those can be handled in VisIt but they are treated as meshes not curves. They are topologically one dimensional but geometrically higher than one dimensional. But, we cannot plot those using the curve plotting idea either where we'd use distance (or some other parametric measure) along the path for the x-coordinate and then a field value for the y coordinate.

Think of a 2D equivalent of the above...it would be a surface embedded in 3 dimensions. We can indeed plot such a thing in VisIt but only its 3D expression. To plot it as just a 2D object, we'd need to Project it. But, that would only work if there was a plane of projection for which the embedded surface didn't overlap in the projected domain. If we had a 2D parameterizition of all points on the surface, we can use that as the way to make a 2D plot of it without needing a projection operation. This is just like the idea of plotting a path as a curve where x is distance along the path except generalized to 2D.

[markcmiller86]

We should be able to do a Mesh plot of a curve. That might sound boring...at first...because its just a line (with maybe dots where segments join). Well, not if you think of curves as paths. In 2D a mesh plot of a curve overlayed with a related dataset would plot the path of that curve through the 2D topology of the dataset, showing the user where the two overlap. That seems very useful...even if the "curve" was just a line through the 2D data.

[JustinPrivitera]

I ran into several curve-related issues recently in my work on #18576. The problem I had is that I was handing the Blueprint plugin a 1D mesh with zone-centered variables defined on it. It went ahead and converted that to a VTKRectilinearGrid. At some point in the process, VisIt decided that it didn't like this, and it did the following:

adding field vars for mesh
End avtBlueprintFileFormat::PopulateDatabaseMetaData
Re-interpreted 1D avtScalarMetaData "mesh_spectra_topo/intensities_spectra" as avtCurveMetaData "Scalar_Curves/mesh_spectra_topo/intensities_spectra"
Re-interpreted 1D avtScalarMetaData "mesh_spectra_topo/path_length_spectra" as avtCurveMetaData "Scalar_Curves/mesh_spectra_topo/path_length_spectra"

I believe this is done here: https://github.com/visit-dav/visit/blob/3.3RC/src/avt/Database/Database/avtDatabase.C#L1333
It went ahead and hid my variables and tried to reinterpret them as curves, which resulted in a crash, I believe because the variables are zone centered.

To solve these problems, I ended up needing to write a bunch of custom logic for the blueprint plugin to detect 1D meshes and interpret them as curves for visit, and do stair-stepping if they are zone-centered.

---

Curves are (or rather they should be) treated like any other mesh...just a special case of a mesh in 1 dimension

I would like this very much... if it was possible to just have curves be treated the same as everything else, and to be handled further down the pipeline (ideally outside of individual plugins) this could simplify things.

I suspect we have a ton of special-case logic to single out curves and treat them like second class citizens in various places and/or can easily crash if someone does the "wrong" thing with a curve. Unifying things would likely simplify logic and reduce code and improve robustness.

+1

---

At the very least, what might be helpful would be if VisIt could take zone-centered 1D meshes and properly stair-step them automatically, instead of printing a stack trace. It may also be nice if VisIt didn't hide 1D meshes when reinterpreting them as curves, but instead allowed users the option to look at their 1D mesh any way they want.

[markcmiller86]

At the very least, what might be helpful would be if VisIt could take zone-centered 1D meshes and properly stair-step them automatically, instead of printing a stack trace. It may also be nice if VisIt didn't hide 1D meshes when reinterpreting them as curves, but instead allowed users the option to look at their 1D mesh any way they want.

👍🏻

[biagas]

@JustinPrivitera Did you experiment with commenting out the call to that function and see how VisIt treated your 1d mesh?

visit/src/avt/Database/Database/avtDatabase.C

Line 1307 in c1f186e

Convert1DVarMDsToCurveMDs(md);

[JustinPrivitera]

@biagas

mesh plot:

pseudocolor plot:

[JustinPrivitera]

When I uncomment the scalar data to 1d curve conversion but leave my blueprint 1d curve logic commented, I get a proper render of vertex-centered curves, and a stack trace when I provide a zone-centered curve.

[markcmiller86]

I believe I may have created many of the issues we face with curves today by having taken the approach of treating a Curve object as a vtkRectilinearGrid where the Curve coordinates are always in the grid's Xcoords and the Curves values are always in the Ycoords. Thats just plain wrong. And, it prevents a Curve from being treated like we treat any other mesh where the coords are the coords and the values are in points or cells data.