[CIG-SHORT] Pylith "timedependent.homogeneous..." errors

[Matthew Knepley]

On Jan 28, 2008 9:49 PM, Ravi Kanda <rkanda at gps.caltech.edu> 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.

So this is about PETSc usage:

  1) For any solve, the first thing to do is see what was used

     --petsc.ksp_monitor

  2) I bet it was block Jacobi, so

     --petsc.sub_pc_factor_shift_positive_definite

  3) However I would change preconditioners since this is a saddle point

     --petsc.sub_pc_type jacobi

     --petsc.pc_type lu --petsc.ksp_type preonly --petsc.mat_type aijmumps

> 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.

   Yes, they create a saddle point since we are using Lagrange multipliers.

> 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.

No, I don't think so.

   Matt

> 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
> >
> >
> > On Tuesday 22 January 2008, Ravi Kanda wrote:
> >> I am building a 2D elastic model that contains three materials, two fault
> >> interfaces, and 8 edge BCs.  Pylith exits with the following errors:
> >> " ...
> >>   -- pyre.inventory(error)
> >>   -- timedependent.homogeneous.materials <- 'slab2D_3M'
> >>   -- unrecognized property 'timedependent.homogeneous.materials'
> >>   ...
> >> "
> >> So, every other error is of the form "-- unknown component
> >> timedependent.homogeneous.x.y.z", which is probably due to the first error
> >> shown above.
> >>
> >> 1) I would have thought the order would be
> >> "timedependent.materials.homogeneous...."
> >>
> >> 2) Does it matter where the materials and time information are defined
> >> (i.e., whether they are defined in the PYLITHAPP.cfg file or the
> >> <RUN-PREFIX>.cfg file? I am defining both in the latter.
> >>
> >> 3) I also want to know if "debug" option is available for Materials, BCs,
> >> and Faults, or if it is restricted to Mesh importing.
> >>
> >> Note on my workflow:
> >> -----------------------
> >> I am using python scripts to generate the mesh in Cubit, and export it in
> >> EXODUS format.  The SpatialDB files for each of the above components, as
> >> well as the CFG files are automatically generated from the problem data
> >> exported from the Cubit python scripts as well as separately specified
> >> run-data, to minimize manual errors.  I checked using Paraview that the
> >> mesh, nodesets and material blocks are exported correctly from cubit.
> >>
> >> For these initial runs, I have manually (and also by using test scripts I
> >> wrote) checked that the spatialDB files generated are consistent w.r.t the
> >> mesh-domain, units, and property values.  I also checked that the required
> >> module definitions of the form: '[pylith.timedependent.x.y.z...]' occur in
> >> the CFG files, as indicated in the pylith examples, and that the mesh
> >> nodeset and block labels are correctly identified in these files.
> >>
> >> I have been able to run and visualize output from all the pylith examples
> >> without problem, and used the HEX8 and TWOQUAD4 examples to guide the
> >> generation my ODB, SPATIALDB, and CFG files.
> >>
> >> ATTACHMENTS & Specifics:
> >> -----------------------
> >> I am attaching the screen-output for the run, along with the CFG files, and
> >> the material ODB file.  All the required files are in the same run
> >> directory (*.cfg, *.odb, *.spatialdb).   I generated containers
> >> (slab2D_3M.odb, slab2D_2F.odb, slab2D_8BC.odb) for the above three
> >> components using the corresponding templates provided in the Pylith binary
> >> distribution.  I also tried variations of the ODB file where I changed the
> >> object name at the top to the defaults (MyMatBin, MyBC, or MyFaults),
> >> instead of customized names... but I get the same errors.
> >>
> >>
> >> Thanks for your help!
> >> 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
> >>
> >> ----------------------------------------------------------------------
> >
> >
>
> --
> ---------------------------------------------------------------------
> 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