<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jun 8, 2014 at 5:00 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> What only works on Cartesian grids?  Wave decomposition and such works<br>
>><br>
><br>
> My understanding was that the Clawpack algorithms worked only on Cartesian<br>
> grids. Are these "mode decomposed"?<br>
<br>
</div>The precise formulation used in Clawpack only works on structured<br>
meshes, but non-conservative hyperbolic systems can be solved on<br>
unstructured meshes and would be implemented in terms of wave<br>
decomposition.<br>
<div class=""><br>
>> on unstructured grids.  PetscProblem is the special-purpose thing that<br>
>> excludes large classes of good methods.  I think it is inappropriate to<br>
>> use the PetscProblem namespace for a specific class of methods.<br>
><br>
><br>
> I think you have an idiosyncratic and expansive understanding of the<br>
> word "Problem".  It can also mean a "difficulty", "unwelcome or<br>
> harmful situation", or "complication". If its really down to the word,<br>
> I could see changing it to reduce the number of ultimately unhelpful<br>
> emails.<br>
<br>
</div>Programmers, computers, and software exist to solve "problems".  That<br>
word is so phenomenally inspecific as to be useless in a general-purpose<br>
library like PETSc, unless it encompasses the entire scope of problems<br>
for which PETSc is applicable.  Clearly it does not even come close.</blockquote><div><br></div><div>I will change the name from Problem, and then push to master.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> Why can't you develop this in a separate package?<br>
><br>
> Too much overhead for too little benefit.<br>
<br>
</div>Can you state necessary and sufficient criteria for deciding when<br>
something should be a separate package?<br>
<div class=""><br>
>> >> From the two examples that use PetscProblem, I think the issue is that<br>
>> >> you want it to work with DMDA and DMPlex because the formulation does<br>
>> >> not depend on grid topology, but the naming convention for<br>
>> >> implementation-specific functions uses different namespaces.  But we can<br>
>> >> have DM functions that are implemented by multiple implementations.  So<br>
>> >> maybe this maps to<br>
>> >> DMTSSetIFunctionMattsCoolDiscretizationVolumetricQuadrature().<br>
>> ><br>
>> ><br>
>> > 1) Volumetric here is inappropriate because it supports boundary<br>
>> integrals<br>
>><br>
>> Through a different function, PetscProblemSetBdResidual().  (I will also<br>
>> complain that this does not support different boundary types.)<br>
><br>
><br>
> Criticize away. I did not want to give you the idea that criticism is<br>
> unwelcome.<br>
><br>
><br>
>> > 2) It is supposed to support both FEM and FVM<br>
>><br>
>> But you need new functions for FV because PetscProblemSetResidual<br>
>> definitely does not support it.<br>
><br>
><br>
> Yep.<br>
<br>
</div>So DMPlexTSSetRHSFunctionLocal is implicitly for upwind-based<br>
finite-volume discretizations of conservative hyperbolic systems and<br>
PetscProblemSetResidual is implicitly for the volumetric term in H^1<br>
finite-element discretizations.  New functions will be added as needed<br>
for solving more general problems or using more general methods?  Why<br>
stake out this canonical namespace for something you know a priori is a<br>
tiny subset of the problems types that should eventually be supported?<br>
<div class=""><br>
>> PetscLayout contains nontrivial data size and can be shared between<br>
>> multiple objects (and we should do a better job of that sharing because<br>
>> PetscLayout storage is not trivial with a million MPI ranks if each<br>
>> object has its own).<br>
>><br>
><br>
> PetscProblem can be shared between multiple objects, and has<br>
> non-trivial sizes.  There is no point to the above paragraph and it<br>
> dodges the main issue of the question.<br>
<br>
</div>Where is the problem-sized data?<br>
<br>
struct _p_PetscProblem {<br>
  PETSCHEADER(struct _PetscProblemOps);<br>
  void        *data;      /* Implementation object */<br>
  PetscBool    setup;     /* Flag for setup */<br>
  PetscInt     Nf;        /* The number of solution fields */<br>
  PetscObject *disc;      /* The discretization for each solution field (PetscFE, PetscFV, etc.) */<br>
  PetscObject *discBd;    /* The boundary discretization for each solution field (PetscFE, PetscFV, etc.) */<br>
  PointFunc   *obj;       /* Scalar integral (like an objective function) */<br>
  PointFunc   *f,   *g;   /* Weak form integrands f_0, f_1, g_0, g_1, g_2, g_3 */<br>
  BdPointFunc *fBd, *gBd; /* Weak form boundary integrands f_0, f_1, g_0, g_1, g_2, g_3 */<br>
  PetscInt     dim;       /* The spatial dimension */<br>
  /* Computed sizes */<br>
  PetscInt     totDim, totDimBd;       /* Total problem dimension */<br>
  PetscInt     totComp;                /* Total field components */<br>
  /* Work space */<br>
  PetscReal  **basis,    **basisBd;    /* Default basis tabulation for each field */<br>
  PetscReal  **basisDer, **basisDerBd; /* Default basis derivative tabulation for each field */<br>
  PetscScalar *u;                      /* Field evaluation */<br>
  PetscScalar *u_t;                    /* Field time derivative evaluation */<br>
  PetscScalar *u_x;                    /* Field gradient evaluation */<br>
  PetscScalar *refSpaceDer;            /* Workspace for computing derivative in the reference coordinates */<br>
  PetscReal   *x;                      /* Workspace for computing real coordinates */<br>
  PetscScalar *f0, *f1;                /* Point evaluations of weak form residual integrands */<br>
  PetscScalar *g0, *g1, *g2, *g3;      /* Point evaluations of weak form Jacobian integrands */<br>
};<br>
<br>
<br>
I don't think disc and discBd makes sense since combinations may be<br>
either non-unique or incompatible.<br>
<br>
Note that this formulation also cannot represent second order elliptic<br>
problems like |D^2 u|^2 = 0.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>