[petsc-dev] getting ready for PETSc release

[Matthew Knepley]

On Sun, Jun 8, 2014 at 5:00 PM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
> >> What only works on Cartesian grids?  Wave decomposition and such works
> >>
> >
> > My understanding was that the Clawpack algorithms worked only on
> Cartesian
> > grids. Are these "mode decomposed"?
>
> The precise formulation used in Clawpack only works on structured
> meshes, but non-conservative hyperbolic systems can be solved on
> unstructured meshes and would be implemented in terms of wave
> decomposition.
>
> >> on unstructured grids.  PetscProblem is the special-purpose thing that
> >> excludes large classes of good methods.  I think it is inappropriate to
> >> use the PetscProblem namespace for a specific class of methods.
> >
> >
> > I think you have an idiosyncratic and expansive understanding of the
> > word "Problem".  It can also mean a "difficulty", "unwelcome or
> > harmful situation", or "complication". If its really down to the word,
> > I could see changing it to reduce the number of ultimately unhelpful
> > emails.
>
> Programmers, computers, and software exist to solve "problems".  That
> word is so phenomenally inspecific as to be useless in a general-purpose
> library like PETSc, unless it encompasses the entire scope of problems
> for which PETSc is applicable.  Clearly it does not even come close.


I will change the name from Problem, and then push to master.

   Matt


> >> Why can't you develop this in a separate package?
> >
> > Too much overhead for too little benefit.
>
> Can you state necessary and sufficient criteria for deciding when
> something should be a separate package?
>
> >> >> From the two examples that use PetscProblem, I think the issue is
> that
> >> >> you want it to work with DMDA and DMPlex because the formulation does
> >> >> not depend on grid topology, but the naming convention for
> >> >> implementation-specific functions uses different namespaces.  But we
> can
> >> >> have DM functions that are implemented by multiple implementations.
>  So
> >> >> maybe this maps to
> >> >> DMTSSetIFunctionMattsCoolDiscretizationVolumetricQuadrature().
> >> >
> >> >
> >> > 1) Volumetric here is inappropriate because it supports boundary
> >> integrals
> >>
> >> Through a different function, PetscProblemSetBdResidual().  (I will also
> >> complain that this does not support different boundary types.)
> >
> >
> > Criticize away. I did not want to give you the idea that criticism is
> > unwelcome.
> >
> >
> >> > 2) It is supposed to support both FEM and FVM
> >>
> >> But you need new functions for FV because PetscProblemSetResidual
> >> definitely does not support it.
> >
> >
> > Yep.
>
> So DMPlexTSSetRHSFunctionLocal is implicitly for upwind-based
> finite-volume discretizations of conservative hyperbolic systems and
> PetscProblemSetResidual is implicitly for the volumetric term in H^1
> finite-element discretizations.  New functions will be added as needed
> for solving more general problems or using more general methods?  Why
> stake out this canonical namespace for something you know a priori is a
> tiny subset of the problems types that should eventually be supported?
>
> >> PetscLayout contains nontrivial data size and can be shared between
> >> multiple objects (and we should do a better job of that sharing because
> >> PetscLayout storage is not trivial with a million MPI ranks if each
> >> object has its own).
> >>
> >
> > PetscProblem can be shared between multiple objects, and has
> > non-trivial sizes.  There is no point to the above paragraph and it
> > dodges the main issue of the question.
>
> Where is the problem-sized data?
>
> struct _p_PetscProblem {
>   PETSCHEADER(struct _PetscProblemOps);
>   void        *data;      /* Implementation object */
>   PetscBool    setup;     /* Flag for setup */
>   PetscInt     Nf;        /* The number of solution fields */
>   PetscObject *disc;      /* The discretization for each solution field
> (PetscFE, PetscFV, etc.) */
>   PetscObject *discBd;    /* The boundary discretization for each solution
> field (PetscFE, PetscFV, etc.) */
>   PointFunc   *obj;       /* Scalar integral (like an objective function)
> */
>   PointFunc   *f,   *g;   /* Weak form integrands f_0, f_1, g_0, g_1, g_2,
> g_3 */
>   BdPointFunc *fBd, *gBd; /* Weak form boundary integrands f_0, f_1, g_0,
> g_1, g_2, g_3 */
>   PetscInt     dim;       /* The spatial dimension */
>   /* Computed sizes */
>   PetscInt     totDim, totDimBd;       /* Total problem dimension */
>   PetscInt     totComp;                /* Total field components */
>   /* Work space */
>   PetscReal  **basis,    **basisBd;    /* Default basis tabulation for
> each field */
>   PetscReal  **basisDer, **basisDerBd; /* Default basis derivative
> tabulation for each field */
>   PetscScalar *u;                      /* Field evaluation */
>   PetscScalar *u_t;                    /* Field time derivative evaluation
> */
>   PetscScalar *u_x;                    /* Field gradient evaluation */
>   PetscScalar *refSpaceDer;            /* Workspace for computing
> derivative in the reference coordinates */
>   PetscReal   *x;                      /* Workspace for computing real
> coordinates */
>   PetscScalar *f0, *f1;                /* Point evaluations of weak form
> residual integrands */
>   PetscScalar *g0, *g1, *g2, *g3;      /* Point evaluations of weak form
> Jacobian integrands */
> };
>
>
> I don't think disc and discBd makes sense since combinations may be
> either non-unique or incompatible.
>
> Note that this formulation also cannot represent second order elliptic
> problems like |D^2 u|^2 = 0.
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140608/d8b9236d/attachment.html>