Re: [firedrake] Fwd: Point evaluation / PointNotInDomainError
Strange, because your script works for me! (both with and without the tolerance arguments, for what it's worth) [image: image.png] I guess you could test increasing the tolerance further, e.g. 1e-6 or 1e-4 If that still doesn't work, all I can suggest are obvious things like checking your firedrake is up to date, etc. [Note that the point you picked (0.05, 0.05, 0.05) is on the boundary between two cells in the y-direction, so it's not completely surprising that this has happened. In particular, if you are using a DG function space, the value there isn't well-defined] Cheers, Andrew On Sun, 14 Jun 2020 at 00:01, Rodrigo Piccinini <rbpiccinini@gmail.com> wrote:
Forgot to c/c the mailing list.
---------- Forwarded message --------- De: Rodrigo Piccinini <rbpiccinini@gmail.com> Date: sáb., 13 de jun. de 2020 às 19:40 Subject: Re: [firedrake] Point evaluation / PointNotInDomainError To: Andrew McRae <andrew.mcrae@physics.ox.ac.uk>
Hi, Andrew.
Thanks for the answer. I've attached a simplified example of what I'm doing.
This reproduces the error I still get.
[image: image.png]
Em sáb., 13 de jun. de 2020 às 17:14, Andrew McRae < andrew.mcrae@physics.ox.ac.uk> escreveu:
Hi Rodrigo,
Are you using the "f.at(...)" syntax, per https://www.firedrakeproject.org/point-evaluation.html ?
If so, you can pass in an extra argument *tolerance*, such as tolerance=1e-8
Under the hood, there are some calculations to see if the point is in a particular cell. If the point requested is on the boundary of the domain, or on the boundary between cells, due to numerical precision issues, it may happen that all nearby cells think the point is not in that cell. There is a default tolerance (of, I believe, 1e-14) to allow for this, but sometimes this is not enough.
If increasing this to 1e-8 doesn't work, there's probably something else going wrong!
Cheers, Andrew
On Sat, 13 Jun 2020 at 20:22, Rodrigo Piccinini <rbpiccinini@gmail.com> wrote:
Hello,
I'm getting the PointNotInDomainError when trying to compute a point evaluation in a extruded mesh. I've tried different coordinates that are inside a cell, but I keep having the same problem.
I'm using a DG scheme of 0 degree, so that values are constant inside a cell. Is there a workaround to get a cell value?
Currently, I'm getting it from the vtk exported file, but it takes much more time.
Thanks in advance for your help! -- Rodrigo
--
-- Rodrigo
--
-- Rodrigo
Hi, Andrew. Thanks for the help! I'll try to rebuild Firedrake. I was avoiding that because it takes some time on my computer. I think the point is in the cell centroid because I've picked coordinates that are half the cell spacing in the three directions. Isn't that correct? Em sáb., 13 de jun. de 2020 às 22:46, Andrew McRae < andrew.mcrae@physics.ox.ac.uk> escreveu:
Strange, because your script works for me! (both with and without the tolerance arguments, for what it's worth)
[image: image.png]
I guess you could test increasing the tolerance further, e.g. 1e-6 or 1e-4
If that still doesn't work, all I can suggest are obvious things like checking your firedrake is up to date, etc.
[Note that the point you picked (0.05, 0.05, 0.05) is on the boundary between two cells in the y-direction, so it's not completely surprising that this has happened. In particular, if you are using a DG function space, the value there isn't well-defined]
Cheers, Andrew
On Sun, 14 Jun 2020 at 00:01, Rodrigo Piccinini <rbpiccinini@gmail.com> wrote:
Forgot to c/c the mailing list.
---------- Forwarded message --------- De: Rodrigo Piccinini <rbpiccinini@gmail.com> Date: sáb., 13 de jun. de 2020 às 19:40 Subject: Re: [firedrake] Point evaluation / PointNotInDomainError To: Andrew McRae <andrew.mcrae@physics.ox.ac.uk>
Hi, Andrew.
Thanks for the answer. I've attached a simplified example of what I'm doing.
This reproduces the error I still get.
[image: image.png]
Em sáb., 13 de jun. de 2020 às 17:14, Andrew McRae < andrew.mcrae@physics.ox.ac.uk> escreveu:
Hi Rodrigo,
Are you using the "f.at(...)" syntax, per https://www.firedrakeproject.org/point-evaluation.html ?
If so, you can pass in an extra argument *tolerance*, such as tolerance=1e-8
Under the hood, there are some calculations to see if the point is in a particular cell. If the point requested is on the boundary of the domain, or on the boundary between cells, due to numerical precision issues, it may happen that all nearby cells think the point is not in that cell. There is a default tolerance (of, I believe, 1e-14) to allow for this, but sometimes this is not enough.
If increasing this to 1e-8 doesn't work, there's probably something else going wrong!
Cheers, Andrew
On Sat, 13 Jun 2020 at 20:22, Rodrigo Piccinini <rbpiccinini@gmail.com> wrote:
Hello,
I'm getting the PointNotInDomainError when trying to compute a point evaluation in a extruded mesh. I've tried different coordinates that are inside a cell, but I keep having the same problem.
I'm using a DG scheme of 0 degree, so that values are constant inside a cell. Is there a workaround to get a cell value?
Currently, I'm getting it from the vtk exported file, but it takes much more time.
Thanks in advance for your help! -- Rodrigo
--
-- Rodrigo
--
-- Rodrigo
-- -- Rodrigo
Rebuilding Firedrake solved the problem. Thanks! Em sáb, 13 de jun de 2020 23:30, Rodrigo Piccinini <rbpiccinini@gmail.com> escreveu:
Hi, Andrew. Thanks for the help! I'll try to rebuild Firedrake. I was avoiding that because it takes some time on my computer.
I think the point is in the cell centroid because I've picked coordinates that are half the cell spacing in the three directions. Isn't that correct?
Em sáb., 13 de jun. de 2020 às 22:46, Andrew McRae < andrew.mcrae@physics.ox.ac.uk> escreveu:
Strange, because your script works for me! (both with and without the tolerance arguments, for what it's worth)
[image: image.png]
I guess you could test increasing the tolerance further, e.g. 1e-6 or 1e-4
If that still doesn't work, all I can suggest are obvious things like checking your firedrake is up to date, etc.
[Note that the point you picked (0.05, 0.05, 0.05) is on the boundary between two cells in the y-direction, so it's not completely surprising that this has happened. In particular, if you are using a DG function space, the value there isn't well-defined]
Cheers, Andrew
On Sun, 14 Jun 2020 at 00:01, Rodrigo Piccinini <rbpiccinini@gmail.com> wrote:
Forgot to c/c the mailing list.
---------- Forwarded message --------- De: Rodrigo Piccinini <rbpiccinini@gmail.com> Date: sáb., 13 de jun. de 2020 às 19:40 Subject: Re: [firedrake] Point evaluation / PointNotInDomainError To: Andrew McRae <andrew.mcrae@physics.ox.ac.uk>
Hi, Andrew.
Thanks for the answer. I've attached a simplified example of what I'm doing.
This reproduces the error I still get.
[image: image.png]
Em sáb., 13 de jun. de 2020 às 17:14, Andrew McRae < andrew.mcrae@physics.ox.ac.uk> escreveu:
Hi Rodrigo,
Are you using the "f.at(...)" syntax, per https://www.firedrakeproject.org/point-evaluation.html ?
If so, you can pass in an extra argument *tolerance*, such as tolerance=1e-8
Under the hood, there are some calculations to see if the point is in a particular cell. If the point requested is on the boundary of the domain, or on the boundary between cells, due to numerical precision issues, it may happen that all nearby cells think the point is not in that cell. There is a default tolerance (of, I believe, 1e-14) to allow for this, but sometimes this is not enough.
If increasing this to 1e-8 doesn't work, there's probably something else going wrong!
Cheers, Andrew
On Sat, 13 Jun 2020 at 20:22, Rodrigo Piccinini <rbpiccinini@gmail.com> wrote:
Hello,
I'm getting the PointNotInDomainError when trying to compute a point evaluation in a extruded mesh. I've tried different coordinates that are inside a cell, but I keep having the same problem.
I'm using a DG scheme of 0 degree, so that values are constant inside a cell. Is there a workaround to get a cell value?
Currently, I'm getting it from the vtk exported file, but it takes much more time.
Thanks in advance for your help! -- Rodrigo
--
-- Rodrigo
--
-- Rodrigo
--
-- Rodrigo
participants (2)
-
Andrew McRae
-
Rodrigo Piccinini