[CIG-SHORT] number of cells and vertices in PyLith

[Brad Aagaard]

On Tuesday 29 January 2008, Ravi Kanda wrote:
> So, Pylith uses the same element numbers as in the EXODUS file?> In that 
> case, is there a convention for numbering the new cohesive elements that
> are generated when there is a fault in the domain?  

PyLith currently does not reorder the original input cells or vertices. 
However, PyLith uses a numbering mechanism in which the numbering extends 
over both the cells and vertices. When there are no cohesive cells, the cells 
are numbered first (0 to M) and then the vertices are numbered (M+1 to M+N). 
With cohesive cells and multiple faults, things are not so tidy and cohesive 
cells and the added vertices are mixed together in the numbering.

> I have been setting the FIATLAGRANGE flag and from what I
> understand, FIAT is an "automatic" element generator, right?

FIAT is used for generating basis functions and quadrature (numerical 
integration) information for the reference cell. The FiatLagrange object uses 
FIAT to generate basis functions for Lagrange cells (line, quad, hex) as 
opposed to simplicial (FiatSimplex) cells (line, tri, tet). It has nothing to 
do with numbering. All of the numbering, labeling, and mapping to degrees of 
freedom is done within Sieve. If you want to understand how the mesh is 
numbered, I recommend turning on debugging for one of the two cell examples 
(e.g., twotri3) and sketching the mesh before and after. The debugging 
information will describe what cohesive cells are added with respect to which 
vertices. You can also look at the C++ files for the unit tests in 
unitests/libtests/faults/data. We have some little diagrams at the top of the 
source files that attempt to document how the numbering of cells and vertices 
changes with the addition of cohesive cells (so we know what the results of 
the tests should be).

Brad