The cxPyramid data type is a root data type, which means it can be used on module ports to pass data into and out of modules. A pyramid consists of three main parts:

This is the data type definition for the pyramid:

root typedef struct cxPyramid {
    cxLattice           baseLattice     “Base Lattice”;
    long                count           “Num Levels”;
    cxPyramidLayer      layer[count];
    cxPyramidReference  ref;
} cxPyramid;

These are the variables for the pyramid:

A pyramid that incorporates a pyramid dictionary is said to be a “compressed pyramid” as opposed to the “uncompressed pyramids” lacking such a dictionary. A pyramid dictionary is simply a collection of uncompressed pyramids that describe in full detail their reference elements.

You can use pyramid dictionaries to:

The cxPyramidReference data structure, described in “Structure of a Dictionary” lets you specify the composition of your pyramid in terms of already-defined pyramidal elements. For example, to create a tetrahedral finite element grid, you would specify the element type as tetrahedral, list the vertices necessary to create the grid, and enumerate the constituent tetrahedra based on their four corner vertices.

For a grid of hexahedral bricks, you would specify the type as hexahedral, list the vertices necessary to create the grid, and enumerate the constituent hexahedral bricks based on their eight corner vertices. This is illustrated in the SimplePyrReader module described below.

The best way to learn how to use the pyramid data type is by example. The next section provides two examples of user functions for pyramid modules.

This example, called SimplePyrReader, takes in nodal points, reads them and makes bricks from them. It is a good template for creating any pyramid reader module that deals with only one data type. It uses compression and refers to the default pyramid dictionary. The source code is in /usr/explorer/src/MWGcode/Pyramid/C/reader.c There is also a Fortran version.

This is the sample data file, which contains finite element data. The file may not contain any comments.

12 1 2

0 0 0 100
0 1 0 100
1 1 0 100
1 0 0 100
0 0 1 200
0 1 1 200
1 1 1 200
1 0 1 200
0 0 2 300
0 1 2 300
1 1 2 300
1 0 2 300

0 1 2 3 4 5 6 7
4 5 6 7 8 9 10 11

The first line gives the number of nodes (12), the number of data variables (1) and the number of bricks (2). The next 12 lines list the coordinates (x,y,z) and the data value for each node. The data variable is pressure, changing in the Z direction. The bricks have eight nodes each, but share one face (four nodes) so there is a total of 12 nodes.

The last two lines define the connectivity list, or the relationship between the nodes that make up the bricks. The two bricks share the face delineated by nodes 4, 5, 6, and 7. The nodes are connected in the sequence indicated in the first list to make up the first brick.

The second list defines the form of the second brick. The form of the hexahedron in the default pyramid dictionary is shown in Figure 4-1.

This is the user function for SimplePyrReader.

/*
This code assumes that only one cell type is used. The user
can alter the two define's for a different cell type. 
*/

#include <cx/cxPyramid.h>
#include <cx/Pyramid.h>
#include <cx/cxPyramid.api.h>
#include <cx/DataAccess.h>
#include <cx/DataTypes.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define NODES 8
#define TYPE cx_pyramid_dict_hexahedron

int memclean(cxPyramid *pyr,
	     cxErrorCode ec, 
	     cxConnection *conn)
{
/* this routine will clear up memory in case of errors */
  if(cxDataAllocErrorGet() || (ec != cx_err_none))
  {
    cxDataRefDec(pyr);
    cxDataRefDec(conn);
    return 1;
  } else {
    return 0;
  }
}

