[CIG-SHORT] Issues with cohesive cells in VTK output

[Brad Aagaard]

Ravi Kanda wrote:
> TWO CELL EXAMPLES:
> ---------------------
> 1) The VTK output for "twotri3" contains 8 nodes (points), and that for 
> "twoquad4" contains 10 nodes.  I thought a cohesive cell adds just two 
> additional nodes.  If I go by the description of cohesive cells shown in 
> Figure 7.3 of the User's Guide, shouldn't the above cases have 6 & 8 
> nodes, respectively?  However, when I relate the Vector displacement 
> data with the Points data using the Cell Connectivity indicated, the 
> displacements at the "fault" nodes of each element are consistent with 
> left-lateral displacement across the cohesive element (see attached Fig 
> 1).  In the "twotri3" case nodes 5 & 7 are dropped from the connectivity 
> matrix (and nodes 7 & 9 in the "twoquad4" case).  I guess I am confused 
> about how cohesive elements are being defined.  I have checked Bathe, 
> Hughes, & Zienkiewicz and Taylor's books but could not find anything on 
> cohesive cells.  Do any of the other references on the back of the 
> Pylith user's guide discuss the implementation details of cohesive cells?

The cohesive cells for kinematic (prescribed slip) ruptures add twice as 
many nodes, because we add a node for the Lagrange multipliers. Dynamic 
ruptures (friction interfaces) will not have the Lagrange multipliers. 
Cohesive cells are of our doing, so you won't find them written up 
anywhere (yet). The DOF for nodes associated with Lagrange multipliers 
are forces in the fault coordinate system (right-lateral, reverse, 
opening) not the global coordinate system. If you are trying to plot 
displacement fields, you should ignore the DOF associated with Lagrange 
multipliers. We will include more documentation about the cohesive cell 
implementation in the next release.

We are currently redoing how PyLith outputs the solution so that fault, 
volume, and other data are in separate files (and include state variable 
information).

> 2) In the "twoquad4" example, I get nodal displacements that have a 
> large fault perpendicular (x-) displacements (see attached Fig 2), which 
> are of the same order of magnitude (roughly half) as the along-fault, or 
> y-, displacement. Also, even though the "dislocation_slip.spatialdb" 
> file defines a left-lateral (+ve) slip of 0.01 m, the output shows 
> right-lateral slip.  In addition, there is a "tiny" third vector 
> pointing perpendicular to the extended fault surfaces as can be seen in 
> the warped image (under node numbers 7 & 9).  I haven't changed anything 
> in the files - I am directly running the examples from the binary tarball.

Your twoquad4 figure has +z away from the viewer, so the right-lateral 
slip looks like left-lateral slip. If you have +z toward the viewer, it 
will be right-lateral slip as expected.

On the fault, there is fault normal motion where the two sides of the 
fault move together (so there is no opening or slip in the fault 
perpendicular direction). This is expected. In the case of the twotri3 
example, the triangles create the slip by undergoing rigid body 
rotations, so the result may not look like what you expect, but the 
solution is correct.

> 3) I have also been experimenting with VTK python scripts, Paraview, & 
> MayvVi to figure out a visualization "pipeline" that works for me.  The 
> problem I am having is that if I want to probe the data along a line 
> passing through the cohesive cells - say a transect running 
> perpendicular to the fault at the top surface - then Paraview (2.6.1) 
> does not display the correct interpolated displacements (whether 
> magnitude or individual components), and I cannot create an X-Y plot of 
> the attribute of interest (displacement magnitude or a component) along 
> that line.

I have never tried probing with ParaView or MayaVi. I suspect the 
inclusion of the forces associated with the Lagrange multipliers is 
causing problems. To test this you can try setting the values in the VTK 
output associated with Lagrange multipliers to zero and see if the 
probing works.

> HEX8 or more complicated examples:
> -------------------------------------
> As in (3) above, if I have to parse the Line Probe vtk output file for 
> line data, but instead have hundreds of elements (& nodes), then how do 
> I identify - just from the vtk file - which nodes are the "dummy" 
> cohesive nodes?  Do I just remove ones with "zero" displacements that 
> occur on the line but not at the fixed boundaries?  Would another 
> alternative be to go through the entire connectivity matrix to see which 
> node numbers have been "dumped"?  Is node-numbering from a cubit-exodus 
> file preserved during pylith runs?

Since we remove the cohesive cells from the VTK output (because VTK 
doesn't understand cohesive cells), you can zero out the DOF by setting 
all DOF not associated with a cell to zero. This can be done in two 
lines of Python code if you get the cells and displacements into Python.

Brad