A non-conforming mesh is a mesh where the nodes of one edge may end in the middle of another edge or face. These happen in block structured AMR meshes and in unstructured meshes being used for general adaptivity. Nodes in such meshes are often called hanging nodes. Data producers can produce continuous fields on such mesh under piecewise linear interpolation by constraining dofs on hanging nodes. However, Visit's expression system cannot, in general, reproduce this continuity for expressions involving the original continuous fields in nonlinear ways. The picture below shows the issues. Left: x (blue) and y (red) contours of continous components of a vectorMiddle: Contour plot of the magnitude of the vector as computed by VisIt's expression system.Right: Contour plot of the magnitude of the vector as computed by data producer and with same continuity constraint enforcement as in original fields, namely that the dofs at the hanging node must be the average of the dofs at the ends of the longer edge it shares. There are a couple of options... Here are a couple of options to consider going forward... Define 'constrained' nodes for a ucd var in Silo This would be an optional object to associate with a field in Silo such that it defines, for each node, whether the node is constrained in some way and, if so, the constraint expression. So, for the case you had, the constraint would look like 0.5Ni+0.5Nj where Ni and Nj are node ids in the mesh. If the constraints for all fields on the mesh would be the same, we can associate the constraints with the ucdmesh object and not with ucd vars These constraints could then be applied by any expression VisIt performs resulting in continuous fields. Create a 'conforming mesh' operator that takes a non-conforming mesh and turns it into a conforming mesh Given no information, it would have to find nodes that are "hanging" nodes and then subdivide neighoring zones to make them conforming. Finding hanging nodes might be difficult in general. So, this might require that the input mesh at least be annotated in some way to indicate which nodes in the mesh are nonconforming This already has some precedent in VisIt where, for example, we take arbitrary polyhedral zones and subdivide into zootype zones.
-----------------------REDMINE MIGRATION-----------------------
This ticket was migrated from Redmine. As such, not all
information was able to be captured in the transition. Below is
a complete record of the original redmine ticket.
Ticket number: 2899
Status: Pending
Project: VisIt
Tracker: Feature
Priority: Normal
Subject: Better support for non-conforming meshes
Assigned to: -
Category: -
Target version: -
Author: Mark Miller
Start: 08/29/2017
Due date:
% Done: 0%
Estimated time:
Created: 08/29/2017 02:56 pm
Updated: 09/19/2017 06:44 pm
Likelihood:
Severity:
Found in version: 2.12.3
Impact: 3 - Medium
Expected Use: 3 - Occasional
OS: All
Support Group: Any
Description:
A non-conforming mesh is a mesh where the nodes of one edge may end in the middle of another edge or face. These happen in block structured AMR meshes and in unstructured meshes being used for general adaptivity. Nodes in such meshes are often called hanging nodes. Data producers can produce continuous fields on such mesh under piecewise linear interpolation by constraining dofs on hanging nodes. However, Visit's expression system cannot, in general, reproduce this continuity for expressions involving the original continuous fields in nonlinear ways. The picture below shows the issues. Left: x (blue) and y (red) contours of continous components of a vectorMiddle: Contour plot of the magnitude of the vector as computed by VisIt's expression system.Right: Contour plot of the magnitude of the vector as computed by data producer and with same continuity constraint enforcement as in original fields, namely that the dofs at the hanging node must be the average of the dofs at the ends of the longer edge it shares. There are a couple of options... Here are a couple of options to consider going forward... Define 'constrained' nodes for a ucd var in Silo This would be an optional object to associate with a field in Silo such that it defines, for each node, whether the node is constrained in some way and, if so, the constraint expression. So, for the case you had, the constraint would look like 0.5Ni+0.5Nj where Ni and Nj are node ids in the mesh. If the constraints for all fields on the mesh would be the same, we can associate the constraints with the ucdmesh object and not with ucd vars These constraints could then be applied by any expression VisIt performs resulting in continuous fields. Create a 'conforming mesh' operator that takes a non-conforming mesh and turns it into a conforming mesh Given no information, it would have to find nodes that are "hanging" nodes and then subdivide neighoring zones to make them conforming. Finding hanging nodes might be difficult in general. So, this might require that the input mesh at least be annotated in some way to indicate which nodes in the mesh are nonconforming This already has some precedent in VisIt where, for example, we take arbitrary polyhedral zones and subdivide into zootype zones.
Comments:
After discussing this with Cyrus, his suggestion was that we treat an element that has hanging nodes attached to it as an aribtrary polyhedral element and then deal with it like we would any arbitrary polyhedral element, namely decompose it into ucd zoo elements. That would have the effect of taking the original nonconforming mesh and making it a conforming mesh. So, the question is, what minimal information is required for data producer to add so that such an operation can be easily implemented?For each hanging node in the mesh, the data producer is required to indicate the topological entity (edge in 2D / edge or face in 3D) it is intended to be connected with. In the example here, node 4 is the hanging node and the data producer, in addition to writing the ucd mesh and ucd zonelist, would be required to write an additional, connectivitylike, object where each hanging node is attached to its respective face or edge. If a hanging node is intended to be attached to an edge, as in the 2D example here, the data producer would have to indicate that. Likewise, in 3D, if a hanging node is intended to be attached to a face, the data producer would have to indicate that. But, in the example here, we're dealing with a case of just one level of refinement difference between neighboring elements. What if there are more levels of refinement? Then, along the long edge, there would be many hanging nodes. If for each such node, all we know is the bigger topological entity they are intended to be attached to is that sufficient?So, for the simple example here, if nodes are numbered 0,1,2 across the bottom, 3,4 in the middle and 5,6,7 across the top, the additional information looks like...
markcmiller86
commented
5 years ago 
A non-conforming mesh is a mesh where the nodes of one edge may end in the middle of another edge or face. These happen in block structured AMR meshes and in unstructured meshes being used for general adaptivity. Nodes in such meshes are often called hanging nodes. Data producers can produce continuous fields on such mesh under piecewise linear interpolation by constraining dofs on hanging nodes. However, Visit's expression system cannot, in general, reproduce this continuity for expressions involving the original continuous fields in nonlinear ways. The picture below shows the issues. Left: x (blue) and y (red) contours of continous components of a vectorMiddle: Contour plot of the magnitude of the vector as computed by VisIt's expression system.Right: Contour plot of the magnitude of the vector as computed by data producer and with same continuity constraint enforcement as in original fields, namely that the dofs at the hanging node must be the average of the dofs at the ends of the longer edge it shares. There are a couple of options... Here are a couple of options to consider going forward... Define 'constrained' nodes for a ucd var in Silo This would be an optional object to associate with a field in Silo such that it defines, for each node, whether the node is constrained in some way and, if so, the constraint expression. So, for the case you had, the constraint would look like 0.5Ni+0.5Nj where Ni and Nj are node ids in the mesh. If the constraints for all fields on the mesh would be the same, we can associate the constraints with the ucdmesh object and not with ucd vars These constraints could then be applied by any expression VisIt performs resulting in continuous fields. Create a 'conforming mesh' operator that takes a non-conforming mesh and turns it into a conforming mesh Given no information, it would have to find nodes that are "hanging" nodes and then subdivide neighoring zones to make them conforming. Finding hanging nodes might be difficult in general. So, this might require that the input mesh at least be annotated in some way to indicate which nodes in the mesh are nonconforming This already has some precedent in VisIt where, for example, we take arbitrary polyhedral zones and subdivide into zootype zones.
-----------------------REDMINE MIGRATION----------------------- This ticket was migrated from Redmine. As such, not all information was able to be captured in the transition. Below is a complete record of the original redmine ticket.
Ticket number: 2899 Status: Pending Project: VisIt Tracker: Feature Priority: Normal Subject: Better support for non-conforming meshes Assigned to: - Category: - Target version: - Author: Mark Miller Start: 08/29/2017 Due date: % Done: 0% Estimated time: Created: 08/29/2017 02:56 pm Updated: 09/19/2017 06:44 pm Likelihood: Severity: Found in version: 2.12.3 Impact: 3 - Medium Expected Use: 3 - Occasional OS: All Support Group: Any Description: A non-conforming mesh is a mesh where the nodes of one edge may end in the middle of another edge or face. These happen in block structured AMR meshes and in unstructured meshes being used for general adaptivity. Nodes in such meshes are often called hanging nodes. Data producers can produce continuous fields on such mesh under piecewise linear interpolation by constraining dofs on hanging nodes. However, Visit's expression system cannot, in general, reproduce this continuity for expressions involving the original continuous fields in nonlinear ways. The picture below shows the issues. Left: x (blue) and y (red) contours of continous components of a vectorMiddle: Contour plot of the magnitude of the vector as computed by VisIt's expression system.Right: Contour plot of the magnitude of the vector as computed by data producer and with same continuity constraint enforcement as in original fields, namely that the dofs at the hanging node must be the average of the dofs at the ends of the longer edge it shares. There are a couple of options... Here are a couple of options to consider going forward... Define 'constrained' nodes for a ucd var in Silo This would be an optional object to associate with a field in Silo such that it defines, for each node, whether the node is constrained in some way and, if so, the constraint expression. So, for the case you had, the constraint would look like 0.5Ni+0.5Nj where Ni and Nj are node ids in the mesh. If the constraints for all fields on the mesh would be the same, we can associate the constraints with the ucdmesh object and not with ucd vars These constraints could then be applied by any expression VisIt performs resulting in continuous fields. Create a 'conforming mesh' operator that takes a non-conforming mesh and turns it into a conforming mesh Given no information, it would have to find nodes that are "hanging" nodes and then subdivide neighoring zones to make them conforming. Finding hanging nodes might be difficult in general. So, this might require that the input mesh at least be annotated in some way to indicate which nodes in the mesh are nonconforming This already has some precedent in VisIt where, for example, we take arbitrary polyhedral zones and subdivide into zootype zones.
Comments: After discussing this with Cyrus, his suggestion was that we treat an element that has hanging nodes attached to it as an aribtrary polyhedral element and then deal with it like we would any arbitrary polyhedral element, namely decompose it into ucd zoo elements. That would have the effect of taking the original nonconforming mesh and making it a conforming mesh. So, the question is, what minimal information is required for data producer to add so that such an operation can be easily implemented?For each hanging node in the mesh, the data producer is required to indicate the topological entity (edge in 2D / edge or face in 3D) it is intended to be connected with. In the example here, node 4 is the hanging node and the data producer, in addition to writing the ucd mesh and ucd zonelist, would be required to write an additional, connectivitylike, object where each hanging node is attached to its respective face or edge. If a hanging node is intended to be attached to an edge, as in the 2D example here, the data producer would have to indicate that. Likewise, in 3D, if a hanging node is intended to be attached to a face, the data producer would have to indicate that. But, in the example here, we're dealing with a case of just one level of refinement difference between neighboring elements. What if there are more levels of refinement? Then, along the long edge, there would be many hanging nodes. If for each such node, all we know is the bigger topological entity they are intended to be attached to is that sufficient?So, for the simple example here, if nodes are numbered 0,1,2 across the bottom, 3,4 in the middle and 5,6,7 across the top, the additional information looks like...