<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 7, 2014 at 5:11 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>
<br>
> As far as I know, neither can do FV stuff which this is going to<br>
> do.<br>
<br>
</div>Where are your Riemann solve, characteristic reconstruction, and<br>
boundary conditions interfaces?  You already used the generic namespace<br>
for a volumetric term that doesn't even exist in FV formulations.</blockquote><div><br></div><div>Its in PetscFV. PetscProblem is supposed to hold both types. I can only work</div><div>so fast, and I am doing the FEM example first.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> Maybe MOOSE does. However, neither of those has good integration with<br>
> the solver (I have discussed this personally with Roy and Derek and<br>
> they agree).<br>
<br>
</div>You have to be able to formulate a similar scope of problems before you<br>
get to argue fine points of supporting geometric multigrid and the like.<br>
FWIW, it does not support the solve structure we use in pTatin so gives<br>
up significant performance relative to existing packages that use solver<br>
algorithms you want.<br></blockquote><div><br></div><div>I asked you to help with this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
>> think this belongs in PETSc, definitely not in such prominent namespace.<br>
>><br>
><br>
> I don't know why you think this is so bad. I picked a name because I needed<br>
> a name. Its not DM, its a collection of DMs.<br>
<br>
</div>It's a very framework-style name with generic connotations used for<br>
something extremely specific.</blockquote><div><br></div><div>I do not think its for something that specific. It is to hold a collection of pointwise</div><div>evaluation routines + discretizations. What is better than "problem"?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
>> 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>
>><br>
><br>
> We have a bunch of stuff that is not completely stable. I am not sure<br>
> what this kind of conservatism buys us.<br>
<br>
</div>Exploratory programming in a release using a prominent namespace will<br></blockquote><div><br></div><div>I think "prominent" here is misguided.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

encourage people to try using it, then have a bad experience when it (a)<br>
does not work for their problem and (b) is changed soon after the<br>
release.  I would rather that exploration happen in a different package<br>
that users can opt into.<br><br>
I like developing library code in PETSc, and often look for ways to<br>
formulate a new idea to make it appropriate for PETSc.  But some things<br>
just make more sense in a separate package.  If there is a technical<br>
problem with distributing such a package, we should solve that problem.<br>
</blockquote></div><br>Its not a lot of code, its very useful for exactly the people that use our package,</div><div class="gmail_extra">it disrupts none of the existing workflow, and its got a fair number of test compared</div>
<div class="gmail_extra">to other stuff we have released.</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>