<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 7, 2014 at 8:21 AM, 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>
>> How do we note that these interfaces are not stable and will likely<br>
>> change soon after the release?  (At least I think the current<br>
>> arrangement is brittle and either will not last or will not be used<br>
>> much.)<br>
>><br>
><br>
> Feel free to note on the list that you think it should be done a different,<br>
> as yet unspecified<br>
> or coded, way.<br>
<br>
</div>We've discussed these issues many times.  I think that in your quest to<br>
make certain simple things easy (or to avoid duplication between<br>
examples), you are building a Framework.  Not in the sense of<br>
controlling main, but in being very opinionated about formulation.<br></blockquote><div><br></div><div>Of course, I disagree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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></blockquote><div><br></div><div>I gave my reasons for excluding context argument from the bottom level functions. The context</div><div>appears at the next level up, so that can be replaced if you do not like the quadrature-level</div>
<div>interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  ierr = DMGetProblem(dm, &prob);CHKERRQ(ierr);<br>
  ierr = PetscProblemSetResidual(prob, 0, f0_u, f1_u);CHKERRQ(ierr);<br>
  ierr = PetscProblemSetResidual(prob, 1, f0_p, f1_p);CHKERRQ(ierr);<br>
  ierr = PetscProblemSetJacobian(prob, 0, 0, NULL, NULL,  NULL,  g3_uu);CHKERRQ(ierr);<br>
  ierr = PetscProblemSetJacobian(prob, 0, 1, NULL, NULL,  g2_up, NULL);CHKERRQ(ierr);<br>
  ierr = PetscProblemSetJacobian(prob, 1, 0, NULL, g1_pu, NULL,  NULL);CHKERRQ(ierr);<br>
<br>
<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></blockquote><div><br></div><div>I think this argument can be made about anything on top of Vec and Mat, like</div><div>TS. The real criterion we use to decide these things is how useful it would be</div>
<div>for the majority of PETSc users. I think this is a hands-down win there.</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">

functionality found in the rest of PETSc, and so that it can make more<br>
frequent releases.  As an external library, it would also compete as a<br>
peer with other packages offering a similar level of abstraction, rather<br>
than the asymmetric relationship of a high-level opinionated abstraction<br>
masquerading as being part of the middleware upon which its rightful<br>
"peers" depend.<br>
<br>
I think a good way to evaluate scope is to ask whether we would accept<br>
the code if it were submitted by an outsider with no prior history<br>
developing PETSc.  If it is quality code that is in scope, there should<br>
be no question.  I think this would be considered out of scope, but I'm<br>
just one person.  What does everyone else think?<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>