void       read_brick   (char *filename, 
	                   cxLattice **base_lat,
		                cxPyramid ** pyramid )
{
  FILE *file;
  float *coord, *data;
  cxConnection *conn;
  cxPyramidDictionary *dict;
  cxErrorCode ec = cx_err_none;
  long *connec, num_nodes, num_bricks;
  long nDataVar,i,j,k, *elem;

  if(filename == NULL) return;
  if(filename[0] == NULL) return;
  if((file = fopen(filename,”r”)) == NULL)
  {
    printf(“Cannot open file %s\n”,filename);
    return;
  }
/* 
  get the header information 
   Number of Nodes, 
   Number of Data Properties, 
   Number of elements
*/
  fscanf(file,”%d %d %d”,&num_nodes, &nDataVar, &num_bricks); 
  *base_lat = cxLatNew(1,&num_nodes,nDataVar,cx_prim_float,
		       3,cx_coord_curvilinear);
  if(cxDataAllocErrorGet()) return;
  cxLatPtrGet(*base_lat,NULL,&data,NULL,&coord);

/* 
  read in the nodal data. This assumes there are 3 coords
  and nDataVar data values for each node. 
*/
  for(i=0,k=0;i<num_nodes;i++)
  {
    fscanf(file,” %f %f %f”,&coord[3*i],&coord[3*i+1],&coord[3*i+2]);
    for(j=0;j<nDataVar;j++)
       fscanf(file,”%f”,&data[k++]);
  }

Pyramid Compression

/* build up the pyramid by ignoring the intermediate levels */
  *pyramid = cxPyrNew(0);
  cxPyrSet(*pyramid,*base_lat);
  cxPyrLayerSet(*pyramid,1,NULL,NULL);
  cxPyrLayerSet(*pyramid,2,NULL,NULL);
/* set up the connections list */

  conn = cxConnNew(num_bricks, num_bricks * NODES);
  if(memclean(*pyramid,ec,0))return;
  cxConnPtrGet(conn,NULL,NULL,&elem,&connec);
  *elem++ = 0;
  for(i=0,k=0;i<num_bricks;i++)
  {
    *elem++ = (i+1) * NODES;  /* each has NODES nodes per brick */
    for(j=0;j<NODES;j++)
    {
      fscanf(file,”%d”,&connec[k++]); /* read in nodal list */
    }
  }
  cxPyrLayerSet(*pyramid,3,conn,NULL);
  if(memclean(*pyramid,ec,conn))return;

/* make the pyramid dictionary */

  dict = cxPyrDictDefault( 3 );
  cxPyramidDictionarySet( *pyramid, dict, &ec );
  if(memclean(*pyramid,ec,conn))return;
  cxPyramidCompressionTypeSet( *pyramid, 
			      cx_compress_unique, &ec );
  if(memclean(*pyramid,ec,conn))return;
  connec = (long *)cxPyramidCompressionIndexGet(*pyramid,&ec);
  if(memclean(*pyramid,ec,conn))return;
  *connec = TYPE;
}

The dictionary reference elements serve as building blocks from which the final pyramid is constructed. They include 2-D elements, such as triangles and quadrilaterals, and 3-D elements, such as bricks and tetrahedrons. The Explorer default dictionary contains some of the most commonly used reference elements (see Figure 4-1).

The vertices are labelled in the order that Explorer requires to make each form, counter-clockwise on the bottom and then counter- clockwise on the top. You provide this information in the connections list in cxConnection (see “Creating a Connection List”).

---

Note: The vertex labelling of these elements is critical. The sequence determines how the vertices you provide in the connection list are interpreted. If you label the vertices differently, your finite element mesh will be made up of distorted or inverted elements.

---

Figure 4-1. Pyramid Dictionary Reference Elements

Table 4-1 lists the elements illustrated above, with the dictionary name and number of nodes that make up each element.

The finite element pyramid requires a 1-D curvilinear lattice at all levels. The 1-D restriction is so that the indexing information in the connections list makes sense. But there is a natural ordering from the nodes in a 3-D lattice to nodes in a 1-D lattice, so you can break out data from a 3-D lattice fairly easily into a 1-D lattice for inclusion in a pyramid. The natural ordering, or memory layout, of data in two or more dimensions gives the usual 1-D indexing into the array.

Figure 4-2 shows a 2-D lattice that, when translated into a 1-D IRIS pyramid lattice, has 35 nodes, indexed as 0-34.

Figure 4-2. Memory Layout of a 2-D Lattice

Not all lattices in a pyramid need have data or coordinates. The base lattice, which contains all the nodal data and coordinate values, is frequently the only lattice that contains coordinate information at all. The 0-layer lattice can store edge-based data, and the 1-layer lattice can contain face-centered data, such as the mass flux, for example. The tetrahedral lattice contains volumetric or centroid data, such as a mass fraction, centroid pressure, or gauss point information, as well as coordinates for the exact location of the data in 3-D space.

