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, 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
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
>> 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
12 matches
Mail list logo
