<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 7, 2014 at 4:50 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>
>> 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.<br>
><br>
><br>
> I think you exaggerate the danger.<br>
<br>
</div>I'd like to hear what some users and other developers think.<br>
<div class=""><br>
>> >> 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>
>> 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>
>><br>
><br>
> I agree, and many PETSc users want to use their own SNES, or they solve<br>
> problems which SNES cannot cope with nicely (non-holonomic constraints).<br>
<br>
</div>Clearly that is more common than people that use TS _and_ have a spatial<br>
discretization that fits nicely into your Framework.<br>
<div class=""><br>
>> 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>
<br>
</div>You didn't respond to this point.  Why are you taking up generic<br>
namespace with something this specific?<br>
<br>
I would argue that your PetscProblem interface is currently applicable<br>
to a strict subset of the intersection of MOOSE and GRINS.  I don't<br></blockquote><div><br></div><div>As far as I know, neither can do FV stuff which this is going to do. Maybe MOOSE</div><div>does. However, neither of those has good integration with the solver (I have</div>
<div>discussed this personally with Roy and Derek and they agree).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
think this belongs in PETSc, definitely not in such prominent namespace.<br></blockquote><div><br></div><div>I don't know why you think this is so bad. I picked a name because I needed</div><div>a name. Its not DM, its a collection of DMs.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I also cannot imagine that this interface is stable, so even if this<br>
sort of thing goes into PETSc, there's no use having it in the release.<br>
</blockquote></div><br>We have a bunch of stuff that is not completely stable. I am not sure what this</div><div class="gmail_extra">kind of conservatism buys us.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
   Matt<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>