The ClipPyr and CropPyr modules work by removing elements at the highest level in the pyramid, if those elements contain any vertices outside the bounding plane(s). Therefore, you should construct t finite element meshes with the top level being the most natural component. Often, this will mean that a finite element mesh has count=3 and is composed of a large number of 3-D elements. This is the default behavior of the LatToPyr module, which forms a tetrahedral or hexahedral mesh from a lattice.

The pyramid structure is built from lattices layered onto the base lattice. Figure 4-3 shows the relationship between elements and layers in an uncompressed tetrahedral pyramid. It illustrates how a finite element grid can be built from the hierarchy of relationships between four vertices.

Figure 4-3. Layers in a Tetrahedral Grid

However, the simplest tetrahedral grid is just an array of tetrahedra, defined by specifying their vertices. The vertex locations and data are stored in the base lattice. You can omit edge and face information and go directly to the 3-D element layer of the pyramid. The cxConnection structure of this layer (layer[2] in C or layer(3) in Fortran) really does all the work of constructing the tetrahedral grid.

It has 32 tetrahedra, so the structure of the elements array is:

numElements     32
elemArrayLen    33
elements[]      0 4 8 12 16 ... 128
numConnections  128

The vertices are labelled in the natural order shown in Figure 4-4. Grid A shows the vertices at the bottom of the pyramid and grid B shows those at the top. Grid C shows the top partially overlaid on the bottom to illustrate how the tetrahedra are formed.

Figure 4-4. Top and Bottom of Compressed Tetrahedral Grid

The elements array is the concatenation of the sets of four vertices for the 32 tetrahedra:

elements    0  1  5 24   1 2  6 25    2  3  7 26
            0  5  4 27   1  6  5 28   2  7  6 29   3  8  7 30
            4  5 10 27   5  6 11 28   6  7 12 29   7  8 13 30
            4 10  9 31   5 11 10 32   6 12 11 33   7 13 12 34    8 14 13 35 
            9 10 15 31   10 11 16 32  11 12 17 33  12 13 18 34   13 14 19 35 
             10 16 15 36  11 17 16 37  12 18 17 38  13 19 18 39
             15 16 20 36  16 17 21 37  17 18 22 38  18 19 23 39
             16 21 20 40  17 22 21 41  18 23 22 42 
                      ...

When you use a pyramid dictionary, some of the cell structures in your own pyramid are compressed and you may not have to enumerate the faces or edges making up the finite element grid. In general, it is unnecessary to specify any relationship information for the layers between the vertices and the layer at which dictionary elements are referenced. It is this careful omission of repetitive data that makes the pyramid dictionary structure simpler and more compact to use.

However, you must still define the lattice and connection list pairs in the layer[] array above the “compression dimension” (see the definition of nDim in “Structure of a Dictionary.”) But below the compression dimension nDim, there are no lattice or cxConnection structures; these structures are superseded by the reference elements in the dictionary. The base lattice still holds the vertex data and coordinates necessary to give the compressed pyramid a location in physical space and to supply the data requirements of the pyramid modules.

In addition to the omission of some layers, there is an important change in the cxConnection structure at the compression layer. At layer [nDim-1] (in C) or layer(nDim) (in Fortran), the cxConnection structure must describe the composition of the compressed elements in terms of their vertices. You create such a connection list by listing the actual vertex indices of the baseLattice vertices you wish to go into the construction of each element, as in the example in “Creating a Tetrahedral Grid.”

The integer value that identifies the type of an element is really just an index into the pyramid dictionary. Since the dictionary is merely an array of uncompressed pyramids, it is natural to use the array index of the dictionary element as the identifying value.

In the case of a grid of a single element type, however, the vector of identical indices is omitted in favor of a single universal element type.

Figure 4-5 shows how the tetrahedral grid looks in compressed form.

Figure 4-5. Layers in a Compressed Grid

Figure 4-3 shows the same grid in uncompressed form, with all the layers visible.

The pyramid layers are described by the cxPyramidLayer structure. This is the type definition for a single pyramid layer:

typedef struct {
    closed cxConnection relation       “Layer %d Connection”;
    closed cxLattice    nextLattice    “Layer %d Lattice”;
} cxPyramidLayer;

