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

[Ravi Kanda]

Hi,

Happy New Year!  Over the past week, I have been going through the examples 
supplied with the latest pylith binary (1.0.2).  In addition to the well 
documented input files, i have also been looking at the output VTK (ascii) 
files.  In going through these examples, I encountered the following issues:

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?

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.

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.  Paraview gives me the following error message (but does not 
crash) on the Unix command line:
"ErrorMessage
# Error or warning: There was a VTK Error in file: 
/home/amy/ParaViewReleaseRoot/ParaView-2.6.1/VTK/Hybrid/vtkXYPlotActor.cxx (445)
  vtkXYPlotActor (0xa4fdd68): Nothing to plot!
ErrorMessage end
"
I am attaching the Line Probe output image from Paraview (Fig 3, a close-up of 
top surface) to illustrate this problem.  You can see the green-blue coloration 
on the line where the underlying surface values are red.  I have tried 
off-setting the line, so the interpolation points do not fall close to the 
fault, but I still have the same visualization problem.  I checked with my own 
python code using "vtkLineProbe()" that the vtk output file from Paraview is 
what I'd expect from the Line Probe command.  So, I am wondering if I should 
write a separate parsing routine to extract the interpolated values along the 
line from the Line Probe vtk output file by removing the cohesive element values 
(zero vector) from the line probe values (instead of using Paraview). Is this 
something that could be fixed in the next release?

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?

I am also attaching an example of what I am interested in plotting (Fig 4, 
visualization of lithomop output in a previous version of Paraview).

Thanks for your time!
Ravi.

---------------------------------------------------------------------
Ravi Kanda
Seismological Laboratory, MC 252-21
Division of Geological and Planetary Sciences
California Institute of Technology

1200 E. California Blvd., Pasadena, CA 91125
Phone: 626-395-6971, Fax: 626-564-0715
Web Page: http://www.gps.caltech.edu/~rkanda

----------------------------------------------------------------------

For a human being, the unexamined life is not worth living - SOCRATES

----------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig1_TwoTri3_dislocation_Warp10.jpg
Type: image/jpeg
Size: 63294 bytes
Desc: not available
Url : http://www.geodynamics.org/pipermail/cig-short/attachments/20080104/4b31a26b/Fig1_TwoTri3_dislocation_Warp10-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig2_TwoQuad4_dislocation_Warp25.jpg
Type: image/jpeg
Size: 38702 bytes
Desc: not available
Url : http://www.geodynamics.org/pipermail/cig-short/attachments/20080104/4b31a26b/Fig2_TwoQuad4_dislocation_Warp25-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig3_Hex8_dislocation_LineProbeIssue.jpg
Type: image/jpeg
Size: 68539 bytes
Desc: not available
Url : http://www.geodynamics.org/pipermail/cig-short/attachments/20080104/4b31a26b/Fig3_Hex8_dislocation_LineProbeIssue-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig4_ThrustFaultExample.jpg
Type: image/jpeg
Size: 272000 bytes
Desc: not available
Url : http://www.geodynamics.org/pipermail/cig-short/attachments/20080104/4b31a26b/Fig4_ThrustFaultExample-0001.jpg