"last-attempt" length

[Jeremy Theler]

Dear all

I write here so it is somehow recorded, but this question is for Ramiro
and/or other of the ones that made at leas a commit to the code...

Does anyone has a problem with increasing the factor in this commit?

https://bitbucket.org/seamplex/wasora/commits/d4c4ac4b89358f110b8d2f9e044626d0e53957a6

I remember that large values for this parameter have other non-
desirable results appart from the performance issue, but I cannot
recall them.

Maybe we should put this value into a modifiable wasora variable?


Regards
--
jeremy theler
www.seamplex.com

[César Pablo Camusso]

Dear Germán,

I do not have any problem. If I had a problem with that, I do not remember.
I think the proposal (put that value in a variable) is good because each one can customize the variable to fit the problem.

Regards.

--

You received this message because you are subscribed to the Google Groups "wasora" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wasora+unsub...@seamplex.com.

To post to this group, send email to was...@seamplex.com.

Visit this group at https://groups.google.com/a/seamplex.com/group/wasora/.

To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/1540247528.1626.3.camel%40seamplex.com.

For more options, visit https://groups.google.com/a/seamplex.com/d/optout.

[Ramiro Vignolo]

Hi Jeremy,

please find below my comments.

Thanks!

On 22Oct, 2018, at 19:32, Jeremy Theler <jer...@seamplex.com> wrote:

Dear all

I write here so it is somehow recorded, but this question is for Ramiro
and/or other of the ones that made at leas a commit to the code...

Does anyone has a problem with increasing the factor in this commit?

The ray tracing algorithm will work without any problem using this increased factor.

https://bitbucket.org/seamplex/wasora/commits/d4c4ac4b89358f110b8d2f9e044626d0e53957a6

I remember that large values for this parameter have other non-
desirable results appart from the performance issue, but I cannot
recall them.

On the contrary, small values have non-desirable results for the ray tracing algorithm. If the correct element is not reached, then it will not find the element.

Maybe we should put this value into a modifiable wasora variable?

That would be good. However, a different approach could be to recursively increase it if no element is found until an element is found or a number of iterations is reached. 

I do not get the last part of the function (from line 310). If no element is found, you still try to get an element. Is that necessary instead of printing an error: element not found? I believe this approach  could also retrieve NULL if (distance > DEFAULT_MULTIDIM_INTERPOLATION_THRESHOLD).

Please, take a look at the comments in track.c file (here) at lines 383 and, particularly, at line 418.

Regards
--
jeremy theler
www.seamplex.com

--
You received this message because you are subscribed to the Google Groups "wasora" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wasora+un...@seamplex.com.

[Jeremy Theler]

Does anyone has a problem with increasing the factor in this
> > commit?
> >
>
> The ray tracing algorithm will work without any problem using this
> increased factor.

ok

>
> > https://bitbucket.org/seamplex/wasora/commits/d4c4ac4b89358f110b8d2
> > f9e044626d0e53957a6

> >
> > I remember that large values for this parameter have other non-
> > desirable results appart from the performance issue, but I cannot
> > recall them.
> >
>
> On the contrary, small values have non-desirable results for the ray
> tracing algorithm. If the correct element is not reached, then it
> will not find the element.

I know, but sometimes the idea is not to find an element for example if
the point is outside the domain.

>
> > Maybe we should put this value into a modifiable wasora variable?
> >
>
> That would be good. However, a different approach could be to
> recursively increase it if no element is found until an element is
> found or a number of iterations is reached. 

This makes no sense. If you try a length of say of 1 and 10 nodes are
returned, if you then try a length of 2 then the first 10 nodes are
returned again plus more. Just having a reasonable value of the length
and a single iteration should be enough.

> I do not get the last part of the function (from line 310). If no
> element is found, you still try to get an element. Is that necessary
> instead of printing an error: element not found? I believe this
> approach  could also retrieve NULL if (distance >
> DEFAULT_MULTIDIM_INTERPOLATION_THRESHOLD).

It depends what you want. Sometimes you do not want to raise an error
but return a reasonable value.

>
> Please, take a look at the comments in track.c file (here) at lines
> 383 and, particularly, at line 418.

What happens if a point lies exactly on (or near) one of the surfaces
of the element? I'd rather return one element than nothing, that's why
there is a tolerance.

Maybe instead of using eps we should define a new variable for this
tolerance, and define another variable for this "last-attempt" length.

--
jeremy

[Ramiro Vignolo]

On 24Oct, 2018, at 16:38, Jeremy Theler <jer...@seamplex.com> wrote:

Does anyone has a problem with increasing the factor in this

commit?

The ray tracing algorithm will work without any problem using this
increased factor.

ok