The connections among elements within a layer can be fairly complex and each one must be specifically defined in the cxConnection structure. This is the type definition for the set of connections in a pyramid layer:

shared typedef struct {
  long         numElements            “Num Elements”;
  long         elemArrayLen           “Elements Array Length”;
  long         numConnections        “Connections Array Length”;
  long         elements[elemArrayLen]      “Elements Array”;
  long         connections[numConnections] “Connections Array”;
} cxConnection;

These are the variables:

This is the data type declaration for cxConnection:

typedef struct cxConnection {
    long       numElements;
    long       elemArrayLen;
    long       numConnections;
    long       *elements;
    long       *connections;
} cxConnection;

The variables are described in “Creating a Connection List.”

Figure 4-6 illustrates the components of a connection list for layer 0 of a tetrahedron. It contains six edge elements connected to four nodes in the base lattice by twelve dependencies. The connection data structure defines each edge-vertex relationship specifically (see “The Pyramid Connections.”)

Figure 4-6. Connections in a Tetrahedron

You can see how the vertex information and the description of the connections between them at each level are used to construct 2-D and 3-D elements, resulting in the creation of a tetrahedron. It is, however, legal to create a finite element pyramid without base data, coordinates, or indeed a base lattice at all.

This example shows how you fill out the connections list for each layer in a pyramid. The data are for the connections illustrated in Figure 4-6.

It is somewhat involved to write a module that takes a pyramid as input in order to perform a computation, create a filtered output pyramid, or to generate geometry for visualization in the Render module. You must take into account the hierarchical nature of the pyramid data, with the added option of a dictionary to indicate element types.

A Practical Example

Assume that you are writing the 2-D part of PyrToGeom, which creates shaded polygons from an input pyramid. However, the input pyramid is compressed at the 3-D cell level. It is prohibitively expensive in time and memory to expand the pyramid and then recompress it to faces, so instead you preprocess the 3-D element dictionary in terms of its faces, then simply draw the faces for each 3-D element.

The first step is to preprocess the pyramid dictionary. The routine cxPyrDictCompress simplifies this task. This routine takes an input dictionary compressed at too high a level and returns a new, equivalent dictionary, where each reference element in the input dictionary is replaced by a _compressed_ reference element in the output dictionary.

This violates the usual standard that a pyramid dictionary is made up of fully expanded pyramids, but the violation is temporary, as this output dictionary is really used as a translation table to process elements at the operational level. Figure 4-7 shows the process.

Figure 4-7. Preprocessing a Pyramid Dictionary

Each of the compressed reference elements now refers to the same dictionary, which has dimension equal to the operational level. This means that each reference element is now described in terms of elements that your algorithm can handle. Furthermore, all the reference elements in the input dictionary are described in terms of the same dictionary, which you can include in your output if necessary.

Relating this to the PyrToGeom example, you receive a grid of 3-D elements but want to work with faces. So you call cxPyrDictCompress to get a 3-D dictionary in which each 3-D reference element is instead a pyramid compressed at the 2-D level, that is, each 3-D reference element is now a compressed pyramid made up of faces.

Now it is easy to process the too highly compressed input. Simply operate on each active element at the compression level, looking up the element in the translation dictionary.

The element will comprise one or more elements at the right level of compression, which can be processed directly by your algorithm. For instance, a 3-D prism cell input is made up of triangular and rectangular faces, which PyrToGeom can handle.

Lastly, keep track of the vertices that are used to represent each element. In the original input, the vertices are listed at the compression layer in the connections[] array of the cxConnection structure. The input dictionary uses vertices numbered 0, 1, ... n-1 to indicate the first n vertices of the compressed element. During recompression of the input dictionary, the higher level element is decomposed into lower level elements, and the relevant vertices from the set [0, 1, ..., n-1] are used.

It is important to pick up the indirect indexing from both the compressed dictionary and the input connection list, so that the correct vertices are used. For example, the prism has six vertices. If vertices 1 2 3 6 7 8 make up a sample prism, then the prism element in the input dictionary refers to vertices 0-5, meaning the first six vertices of the input element. If you work with vertices 0, 1, 2, 3, 4, 5, you will be interpreting the input data incorrectly. Use the indirect addressing to pick up 0==>1, 1==>2, 2==>3, 3==>6, 4==>7, 5==>8.

