<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 7, 2014 at 6:01 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>
> On Sat, Jun 7, 2014 at 5:11 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> 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>
>> 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.<br>
><br>
><br>
> Its in PetscFV. PetscProblem is supposed to hold both types. I can only work<br>
> so fast, and I am doing the FEM example first.<br>
<br>
</div>So it's not supported by the PetscProblem interface?</blockquote><div><br></div><div>I have not had time to code the implementation. The interface is (hopefully) fine.</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>
>> 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>
>><br>
><br>
> I asked you to help with this.<br>
<br>
</div>I pointed out that your interface can't do that algorithm and I showed<br>
you code that can. I'm not sure what you want me to do. Change your<br>
interface to be able to do that method fast, implying other data<br>
structure changes and possible loss of functionality that you want?</blockquote><div><br></div><div>Of course, there is nothing else to do but point out shortcomings. That makes things easy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> >> 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<br>
>> needed<br>
>> > a name. Its not DM, its a collection of DMs.<br>
>><br>
>> It's a very framework-style name with generic connotations used for<br>
>> something extremely specific.<br>
><br>
><br>
> I do not think its for something that specific. It is to hold a<br>
> collection of pointwise evaluation routines + discretizations. What is<br>
> better than "problem"?<br>
<br>
</div>H^1 semi-discrete-in-time quadrature-based method of weighted residuals<br>
without material models or boundary conditions. "Problem" is way too<br>
generic to be used for something so specific in PETSc.<br></blockquote><div><br></div><div>I do not agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
>> >> 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>
>> Exploratory programming in a release using a prominent namespace will<br>
>><br>
><br>
> I think "prominent" here is misguided.<br>
<br>
</div>How else would you describe it? I suggested<br>
DMMattsCoolDiscretizationTSSetIFunctionVolumetricQuadrature().</blockquote><div><br></div><div>Its not a DM.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
>> 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>
>><br>
><br>
> Its not a lot of code, its very useful for exactly the people that use<br>
> our package,<br>
<br>
</div>s/exactly the people/a subset of the people using H^1<br>
semi-discrete-in-time quadrature-based method of weighted residuals<br>
without material models or boundary conditions/</blockquote><div><br></div><div>Here you are just arguing to argue. There are many people who would benefit.</div><div>Should we have a survey?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
> it disrupts none of the existing workflow, and its got a fair number<br>
> of test compared to other stuff we have released.<br>
<br>
</div>Deal.II has lots of tests. Apart from the more restrictive license and<br>
language choice, why don't we include it in PETSc? It's currently more<br>
flexible than your interface. It can be a separate include so that it<br>
does not disrupt existing workflow.<br>
</blockquote></div><br>Yep, I am for including Deal.II. Its now the only logical thing to do. I am also for</div><div class="gmail_extra">counting all its lines of generated code in our SLOC count. We will win another</div>
<div class="gmail_extra">DOE award.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> Matt</div><div class="gmail_extra"><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>