https://bitbucket.org/seamplex/wasora/commits/d4c4ac4b89358f110b8d2
f9e044626d0e53957a6

I remember that large values for this parameter have other non-
desirable results appart from the performance issue, but I cannot
recall them.

On the contrary, small values have non-desirable results for the ray
tracing algorithm. If the correct element is not reached, then it
will not find the element.

I know, but sometimes the idea is not to find an element for example if
the point is outside the domain.

Maybe we should put this value into a modifiable wasora variable?

That would be good. However, a different approach could be to
recursively increase it if no element is found until an element is
found or a number of iterations is reached. 

This makes no sense. If you try a length of say of 1 and 10 nodes are
returned, if you then try a length of 2 then the first 10 nodes are
returned again plus more. Just having a reasonable value of the length
and a single iteration should be enough.

ok. It made sense to me because the use of an unreasonable large length for all the searches (for example, now we are using 7*mesh_subtract_module(x, x_nearest), which might be large) could always retrieve several elements. In the other hand, what I proposed would retrieve several elements but for only those cases where the mesh is deformed. 

However, lets use a wasora special variable! For me that is a good approach!

I do not get the last part of the function (from line 310). If no
element is found, you still try to get an element. Is that necessary
instead of printing an error: element not found? I believe this
approach  could also retrieve NULL if (distance >
DEFAULT_MULTIDIM_INTERPOLATION_THRESHOLD).

It depends what you want. Sometimes you do not want to raise an error
but return a reasonable value.

Please, take a look at the comments in track.c file (here) at lines
383 and, particularly, at line 418.

What happens if a point lies exactly on (or near) one of the surfaces
of the element? I'd rather return one element than nothing, that's why
there is a tolerance.

Maybe instead of using eps we should define a new variable for this
tolerance, and define another variable for this "last-attempt" length.

Okay, that would be nice.

--
jeremy

--
You received this message because you are subscribed to the Google Groups "wasora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wasora+un...@seamplex.com.
To post to this group, send email to was...@seamplex.com.
Visit this group at https://groups.google.com/a/seamplex.com/group/wasora/.

To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/1540413504.1615.2.camel%40seamplex.com.

[jeremy theler]

On Tue, Oct 30, 2018 at 5:27 PM Ramiro Vignolo <ramiro...@gmail.com> wrote:

Maybe we should put this value into a modifiable wasora variable?

That would be good. However, a different approach could be to
recursively increase it if no element is found until an element is
found or a number of iterations is reached. 

This makes no sense. If you try a length of say of 1 and 10 nodes are
returned, if you then try a length of 2 then the first 10 nodes are
returned again plus more. Just having a reasonable value of the length
and a single iteration should be enough.

ok. It made sense to me because the use of an unreasonable large length for all the searches (for example, now we are using 7*mesh_subtract_module(x, x_nearest), which might be large) could always retrieve several elements. In the other hand, what I proposed would retrieve several elements but for only those cases where the mesh is deformed. 

I see. I was assuming that the elements returned in x_nearest were sorted out, but now I think they are not. I am not sure how to choose a one-fits-all value instead of 7.

 

However, lets use a wasora special variable! For me that is a good approach!

ok

I do not get the last part of the function (from line 310). If no
element is found, you still try to get an element. Is that necessary
instead of printing an error: element not found? I believe this
approach  could also retrieve NULL if (distance >
DEFAULT_MULTIDIM_INTERPOLATION_THRESHOLD).

It depends what you want. Sometimes you do not want to raise an error
but return a reasonable value.

Please, take a look at the comments in track.c file (here) at lines
383 and, particularly, at line 418.

What happens if a point lies exactly on (or near) one of the surfaces
of the element? I'd rather return one element than nothing, that's why
there is a tolerance.

Maybe instead of using eps we should define a new variable for this
tolerance, and define another variable for this "last-attempt" length.

Okay, that would be nice.

that would be on your side :-)

--
jeremy

--
You received this message because you are subscribed to the Google Groups "wasora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wasora+un...@seamplex.com.
To post to this group, send email to was...@seamplex.com.
Visit this group at https://groups.google.com/a/seamplex.com/group/wasora/.

To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/1540413504.1615.2.camel%40seamplex.com.

For more options, visit https://groups.google.com/a/seamplex.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "wasora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wasora+un...@seamplex.com.
To post to this group, send email to was...@seamplex.com.
Visit this group at https://groups.google.com/a/seamplex.com/group/wasora/.

To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/50D83E5A-D47F-4E6F-9D7C-6D22CEC37BA2%40gmail.com.

For more options, visit https://groups.google.com/a/seamplex.com/d/optout.

--

--

jeremy theler

www.seamplex.com