The prism will then be made up of faces of two types, triangles (0,1,2) and rectangles (0,1,2,3). A sample connection array for a prism is [ 0 1 2 0 1 4 3 1 2 5 4 2 0 3 5 3 4 5 ]. When you work with the last triangle in the prism, make sure to index from its vertex number (0,1,2) into the connection array to get (3,4,5) as the vertices to look up in the original compressed input, yielding actual vertex numbers 6,7,8. This double translation may seem complex, but it naturally reflects the compression in two stages, first to too high a level, then down to the correct level.

Correct application of this technique makes it almost as easy to handle pyramid compression at any level as it is to handle it only at the desired level. Source code for the modules ComposePyr, CropPyr, and LatToPyr is provided in the directories below /usr/explorer/src.

Most modules operate at a single level, but some, like PyrToGeom, can operate at many levels. In this case, you can create a table of operational level versus level of compression. You will usually find that the table breaks down into actions at the operational level, actions below that level (including, perhaps, simply expanding the input data), and recompressing the input dictionary for inputs above the operational level.

This example uses compressed pyramids to generate a pyramid. The C and Fortran versions do the same thing. The code is in /usr/explorer/src/MWGcode/Pyramid/C/GeneratePyr.c and in /usr/explorer/src/MWGcode/Pyramid/Fortran/GeneratePyr.f.

#include <cx/cxLattice.api.h>
#include <cx/cxParameter.api.h>
#include <cx/cxPyramid.api.h>
#include <cx/Pyramid.h>
#include <cx/DataAccess.h>
#include <cx/DataTypes.h>
#include <cx/UI.h>

