Description
Hello -
I represent a team that solves topology optimization and related problems, so we frequently wish to render element-wise constant fields on meshes of various geometries. I recently heard from two team members that the default visit installation on LC (at /usr/gapps/visit/bin/visit, which is now visit 3.4.1) now renders such fields incorrectly, as depicted below, and also yields an error message. This behavior is new relative to visit 3.3, which we had been using previously (are now using again to correctly render the fields).
Here is a representation of the issue. The two images below are renderings of the same data on the same mesh, saved from MFEM as an mfem::VisitDataCollection. The only difference is that the first image was rendered using visit 3.3, and the second one was rendered using visit 3.4. The 3.3 version is piecewise constant over the elements as expected, and moreover has the expected radially symmetry (expected due to constraints in the design data before being saved). The 3.4 version is not radially symmetric, nor is the field constant over the elements - it looks, at least in places, like a C0-continuous, second order field.
Additionally, the 3.4 version issues the following error message:
which seems like it may be consistent with an expectation of a nodal (vice elementwise) field.
Another team member has seen the same effect on other meshes (which I can't share here), leading me to suspect the issue is not specific to the mesh shown here. I will ask the team member that produced the images above to provide a tarball of the data as well as a session file from visit 3.4 to reproduce the unexpected behavior.