[CIG-SHORT] Pylith "zero-pivot" error

[Brad Aagaard]

Ravi-

I don't see any error in the run log you sent. It looks like PyLith ran 
all the way through without any errors.

The zero-pivot usually means that PETSc encountered an unconstrained 
DOF. If things didn't run correctly, try running the problem with the 
same BC but without faults.

Some things to note:

(1) The zero-pivot is not associated with distorted cells.
(2) In exporting the mesh to an Exodus file, CUBIT renumbers everything. 
  I have no idea what the renumbering is based on. You can look at the 
exodus file in ParaView to see the renumbered mesh.

Brad


Ravi Kanda wrote:
> Brad,
> 
> Thanks, the debugging suggestion was very helpful.  Pylith now 
> "understands" my
> CFG files. But now, the run fails with the "Detected zero pivot in LU 
> factorization" error (see attached screen output log).  After checking 
> the PETSc documentation page, I tried running with the following in my 
> PYLITHAPP.CFG file:
> ---------------------------------------------
> pc_factor_shift_nonzero = true
> #pc_factor_shift_positive_definite = true
> ---------------------------------------------
> 
> A. I get the same error with either/BOTH flags.
> 
> B. I then ran pylith with the mesh debug flag, "debug = 1", and it seems 
> like the problem is with element 2982 (?).  On further investigation of 
> the screen output, this turns out to be a cohesive element.  So, I am 
> trying to figure out whether there is a problem of mesh-quality or if it 
> has something to do with cohesive element generation.
> 
> C. I used Cubit to generate my mesh, and have visually checked the mesh 
> quality to make sure there are only a small number of elements with a 
> poor aspect ratio (and no negative Jacobians).  The imported mesh has 
> 1265 elements (and only 4 of those elements have "bad" aspect or edge 
> ratios - i.e. > 4.0).  I am not sure if/how Pylith re-numbers the 
> imported elements, especially after the cohesive elements are added to 
> the system - so, I don't know where this element is in the mesh.  Is it 
> possible to extract this from the pylith debug information?  I couldn't 
> find any coordinate info listed in the screen output.
> 
> D. Also, there are two more error "blocks" starting at lines 134122 and 
> 134167 of the attached log file.  Are these associated with the zero 
> pivot error above (line 134077)?
> 
> Thanks again!
> Ravi.
> 
> ---------------------------------------------------------------------------------- 
> 
> 
> Brad Aagaard wrote:
>> Ravi-
>>
>> You have an error when specifying the materials bin. Delete line 38 of 
>> SLAB2D_p2_nx101_Th30.cfg.
>> What you have translates to:
>> pylith.timedependent.materials.materials = slab2D_3M
>> what you mean is:
>> pylith.timedependent.materials = slab2D_3M
>>
>> The easiest way to track down these problems is to use the --help, 
>> --help-properties, and --help-components arguments to pylith. For 
>> example, if you ran PyLith with
>> pylith YOUR_CFG_FILES_HERE --timedependent.help-components
>> you would find out that PyLith is still using the default materials 
>> bin (homogeneous). Once you fix your error you should see that PyLith 
>> is picking up your setting on line XX of your cfg file.
>>
>> Brad
>>
>>
> 
> ---------------------------------------------------------------------
> 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
> 
> ----------------------------------------------------------------------