#include <string.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define NUM_TYPES 9
#define NODE(i) ((i==0)?4:i)
long pyr_type[NUM_TYPES] = {
 cx_pyramid_dict_quadrilateral,
 cx_pyramid_dict_point,
 cx_pyramid_dict_line,
 cx_pyramid_dict_triangle,
 cx_pyramid_dict_tetrahedron,
 cx_pyramid_dict_pyramid,
 cx_pyramid_dict_prism,
 cx_pyramid_dict_wedge,
 cx_pyramid_dict_hexahedron,
};
int memclean(cxPyramid *pyr,
             cxErrorCode ec, 
             cxConnection *conn)
{
  if(cxDataAllocErrorGet() || (ec != cx_err_none))
  {
    if(pyr != NULL)cxDataRefDec(pyr);
    if(conn != NULL)cxDataRefDec(conn);
    return 1;
  } else {
    return 0;
  }
}
void    compose  (
                  cxLattice      *baseLat, 
                  unsigned char  *filename, 
                  cxPyramid      **pyr, 
                  long           quad )
{
  cxPyramidDictionary *dict;
  cxErrorCode ec = cx_err_none;
  cxConnection *conn;
  FILE *file;
  long *obj = NULL;
  long *node = NULL;
  long *iptr,i,num_nodes,num_objs,unique,levels;
  long show_quad,*elem,*connect;  
  char buf[100];
  
  if(!filename || filename[0] == NULL) return;
  if((file = fopen(filename,”r”)) == NULL) 
  {
    printf(“ Error reading file %s\n”,filename);
    return;
  }
/* the object list will not be any larger than the number of nodes */
  obj = (long *)calloc(baseLat->dims[0],sizeof(long));
  show_quad = FALSE;
  num_objs = num_nodes = 0;
  while(TRUE){
    if(fscanf(file,”%d”,&obj[num_objs]) < 0) break;
    if(node == NULL)
    {
      node = (long *)malloc(obj[num_objs]*sizeof(long));
    }else{
      node = (long *)realloc((void *)node,
                             (num_nodes+obj[num_objs])*sizeof(long));
    }
    for(i=0;i<obj[num_objs];i++)
    {
      if(fscanf(file,”%d”,&node[num_nodes+i]) < 1)
      {
        printf(“ Error reading obj %d. Not enough data\n”,num_objs);
        return;
      }
    }
    num_nodes += obj[num_objs];
/* determine whether it it a quad or tetra */
    if(obj[num_objs] == 4) {
      obj[num_objs] = ((quad == 0) ? 0:4);
      show_quad = TRUE;
    }
    num_objs++;
  }
/* do I need the radio button? */
  if(show_quad)
{
    cxInWdgtShow(“Quad”);
  }else{ 
    cxInWdgtHide(“Quad”);
  }
/* am I a unique compressed pyramid ? */
  unique = TRUE;
  for(i=1;i<num_objs;i++)
  {
    if(obj[i] != obj[i-1])
    {
      unique = FALSE;
      break;
    }
  }
/* build the pyramid */  
  *pyr = cxPyrNew(0);
  cxPyrSet(*pyr,baseLat);
  levels = 3;
  conn = cxConnNew(num_objs,num_nodes);
  if(memclean(*pyr,ec,conn)) return;
  cxConnPtrGet(conn,NULL,NULL,&elem,&connect);
/* fill elem & connect */
  elem[0] = 0;
  for(i=0;i<num_objs;i++)
  {
    elem[i+1] = elem[i] + NODE(obj[i]);
  }
  bcopy(node,connect,num_nodes*sizeof(long));
/* verify all the nodes are legal */
  for(i=0;i<num_nodes;i++)
  {
    if(node[i] < 0 || node[i] > baseLat->dims[0])
    {
      printf(“Illegal connection %d at %d\n”,node[i],i);
      *pyr = NULL;
      return;
    }
}
/* load all the intermediate levels of the pyramid */
  for(i=1;i<levels;i++)
  {
    cxPyrLayerSet(*pyr,i,NULL,NULL);
  }
/* put the connectivity in the pyr */
  cxPyrLayerSet(*pyr,levels,conn,NULL);
  if(memclean(*pyr,ec,conn)) return;
/* add the compression info */
  dict = cxPyrDictDefault(levels);
  cxPyramidDictionarySet(*pyr,dict,&ec);
  if(memclean(*pyr,ec,NULL))return;
  if(unique)
  {
    cxPyramidCompressionTypeSet(*pyr,cx_compress_unique,&ec);
    if(memclean(*pyr,ec,conn)) return;
    iptr =  cxPyramidCompressionIndexGet(*pyr,&ec);
    if(memclean(*pyr,ec,NULL))return;  
    *iptr = pyr_type[obj[0]];
  } else {         /* non-unique */
    cxPyramidCompressionTypeSet(*pyr,cx_compress_multiple, &ec);
    if(memclean(*pyr,ec,NULL)) return;
    cxPyramidNumberIndicesSet(*pyr,num_objs,&ec);
    iptr = (long *)cxPyramidCompressionIndexAlloc(*pyr);
    if(iptr != NULL)
    {
      cxPyramidCompressionIndexSet(*pyr,&iptr,&ec);
      if(memclean(*pyr,ec,NULL))return;  
      for(i=0;i<num_objs;i++)
      {
        *iptr++ = pyr_type[obj[i]];
      }
    }
  }
  free(obj);
  free(node);
}

      subroutine compose ( baselat, filename, pyr, quad )
      implicit none
      include '/usr/explorer/include/cx/DataAccess.inc'
      include '/usr/explorer/include/cx/DataTypes.inc'
      include '/usr/explorer/include/cx/Pyramid.inc'
      integer cxPyramidCompressionIndexGet
      integer pyr_type(9) /
     1    cx_pyramid_dict_quadrilateral,
     1    cx_pyramid_dict_point,
     1    cx_pyramid_dict_line,
     1    cx_pyramid_dict_triangle,
     1    cx_pyramid_dict_tetrahedron,
     1    cx_pyramid_dict_pyramid,
     1    cx_pyramid_dict_prism,
     1    cx_pyramid_dict_wedge,
     1    cx_pyramid_dict_hexahedron/
      logical show_quad,unique
      integer long_size,num_objs, num_nodes,iunit
      parameter (long_size = 4)
      character*(*)   filename
      character*80 line
      integer     pyr, quad, baselat,levels,dict,INODE,conn
      integer ios,i1,i2,i3,i4,i5,i6,i7,dims(1),i,j,ec
      integer obj(1),elem(1),connect(1),node(1),nod(1)
      pointer (pobj,obj),(pnode,node),(pdims,dims)
      pointer (pelem,elem),(pconnect,connect),(pnod,nod)
      open(iunit,file=filename,status='old',iostat=ios)
      if(ios .ne. 0) then
         print*,”Error opening file “,filename
         return
      endif
      call cxLatDescGet(baselat,i1,pdims,i2,i3,i4,i5,i6,i7)
      pobj = malloc(dims(1)*long_size)
      show_quad = .false.
      num_objs = 0
      num_nodes = 0
 10   read(iunit,'(a)',end=20)line
      read(line,*)obj(num_objs+1)
      if(num_nodes .eq. 0)then
         pnode = malloc(obj(num_objs+1)*long_size)
      else
         pnod = pnode
         call realloc(pnode,pnod,(num_nodes+obj(num_objs+1))*long_size,
     1       num_nodes*long_size)
      endif
        read(line,*)i,(node(j),j=num_nodes+1,num_nodes+obj(num_objs+1))
      num_nodes = num_nodes + obj(num_objs+1)
      if(obj(num_objs+1) .eq. 4)then
         if(quad .eq. 0) then
            obj(num_objs+1) = 0
         else
            obj(num_objs+1) = 4
         endif
         show_quad = .true.
      endif
      num_objs = num_objs + 1
      go to 10
 20   continue
      close(iunit)
      if(show_quad)then
         call cxInWdgtShow(“Quad”)
      else
         call cxInWdgtHide(“Quad”)
      endif
      unique = .true.
      do i=2,num_objs
         if(obj(i) .ne. obj(i-1)) unique = .false.
      end do
      pyr = cxPyrNew(0)
      call cxPyrSet(pyr,baselat)
      levels = 3
      conn = cxConnNew(num_objs,num_nodes)
      call cxConnPtrGet(conn,i1,i2,pelem,pconnect)
      elem(1) = 0
      do i=1,num_objs
         elem(i+1) = elem(i) + INODE(obj(i))
      end do
      do i=1,num_nodes
         connect(i) = node(i)
      end do
      do i=1,num_nodes
         if(node(i) .lt. 0 .or. node(i) .gt. dims(1))then
            print*,”Illegal connection “,node(i),” at “,i
            pyr = 0
            return
         endif
      enddo
      call cxPyrSet(pyr,baselat,1)
      call cxPyrLayerSet(pyr,1,0,0)
      call cxPyrLayerSet(pyr,2,0,0)
      call cxPyrLayerSet(pyr,3,conn,0)
      dict = cxPyrDictDefault(3)
      call  cxPyramidDictionarySet(pyr,dict,ec)
      if(unique)then
         call cxPyramidCompressionTypeSet(pyr,cx_compress_unique,ec)
         pconnect = cxPyramidCompressionIndexGet(pyr,ec)
         connect(1) = pyr_type(obj(1))
else
         call cxPyramidCompressionTypeSet(pyr,cx_compress_multiple,ec)
         call cxPyramidNumberIndicesSet(pyr,num_objs,ec)
         pconnect = cxPyramidCompressionIndexAlloc(pyr)
         call cxPyramidCompressionIndexSet(pyr,pconnect,ec)
         if(pconnect .ne. 0)then
            do i=1,num_objs
               connect(i) = pyr_type(obj(i)+1)
            end do
         endif
      endif
      call free(pobj)
      call free(pnode)
      return
      end

      integer function INODE(i)
      INODE = i
      if(i .eq. 0) INODE = 4
      return
      end
      subroutine realloc(paddr,piaddr,new_size,old_size)
      implicit none
      character*1 addr(1),iaddr(1)
      integer i,new_size,old_size
      pointer(paddr,addr),(piaddr,iaddr)
      paddr = malloc(new_size)
      do i=1,old_size
         addr(i) = iaddr(i)
      end do
      call free(iaddr)
      return
      end

Source code for the modules ComposePyr, CropPyr, and LatToPyr is provided in the directories below /usr/explorer/src. To see how the modules are constructed, open the modulename.mres files for these modules in the Module Builder.