<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 7, 2014 at 3:30 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>
>> This is awfully prime real estate in the namespace to be placing<br>
>> functions that run at quadrature points, do not have context arguments,<br>
>> cannot share results of a material model, is somewhat specific to finite<br>
>> elements, does not support Riemann solvers, characteristic<br>
>> reconstruction, general boundary conditions, etc.<br>
>><br>
><br>
> I gave my reasons for excluding context argument from the bottom level<br>
> functions. The context appears at the next level up, so that can be<br>
> replaced if you do not like the quadrature-level interface.<br>
<br>
</div>And yet the quadrature interface is what occupies that prime namespace.<br>
Other uses of unadorned wording like "Residual" (well, everything else<br>
uses Function, though I would use Residual if starting anew) and<br>
"Jacobian" are in places that do not even assume a PDE or variational<br>
problem, let alone a very specific class of discretizations.</blockquote><div><br></div><div>I think you exaggerate the danger.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> I don't think PETSc should be in the business of creating a Framework.<br>
>> To be honest, I would rather see functionality like this provided in an<br>
>> external library so that it isn't confused with the more general-purpose<br>
><br>
> I think this argument can be made about anything on top of Vec and<br>
> Mat, like TS. The real criterion we use to decide these things is how<br>
> useful it would be for the majority of PETSc users. I think this is a<br>
> hands-down win there.<br>
<br>
</div>Keep in mind that (a) many PETSc users already use a discretization<br>
package so they couldn't care less about PetscProblem, and (b) many<br>
users that call PETSc directly have rather exotic discretizations or are<br>
not solving PDEs so PetscProblem is of no use for them.<br></blockquote><div><br></div><div>I agree, and many PETSc users want to use their own SNES, or they solve</div><div>problems which SNES cannot cope with nicely (non-holonomic constraints).</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">
TS works on a semi-discrete form and assumes nothing about the equation<br>
(such as spatial discretization, if applicable).  The interfaces that<br>
offer something more specific are namespaced accordingly, e.g.,<br>
DMDATSSetIFunctionLocal().  I would have less issue with<br>
DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature (which may<br>
or may not be "in scope"), but PetscProblemSetResidual is downright<br>
pretentious.<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>