I made a pull request related to this.
If the PointLocatorTree doesn't find the element, I use a linear search
over the mesh with Elem::close_to_point as a back-up. It works well for
me. It's slower than the tree, of course, but it's only a back-up so
seems fine to me. Also, we already had a li
I would find a bit more fuzziness here to be useful myself
Derek
On Tue, Jul 15, 2014 at 8:53 PM, David Knezevic
wrote:
>
> On 07/15/2014 10:51 PM, Roy Stogner wrote:
> >
> > On Tue, 15 Jul 2014, David Knezevic wrote:
> >
> >> I use MeshFunction a lot, it's very helpful. But sometimes due
On 07/15/2014 10:51 PM, Roy Stogner wrote:
>
> On Tue, 15 Jul 2014, David Knezevic wrote:
>
>> I use MeshFunction a lot, it's very helpful. But sometimes due to
>> rounding error, I evaluate a MeshFunction at a point just outside the
>> mesh, and hence the evaluation fails.
>>
>> I'd like to preve
On Tue, 15 Jul 2014, David Knezevic wrote:
> I use MeshFunction a lot, it's very helpful. But sometimes due to
> rounding error, I evaluate a MeshFunction at a point just outside the
> mesh, and hence the evaluation fails.
>
> I'd like to prevent this type of failure.
>
> I was thinking of pertur
I use MeshFunction a lot, it's very helpful. But sometimes due to
rounding error, I evaluate a MeshFunction at a point just outside the
mesh, and hence the evaluation fails.
I'd like to prevent this type of failure.
I was thinking of perturbing the evaluation point in various directions
(p + (
I tried running in the debug mode (should have done that earlier) and the code
aborted with the following error.
No index 128 in ghosted vector.
Vector contains [1352,2604)
And empty ghost array.
[1] ./include/libmesh/petsc_vector.h, line 1176, compiled May 22 2013 at
22:27:31
It also was tr
Put another way, solution contains storage for remote entries but it cannot
keep them in sync under all usage cases (1) for performance reasons and (2) to
avoid parallel deadlocks.
So depending on when you are accessing it the remote values may be stale,
leading to chaos.
-Ben
On May 24,
What are you trying to do? There are many scenarios where this could
fail... and some where it might succeed.
Derek
Sent from my iPad
On May 24, 2013, at 8:02 AM, Manav Bhatia wrote:
>
>
> On May 24, 2013, at 9:58 AM, Derek Gaston wrote:
>
>> Yes.
>>
>> Ok, well, MeshFunction itself doesn't
On May 24, 2013, at 9:58 AM, Derek Gaston wrote:
> Yes.
>
> Ok, well, MeshFunction itself doesn't care (as you found out)... but
> if you want to evaluate your solution in elements containing
> off-processor degrees of freedom then you need to serialize that
> vector.
>
But if the element i
Yes.
Ok, well, MeshFunction itself doesn't care (as you found out)... but
if you want to evaluate your solution in elements containing
off-processor degrees of freedom then you need to serialize that
vector.
Think of it this way: MeshFunction doesn't do parallel
communication... you are responsib
Hi,
Does MeshFunction expect the vector (input argument for constructor) to be
serialized and hold the global solution?
I am attempting to use the class in my code. Passing it the system.solution
without serializing it is leading to nans as the interpolated solution at the
boundary of ea
On Thu, 6 Dec 2012, Ataollah Mesgarnejad wrote:
> I was wondering if there is any reasons for MeshFunction::gradient not to
> work with C1 (Clough) elements?
In theory, it should work fine. If anything I'd expect it to work
*better* for C1 elements, since the results would always be
well-defin
Dear all,
I was wondering if there is any reasons for MeshFunction::gradient not to work
with C1 (Clough) elements?
Thanks,
Ata
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs a
Dear all,
Can someone please briefly explain how to use MeshFunction to me? I've been
digging the mailing list archives and
./src/error_estimation/exact_error_estimator.C to understand it but I'm still
hazy on how it use it?
This is what I intend to do I want to get the L-2 projection of a so
Dear Roy,
On Mon, 12 Jan 2009, Roy Stogner wrote:
> On Mon, 12 Jan 2009, Tim Kroeger wrote:
>
>> At the end of my application, I want to evaluate the computed solution
>> at a number of points (which cannot be assumed to be grid nodes).
>> Since I only want to write the values to a file, it suffi
On Mon, 12 Jan 2009, Derek Gaston wrote:
> On Jan 12, 2009, at 10:05 AM, Roy Stogner wrote:
>
>> Really, what we need is to properly parallelize MeshFunction, but I'm
>> not sure what the right API is to do that with MPI. If processor A
>> wants to evaluate the function on a point in processor B
On Jan 12, 2009, at 10:05 AM, Roy Stogner wrote:
> Really, what we need is to properly parallelize MeshFunction, but I'm
> not sure what the right API is to do that with MPI. If processor A
> wants to evaluate the function on a point in processor B's elements,
> processor B (which probably has a
On Mon, 12 Jan 2009, Tim Kroeger wrote:
> At the end of my application, I want to evaluate the computed solution
> at a number of points (which cannot be assumed to be grid nodes).
> Since I only want to write the values to a file, it suffices to do
> this on one processor.
>
> My idea was:
>
> 1
Dear all,
At the end of my application, I want to evaluate the computed solution
at a number of points (which cannot be assumed to be grid nodes).
Since I only want to write the values to a file, it suffices to do
this on one processor.
My idea was:
1. Localize.
2. On all processors except #0
19 matches
Mail list logo
