Variable sum of mesh_quality/volume is wrong.

[brugger1]

Describe the bug

Perry Chodash reported a bug where the Volume query and a variable sum of mesh_quality/volume reported different values. They should be the same. I have his data. It is located in /usr/workspace/brugger/chodash_bug_2019_11_15 on the RZ. He selected out material "sample_material". When I did a Volume query I got 5. When I did a variable sum of mesh_quality/volume I got 4.5...

The object is a rectangular solid made up of hexs that is 0.2 x 5 x 5, which gives a volume of 5, which is what the Volume query gives. Looking at the pseudocolor of mesh_quality/volume I see variations in value where I don't expect it. In particular, it is a pretty regular mesh, made up of about 5 sheets of zones in the thin direction. So, I suspect the result of the mesh_quality calculation is incorrect and not the variable sum.

Impact

• [X] High - User productivity significantly degraded

Likelihood

• [X] Medium - neither low nor high likelihood

[rusu24edward]

Some zones have inconsistent coloring in mesh_quality/volume, but this only happens when Sample Material is selected. Without that material explicitly selected, the zones are not miscolored (verified with zonal pick). @markcmiller86 and I investigated the possibility of there being mixed-materials. There indeed mixed materials, but surprisingly not in the zones that are getting miscolored.

Current questions are:

1. What do the miscolored zones have in common?
   • Some suspicion that they have nodes on domain boundaries, causing the volume calculation to fail.
2. What do the miscolored zones have in difference from the correct zones?
3. What does mesh_quality/volume do differently than the volume calculation?

[rusu24edward]

Both variable sum and mesh volume go through avtVerdictExpression. Still digging to see why they produce difference answers.

[biagas]

You might want to check the two swizzles on VMetricVolume: Sum only positive volumes (default false) and Use Verdict Hex (default true)

'UseVerdictHex' to allow a different form of hex-volume calculation. Requested by a customer a long while ago. Captured by a 'volume2' expression, which I think is undocumented.

[rusu24edward]

I believe there is something happening with the material selection that is resulting in the mismatch between calculating volume by (1) summing over the mesh_quality vs (2) directly taking volume of the mesh. When all materials are selected, the volumes match. Even when picking a "miscolored" cell with all materials, the volume of that cell is exactly as we expect. However, when selecting only the sample material, the volumes don't match and the cell seems to collapse to 0 volume.

I think this is further enforced because when all materials are selected, there are only hexes in the mesh, but when the sample material is selected, we see tets, pyramids, wedges, and hexes. This becomes a little strange when we see that both ways of calculating the volume still go through the same code, and with a little debugging I've found that they have the same number of tets, pyramids, wedges, and hexes.

How can it be using the same code but producing different results? Maybe the "inputs" are different in the two cases? I'm exploring this now.

[rusu24edward]

The volume of each cell is the same in both volume calculations... Looking to see if there is a bug in the sum.

[rusu24edward]

The difference in the calculations is caused by the sumFromOriginalElement flag. When calculating the volume from mesh_quality/volume, this flag is true. When calculating the volume from the mesh, this flag is false. @biagas it looks like you added this. Can you provide insight here?

[markcmiller86]

This probably has to do with arbitrary polyhedral cases...where we have arbitrary polyhedra in the input mesh and those get decomposed into zoo-type elements (tet, wedge, pyramid, hex). When this happens, things like "volume" of a zone need to deal with summing up the individual pieces to report the correct volume for the original arbitrary zone type.

[rusu24edward]

I was able to duplicate this with our own data in #4156. It seems to me that the sumFromOriginalElement flag is the cause of the incorrect results.

[rusu24edward]

This probably has to do with arbitrary polyhedral cases...where we have arbitrary polyhedra in the input mesh and those get decomposed into zoo-type elements (tet, wedge, pyramid, hex). When this happens, things like "volume" of a zone need to deal with summing up the individual pieces to report the correct volume for the original arbitrary zone type.

@markcmiller86 This seems to happen when selecting material. The original mesh (which is all hexes) is decomposed into zoo elements (see above comment). However, it looks like there may be something wrong with the logic surrounding sumFromOriginalElement. The examples that I've produced so far only show cases where using sumFromOriginalElement is the WRONG thing to do. Do you know of any cases where it is the CORRECT thing to do?

[markcmiller86]

I think we may need an example where we have arbitrary polyedra and mixing materials. I honestly don't know whether we have data of this ilk. We can make some. I honestly don't know how well this particular combination of things is handled everywhere in VisIt. I suspect it isn't too common and that we don't handle it well everywhere.

I think the case you have is mixing materials and so when any materials are turned off, VisIt does Material Interface Reconstruction (MIR) and that means breaking mixing cells into pieces that are homogeneous in material and so somehow gets into this sumFromOriginalElement behavior.

Can you give me (miller86) the example data your are playing with?

[rusu24edward]

Can you give me (miller86) the example data your are playing with?

I reproduced it in #4156 with our own data which demonstrates the problem. I will also give you the users data on RZ, but I believe both examples show mixed-materials and not arb poly.