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

[Matthew Knepley]

On Jan 4, 2008 3:56 PM, Ravi Kanda <rkanda at gps.caltech.edu> wrote:
> 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?

Our implementation of faults uses a Lagrange multiplier formalism, so
each cohesive
edge contributes another degree of freedom (node), the multiplier.

I don't really understand the other questions.

  Thanks,

    Matt

> 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
>
> ----------------------------------------------------------------------
>
> _______________________________________________
> CIG-SHORT mailing list
> CIG-SHORT at geodynamics.org
> http://geodynamics.org/cgi-bin/mailman/listinfo/cig-short
>
>



-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener