Vector fields not showing up as expected

[nDimensionalSpace]

Describe the bug

I have a database that contains multiple point meshes, all of which should have a vector quantity defined on them. On some of these, the vector field seems to display correctly, and on others, there is no visual representation of the vectors, even though the colorbar is displaying some non-trivial magnitude. After investigation with Silo "browser" (great tool, btw), the vector data seems to be defined in a consistent manner for both the working and non-working cases.

Helpful additional information

• Did VisIt crash: no
• Did you get wrong results: yes

To Reproduce

Plot the variables "vector/DBC/DBC1/reaction_force" and "vector/DBC/DBC3/reaction_moment" in the latest version of visit on rzwhippet.

Desktop

• OS and version: toss_4
• VisIt Version: 3.4.2
• Server info (if applicable): rzwhippet

Will post example silo database momentarily.

[nDimensionalSpace]

VisitIssue20201.tar.gz

[markcmiller86]

@nDimensionalSpace I am getting plot yielded no data with the example vectors you provided. Those vectors are all zeros.

Now, IMHO, this is another case (or maybe its the same case) of the plot yielded no data state in VisIt being a bit confusing or misleading because, for example, if this was scalar data, the all-zero condition would produce a blue plot and would not produce a plot yielded no data warning message.

I tried creating a constant vector on your dataset using expressions and plotting that variable works in the sense that I do not get the warning.

However, there is something else odd about this data set. It seems like the extents are off. It seems like the mesh is a single point. So, it has bizarre extents of essentially zero. That seems to be causing other issues in VisIt.

Can you elaborate on this dataset's "design"?

[nDimensionalSpace]

Ah right . . . The plot yielded no data business happens for state zero, please check state 1.

Grrr, if you are seeing some of the extents being incorrect, that is likely a bug on my end. I will check that out.

[markcmiller86]

@nDimensionalSpace I think we're just dealing with a corner case here. I mean, we don't often deal with meshes consisting of a single point. There is nothing inherently invalid about that but we do have a sense of spatial extents that comes into play in, for example, establishing the field of view. And, if the mesh has a single point, then its spatial extents are effectively zero. I am not sure the rest of VisIt will play nice with that..even if you have some way to try to force VisIt to use specific values for spatial extents. So, I think that is problem 1. And, I think that is then preventing it from rendering the vector field (in this case a single vector glyph), in such a way that it is visible.

If not too onerous, can you try ensuring the mesh has at least two points, maybe the same point or maybe like 1 unit distant and see if you get same behavior. I am guessing you will not.

[markcmiller86]

So, I've created a simple example of a point mesh with one non-ghost and one ghost point. It does seem to behave "better" than just having a single point.

onepoint.silo.gz

#include <silo.h>

#define STRLEN 60

/******************************************************************************
 * 
 *****************************************************************************/

int
main(int argc, char *argv[])
{
    DBfile         *dbfile = NULL;
    DBoptlist      *optlist;
    char const * const somenames[3] = {"a", "b", "c"};
    double         *coords[3];
    int             nodelist[8];
    double          x[8], y[8], z[8];
    int             shapesize[1];
    int             shapecnt[1];
    double          var[8];
    char            ghost_labels[8];
    int             i;
    int		    driver = DB_PDB;
    char 	    *filename = "onepoint.silo";
    int             ndefs;
    char            vnames[3][STRLEN], *pvnames[3];
    char            defns[3][STRLEN], *pdefns[3];
    int             types[3];
                
    /* Parse command-line */
    for (i=1; i<argc; i++) {
	if (!strncmp(argv[i], "DB_HDF5", 7)) {
	    driver = DB_HDF5;
	} else if (argv[i][0] != '\0') {
	    fprintf(stderr, "%s: ignored argument `%s'\n", argv[0], argv[i]);
	}
    }

    printf("Creating test file \"%s\".\n", filename);
    dbfile = DBCreate(filename, DB_CLOBBER, DB_LOCAL, "point mesh with one point", driver);

    x[0] = 0; y[0] = 0; z[0] = 0;
    ghost_labels[0] = 1;
    x[1] = 1; y[1] = 1; z[1] = 1;
    ghost_labels[1] = (char)0;

    coords[0] = x;
    coords[1] = y;
    coords[2] = z;

    optlist = DBMakeOptlist(10);
    DBAddOption(optlist, DBOPT_GHOST_NODE_LABELS, ghost_labels);
    DBPutPointmesh(dbfile, "point", 3, coords, 2, DB_DOUBLE, optlist);
    DBClearOption(optlist, DBOPT_GHOST_NODE_LABELS);

    var[0] = 5.5;
    DBPutPointvar1(dbfile, "v", "point", var, 1, DB_DOUBLE, NULL);

    var[0] = var[1] = 1.1;
    DBPutPointvar1(dbfile, "wx", "point", var, 2, DB_DOUBLE, NULL);
    var[0] = var[1] = 2.2;
    DBPutPointvar1(dbfile, "wy", "point", var, 2, DB_DOUBLE, NULL);
    var[0] = var[1] = 3.3;
    DBPutPointvar1(dbfile, "wz", "point", var, 2, DB_DOUBLE, NULL);

    ndefs = 1;
    types[0] = DB_VARTYPE_VECTOR;
    sprintf(vnames[0], "vec");
    pvnames[0] = vnames[0];
    sprintf(defns[0], "{wx,wy,wz}");
    pdefns[0] = defns[0];

    DBPutDefvars(dbfile, "defvars", ndefs, (DBCAS_t) pvnames, types, (DBCAS_t) pdefns, 0);

    DBClose(dbfile);

    return 0;
}

[nDimensionalSpace]

So, I added a second point to the pointmesh, with varying results, as follows:

• second point at same location as first point: no change in behavior, and
• second point 1 unit away from first point: vector shows up as expected.

Admittedly this is an edge case; usually, we would only have meshes this small for test problems. One thing I will note is that the use case for this data is to depict boundary conditions, so presumably if one used the spatial extents of the whole problem domain for the variables on this boundary mesh, that would fix the issue**.

** I am also aware that you all have a million use cases that I am not aware of, and that I may be the only person using multiple meshes in a single database, so maybe its not worth making the changes for just one user . . . Just trying to suggest something that might work, if it were possible and not too difficult.

[markcmiller86]

@nDimensionalSpace, so I agree with second point in same place...not a useful thing to do. In my example, the second point was on the opposite corner of the unit cube and then I made it a ghost node too so it doesn't plot. That seems to work ok but maybe unit distance apart is not appropriate for your case. I think anything above epsilon (say 1e-6) is probably fine.

I don't like having to jury-rig these cases with extra stuff the data producer doesn't care about. But, in the short term, it might be best we can do.

[markcmiller86]

I think the right long term answer might be that when we have something with extents < 1e-6 or something on that order, instead of continuing to try to define a view transform that scales that object, we just set a lower-limit on the view frustum size and the object may appear arbitrarily small within it causing the user to have to manually add a scale transform to fix it.

[nDimensionalSpace]

@markcmiller86: Yeah . . . Having to write out ghost data is not the greatest solution, but not super onerous either.

I should be able to grok the ghost business from your example, but if not, I will shoot you an email on the side.

🙏