Hi guys, I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be: rx = min( abs( x - center_x ), abs( x - center_x - domain_x) ) I think the best way to do this is to set up a NumPy ufunc http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne... that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work? -Matt
Hi guys,
Can somebody review this? I chatted with Jeff, and I believe it is
correct for periodic boxes, but I need somebody to look at it before I
commit it, as it is a rather crucial aspect of yt. This changes the
way radius is calculated and should now work with periodic boundary
conditions.
Here's the new field definition:
def _NewRadius(field, data):
center = data.get_field_parameter("center")
DW = data.pf["DomainRightEdge"] - data.pf["DomainLeftEdge"]
radius = na.zeros(data["x"].shape, dtype='float64')
for i, ax in enumerate('xyz'):
r = na.abs(data[ax] - center[i])
radius += na.minimum(r, na.abs(DW[i]-r))**2.0
na.sqrt(radius, radius)
return radius
the final argument in na.sqrt is the 'out' argument, to avoid temporary arrays.
I've committed a sample script here:
http://paste.enzotools.org/show/101/
which loads up a data dump, calculates the radius from [0.1, 0.1, 0.1]
at all points in the root grid, then plots the output. It gives
correct min & max values for the radius.
If I can get somebody else to sign off on this, I will commit the
necessary changes to _Radius and _ParticleRadius, as well as grid &
point selection for spheres. We'll then have a fully-periodic
profiler, which will close #165.
-Matt
On Thu, Apr 16, 2009 at 11:39 AM, Matthew Turk
Hi guys,
I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be:
rx = min( abs( x - center_x ), abs( x - center_x - domain_x) )
I think the best way to do this is to set up a NumPy ufunc
http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne...
that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work?
-Matt
Oops, just as a note, there's an error in the paste -- the second plot
of "NewRadius" should be of "Radius".
Thanks guys...
-Matt
On Fri, Apr 17, 2009 at 7:16 PM, Matthew Turk
Hi guys,
Can somebody review this? I chatted with Jeff, and I believe it is correct for periodic boxes, but I need somebody to look at it before I commit it, as it is a rather crucial aspect of yt. This changes the way radius is calculated and should now work with periodic boundary conditions.
Here's the new field definition:
def _NewRadius(field, data): center = data.get_field_parameter("center") DW = data.pf["DomainRightEdge"] - data.pf["DomainLeftEdge"] radius = na.zeros(data["x"].shape, dtype='float64') for i, ax in enumerate('xyz'): r = na.abs(data[ax] - center[i]) radius += na.minimum(r, na.abs(DW[i]-r))**2.0 na.sqrt(radius, radius) return radius
the final argument in na.sqrt is the 'out' argument, to avoid temporary arrays.
I've committed a sample script here:
http://paste.enzotools.org/show/101/
which loads up a data dump, calculates the radius from [0.1, 0.1, 0.1] at all points in the root grid, then plots the output. It gives correct min & max values for the radius.
If I can get somebody else to sign off on this, I will commit the necessary changes to _Radius and _ParticleRadius, as well as grid & point selection for spheres. We'll then have a fully-periodic profiler, which will close #165.
-Matt
On Thu, Apr 16, 2009 at 11:39 AM, Matthew Turk
wrote: Hi guys,
I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be:
rx = min( abs( x - center_x ), abs( x - center_x - domain_x) )
I think the best way to do this is to set up a NumPy ufunc
http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne...
that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work?
-Matt
I just tried your script with some data I have here. I've attached the
images. I can't really tell if this is right or not. I think another way
to test this would be to do a projection with a periodic sphere as the
source object. If you throw a sphere that overlaps the domain boundary to a
projection, it should be quite clear if it's doing what it's supposed to.
Does that sound right?
Britton
On Fri, Apr 17, 2009 at 8:17 PM, Matthew Turk
Oops, just as a note, there's an error in the paste -- the second plot of "NewRadius" should be of "Radius".
Thanks guys...
-Matt
On Fri, Apr 17, 2009 at 7:16 PM, Matthew Turk
wrote: Hi guys,
Can somebody review this? I chatted with Jeff, and I believe it is correct for periodic boxes, but I need somebody to look at it before I commit it, as it is a rather crucial aspect of yt. This changes the way radius is calculated and should now work with periodic boundary conditions.
Here's the new field definition:
def _NewRadius(field, data): center = data.get_field_parameter("center") DW = data.pf["DomainRightEdge"] - data.pf["DomainLeftEdge"] radius = na.zeros(data["x"].shape, dtype='float64') for i, ax in enumerate('xyz'): r = na.abs(data[ax] - center[i]) radius += na.minimum(r, na.abs(DW[i]-r))**2.0 na.sqrt(radius, radius) return radius
the final argument in na.sqrt is the 'out' argument, to avoid temporary arrays.
I've committed a sample script here:
http://paste.enzotools.org/show/101/
which loads up a data dump, calculates the radius from [0.1, 0.1, 0.1] at all points in the root grid, then plots the output. It gives correct min & max values for the radius.
If I can get somebody else to sign off on this, I will commit the necessary changes to _Radius and _ParticleRadius, as well as grid & point selection for spheres. We'll then have a fully-periodic profiler, which will close #165.
-Matt
On Thu, Apr 16, 2009 at 11:39 AM, Matthew Turk
wrote: Hi guys,
I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be:
rx = min( abs( x - center_x ), abs( x - center_x - domain_x) )
I think the best way to do this is to set up a NumPy ufunc
http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne...
that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work?
-Matt
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hm, this looks wrong to me. Clearly something I have not considered
-- over here myi mages look like the attached. What's the value for
the domain width? This is confusing to me, as I really thought it
would work!
Can you try with a projection? It should work, right through the
domain, and it should tell us what we're looking for. Or, jsut
straight-up slices of NewRadius. I'll try some stuff too.
On Fri, Apr 17, 2009 at 8:48 PM, Britton Smith
I just tried your script with some data I have here. I've attached the images. I can't really tell if this is right or not. I think another way to test this would be to do a projection with a periodic sphere as the source object. If you throw a sphere that overlaps the domain boundary to a projection, it should be quite clear if it's doing what it's supposed to. Does that sound right?
Britton
On Fri, Apr 17, 2009 at 8:17 PM, Matthew Turk
wrote: Oops, just as a note, there's an error in the paste -- the second plot of "NewRadius" should be of "Radius".
Thanks guys...
-Matt
On Fri, Apr 17, 2009 at 7:16 PM, Matthew Turk
wrote: Hi guys,
Can somebody review this? I chatted with Jeff, and I believe it is correct for periodic boxes, but I need somebody to look at it before I commit it, as it is a rather crucial aspect of yt. This changes the way radius is calculated and should now work with periodic boundary conditions.
Here's the new field definition:
def _NewRadius(field, data): center = data.get_field_parameter("center") DW = data.pf["DomainRightEdge"] - data.pf["DomainLeftEdge"] radius = na.zeros(data["x"].shape, dtype='float64') for i, ax in enumerate('xyz'): r = na.abs(data[ax] - center[i]) radius += na.minimum(r, na.abs(DW[i]-r))**2.0 na.sqrt(radius, radius) return radius
the final argument in na.sqrt is the 'out' argument, to avoid temporary arrays.
I've committed a sample script here:
http://paste.enzotools.org/show/101/
which loads up a data dump, calculates the radius from [0.1, 0.1, 0.1] at all points in the root grid, then plots the output. It gives correct min & max values for the radius.
If I can get somebody else to sign off on this, I will commit the necessary changes to _Radius and _ParticleRadius, as well as grid & point selection for spheres. We'll then have a fully-periodic profiler, which will close #165.
-Matt
On Thu, Apr 16, 2009 at 11:39 AM, Matthew Turk
wrote: Hi guys,
I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be:
rx = min( abs( x - center_x ), abs( x - center_x - domain_x) )
I think the best way to do this is to set up a NumPy ufunc
http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne...
that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work?
-Matt
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Okay, so suddenly it occurs to me -- if your domain width is 1.0, then
this is in fact just a subset of your domain, and it could be correct.
I forgot about parallel root grid IO. What happens if you plot a
slice through the center of the domain of the new field?
pc = PlotCollection(pf, center=[0.5,0.5,0.5])
pc.add_slice("NewRadius", 0)
pc.add_slice("Radius", 0)
pc.save("new")
That should show us if it's actually giving the right results or not.
Apologies; I completely forgot about decomposed root grids when I
wrote that script.
On Fri, Apr 17, 2009 at 9:01 PM, Matthew Turk
Hm, this looks wrong to me. Clearly something I have not considered -- over here myi mages look like the attached. What's the value for the domain width? This is confusing to me, as I really thought it would work!
Can you try with a projection? It should work, right through the domain, and it should tell us what we're looking for. Or, jsut straight-up slices of NewRadius. I'll try some stuff too.
On Fri, Apr 17, 2009 at 8:48 PM, Britton Smith
wrote: I just tried your script with some data I have here. I've attached the images. I can't really tell if this is right or not. I think another way to test this would be to do a projection with a periodic sphere as the source object. If you throw a sphere that overlaps the domain boundary to a projection, it should be quite clear if it's doing what it's supposed to. Does that sound right?
Britton
On Fri, Apr 17, 2009 at 8:17 PM, Matthew Turk
wrote: Oops, just as a note, there's an error in the paste -- the second plot of "NewRadius" should be of "Radius".
Thanks guys...
-Matt
On Fri, Apr 17, 2009 at 7:16 PM, Matthew Turk
wrote: Hi guys,
Can somebody review this? I chatted with Jeff, and I believe it is correct for periodic boxes, but I need somebody to look at it before I commit it, as it is a rather crucial aspect of yt. This changes the way radius is calculated and should now work with periodic boundary conditions.
Here's the new field definition:
def _NewRadius(field, data): center = data.get_field_parameter("center") DW = data.pf["DomainRightEdge"] - data.pf["DomainLeftEdge"] radius = na.zeros(data["x"].shape, dtype='float64') for i, ax in enumerate('xyz'): r = na.abs(data[ax] - center[i]) radius += na.minimum(r, na.abs(DW[i]-r))**2.0 na.sqrt(radius, radius) return radius
the final argument in na.sqrt is the 'out' argument, to avoid temporary arrays.
I've committed a sample script here:
http://paste.enzotools.org/show/101/
which loads up a data dump, calculates the radius from [0.1, 0.1, 0.1] at all points in the root grid, then plots the output. It gives correct min & max values for the radius.
If I can get somebody else to sign off on this, I will commit the necessary changes to _Radius and _ParticleRadius, as well as grid & point selection for spheres. We'll then have a fully-periodic profiler, which will close #165.
-Matt
On Thu, Apr 16, 2009 at 11:39 AM, Matthew Turk
wrote: Hi guys,
I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be:
rx = min( abs( x - center_x ), abs( x - center_x - domain_x) )
I think the best way to do this is to set up a NumPy ufunc
http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne...
that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work?
-Matt
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi guys,
I did a bunch of testing on this today and satisfied myself it was
correct. I also fixed a regression I introduced, clarified the
setting of field parameters, and then made AMRSpheres periodic. This
was committed in r1267. Code review is welcome!
-Matt
On Fri, Apr 17, 2009 at 9:10 PM, Matthew Turk
Okay, so suddenly it occurs to me -- if your domain width is 1.0, then this is in fact just a subset of your domain, and it could be correct. I forgot about parallel root grid IO. What happens if you plot a slice through the center of the domain of the new field?
pc = PlotCollection(pf, center=[0.5,0.5,0.5]) pc.add_slice("NewRadius", 0) pc.add_slice("Radius", 0) pc.save("new")
That should show us if it's actually giving the right results or not. Apologies; I completely forgot about decomposed root grids when I wrote that script.
On Fri, Apr 17, 2009 at 9:01 PM, Matthew Turk
wrote: Hm, this looks wrong to me. Clearly something I have not considered -- over here myi mages look like the attached. What's the value for the domain width? This is confusing to me, as I really thought it would work!
Can you try with a projection? It should work, right through the domain, and it should tell us what we're looking for. Or, jsut straight-up slices of NewRadius. I'll try some stuff too.
On Fri, Apr 17, 2009 at 8:48 PM, Britton Smith
wrote: I just tried your script with some data I have here. I've attached the images. I can't really tell if this is right or not. I think another way to test this would be to do a projection with a periodic sphere as the source object. If you throw a sphere that overlaps the domain boundary to a projection, it should be quite clear if it's doing what it's supposed to. Does that sound right?
Britton
On Fri, Apr 17, 2009 at 8:17 PM, Matthew Turk
wrote: Oops, just as a note, there's an error in the paste -- the second plot of "NewRadius" should be of "Radius".
Thanks guys...
-Matt
On Fri, Apr 17, 2009 at 7:16 PM, Matthew Turk
wrote: Hi guys,
Can somebody review this? I chatted with Jeff, and I believe it is correct for periodic boxes, but I need somebody to look at it before I commit it, as it is a rather crucial aspect of yt. This changes the way radius is calculated and should now work with periodic boundary conditions.
Here's the new field definition:
def _NewRadius(field, data): center = data.get_field_parameter("center") DW = data.pf["DomainRightEdge"] - data.pf["DomainLeftEdge"] radius = na.zeros(data["x"].shape, dtype='float64') for i, ax in enumerate('xyz'): r = na.abs(data[ax] - center[i]) radius += na.minimum(r, na.abs(DW[i]-r))**2.0 na.sqrt(radius, radius) return radius
the final argument in na.sqrt is the 'out' argument, to avoid temporary arrays.
I've committed a sample script here:
http://paste.enzotools.org/show/101/
which loads up a data dump, calculates the radius from [0.1, 0.1, 0.1] at all points in the root grid, then plots the output. It gives correct min & max values for the radius.
If I can get somebody else to sign off on this, I will commit the necessary changes to _Radius and _ParticleRadius, as well as grid & point selection for spheres. We'll then have a fully-periodic profiler, which will close #165.
-Matt
On Thu, Apr 16, 2009 at 11:39 AM, Matthew Turk
wrote: Hi guys,
I've been exploring the idea of changing radius to be correct for periodic boxes. Right now it is incorrect; each component (x,y,z) should not have a distance greater than 0.5 * domain_size. The easiest way to do this would be:
rx = min( abs( x - center_x ), abs( x - center_x - domain_x) )
I think the best way to do this is to set up a NumPy ufunc
http://docs.scipy.org/doc/numpy/user/c-info.beyond-basics.html#creating-a-ne...
that accepts three arrays, along with the center and the domain width, and then returns the radius. What do you all think? Alternatively, I'm thinking maybe just a regular function that gets the arrays and returns one would be better; the ufunc machinery is a bit complicated and I might get confused. Once I come up with it, will somebody be able to look over my work?
-Matt
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Britton Smith
-
Matthew Turk