On Wed, Feb 1, 2012 at 1:26 PM, Roy Stogner wrote:
>
>
> On Wed, 1 Feb 2012, John Peterson wrote:
>
>> On Wed, Feb 1, 2012 at 12:59 PM, Kirk, Benjamin (JSC-EG311)
>> wrote:
>>>
>>> I wonder if all this confusion is telling us something, that perhaps
>>> we've
>>> overloaded the functionality in a
>> Yep, this is what I was thinking as well. Probably close_to_point()
>> is the more general, so contains_point() would call it...
>
> I like this, except I'd leave tol=default_tolerance in contains_point.
Agreed. literary license in the syntax - I apologize. What I meant by
"really, I'm ser
On Wed, 1 Feb 2012, John Peterson wrote:
On Wed, Feb 1, 2012 at 12:59 PM, Kirk, Benjamin (JSC-EG311)
wrote:
I wonder if all this confusion is telling us something, that perhaps we've
overloaded the functionality in a pretty obtuse way?
Perhaps (at least from the public: perspective) we sh
On Wed, Feb 1, 2012 at 12:59 PM, Kirk, Benjamin (JSC-EG311)
wrote:
> I wonder if all this confusion is telling us something, that perhaps we've
> overloaded the functionality in a pretty obtuse way?
>
> Perhaps (at least from the public: perspective) we should implement a few
> functions that ar
I wonder if all this confusion is telling us something, that perhaps we've
overloaded the functionality in a pretty obtuse way?
Perhaps (at least from the public: perspective) we should implement a few
functions that are more clear:
contains_point(p); // really, i'm serious
close_to_point(p, to
On Wed, Feb 1, 2012 at 12:27 PM, Roy Stogner wrote:
>
>
> On Wed, 1 Feb 2012, John Peterson wrote:
>
>> A related question is: do we want contains_point() to return "true" in
>> cases where the point is definitely outside the element (to within
>> floating point tolerance), but is "inside" the ele
On Wed, 1 Feb 2012, John Peterson wrote:
> A related question is: do we want contains_point() to return "true" in
> cases where the point is definitely outside the element (to within
> floating point tolerance), but is "inside" the element (to within
> user-specified tolerance)?
My first inclan
On Wed, 1 Feb 2012, John Peterson wrote:
On Wed, Feb 1, 2012 at 11:56 AM, Kirk, Benjamin (JSC-EG311)
wrote:
Perhaps. How about replicating the behavior of libmesh_do_once, but
with a static std::set (and corresponding mutex to avoid
threaded STL problems) rather than with a single static b
On Wed, 1 Feb 2012, Dmitry Karpeev wrote:
> PETSc isn't shy about changing the API every release :-)
Oh, believe me, we know... are you mentioning this to persuade *for*
or *against* backwards-incompatible API changes? ;-)
> We tend to thing it's the right thing to do, if used sparingly.
Ever
On Wed, Feb 1, 2012 at 11:56 AM, Kirk, Benjamin (JSC-EG311)
wrote:
>
>>> To me that's more confusing than the current approach or the
>>> all-in-debug/nothing-in-opt approach.
>>
>> Perhaps. How about replicating the behavior of libmesh_do_once, but
>> with a static std::set (and corresponding mu
> We tend to thing it's the right thing to do, if used sparingly.
I'm all for it, but I appreciate that the discussion has converged on the
decision.
Most importantly (based on my personal experience with PETSc!) it should be
clearly spelled out in the release notes for the new version, as that's
On Feb 1, 2012, at 1:05 PM, Dmitry Karpeev wrote:
> PETSc isn't shy about changing the API every release :-)
> We tend to thing it's the right thing to do, if used sparingly.
>
> Dmitry.
>
> On Wed, Feb 1, 2012 at 12:57 PM, Derek Gaston wrote:
> I think so. Libmesh doesn't have so many users
PETSc isn't shy about changing the API every release :-)
We tend to thing it's the right thing to do, if used sparingly.
Dmitry.
On Wed, Feb 1, 2012 at 12:57 PM, Derek Gaston wrote:
> I think so. Libmesh doesn't have so many users that we shouldn't be
> allowed to evolve the API if there are j
On Wed, Feb 1, 2012 at 11:45 AM, Roy Stogner wrote:
>
> Copying this whole thing to libmesh-devel; I'd be happy to get
> additional opinions on either question.
A related question is: do we want contains_point() to return "true" in
cases where the point is definitely outside the element (to withi
I think so. Libmesh doesn't have so many users that we shouldn't be
allowed to evolve the API if there are justifiable causes.
I mean, we don't want to break everyone's code all the time, but we
shouldn't be so beholden to the old API just for the cause of backward
compatibility.
Derek
Sent fro
>> To me that's more confusing than the current approach or the
>> all-in-debug/nothing-in-opt approach.
>
> Perhaps. How about replicating the behavior of libmesh_do_once, but
> with a static std::set (and corresponding mutex to avoid
> threaded STL problems) rather than with a single static bo
On Wed, 1 Feb 2012, John Peterson wrote:
On Wed, Feb 1, 2012 at 11:00 AM, Roy Stogner wrote:
On Wed, 1 Feb 2012, John Peterson wrote:
We've had a request here to only print out the poor Newton convergence
info in FE::inverse_map() when in DEBUG mode (see attached patch).
Apparently they h
On Tue, 31 Jan 2012, Derek Gaston wrote:
Also: Screw backward compatibility. libMesh has been moving away from function
pointer stuff for a while (like Ben's new NonlinearSystem stuff).
Let's move to an all object oriented interface
Does "Screw backward compatibility in favor of OOP" exten
On Tue, 31 Jan 2012, Derek Gaston wrote:
Personally... just force people to inherit from the base class and
override virtuals. It's not _that_ much work That's what we do
in MOOSE and it's been working well
Also: Screw backward compatibility. libMesh has been moving away
from funct
19 matches
Mail list logo
