Hi all, I'd very much appreciate feedback on this YTEP: https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like... The related PR that starts implementing them is here: https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-... Two things that I think need some bikeshedding -- histogram and the step argument to slicing. -Matt
Hi everyone,
Thanks for the feedback -- I've made a bunch of changes and additions.
One thing I wanted to ask was about 3D slicing that includes steps.
For instance, in numpy style:
ds = yt.load(...)
ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j,
(-2.5, 'km') : (2.5, 'km'): 64j]
this should return a 128x256x64 3D array. But, how do we generate that?
The obvious thing would be to do either covering grid or arbitrary
grids. The former requires alignment with cell boundaries, and the
latter currently only supports particles. I think "arbitrary_grid"
maps a lot more naturally to the situation, though. So it would
require implementing mesh fields in the arbitrary_grid object, which
is fine, but it's not clear to me the right *way* to do that. I think
the choice might be between nearest neighbor and trilinear
interpolation. So, for the *default* behavior, should we do:
* Trilinear interpolation (maybe nicer, but also subject to
crazytimes with stuff that isn't a volume quantity, like mass)
* Nearest neighbor (way, way faster, but also lower quality values in
many cases)?
My inclination is #2, but I wanted a sanity check...
-Matt
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk
Hi all,
I'd very much appreciate feedback on this YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
The related PR that starts implementing them is here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-...
Two things that I think need some bikeshedding -- histogram and the step argument to slicing.
-Matt
I'd say nearest neighbor. Then it's also a generalization of what the
FixedResolutionBuffer does.
On Friday, September 25, 2015, Matthew Turk
Hi everyone,
Thanks for the feedback -- I've made a bunch of changes and additions. One thing I wanted to ask was about 3D slicing that includes steps. For instance, in numpy style:
ds = yt.load(...) ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j, (-2.5, 'km') : (2.5, 'km'): 64j]
this should return a 128x256x64 3D array. But, how do we generate that?
The obvious thing would be to do either covering grid or arbitrary grids. The former requires alignment with cell boundaries, and the latter currently only supports particles. I think "arbitrary_grid" maps a lot more naturally to the situation, though. So it would require implementing mesh fields in the arbitrary_grid object, which is fine, but it's not clear to me the right *way* to do that. I think the choice might be between nearest neighbor and trilinear interpolation. So, for the *default* behavior, should we do:
* Trilinear interpolation (maybe nicer, but also subject to crazytimes with stuff that isn't a volume quantity, like mass) * Nearest neighbor (way, way faster, but also lower quality values in many cases)?
My inclination is #2, but I wanted a sanity check...
-Matt
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk
javascript:;> wrote: Hi all,
I'd very much appreciate feedback on this YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
The related PR that starts implementing them is here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-...
Two things that I think need some bikeshedding -- histogram and the step argument to slicing.
-Matt
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org javascript:; http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
How about default to one of the options, but have a kwarg to decide which
method to choose? I sort of like trilinear interp but I'm just thinking of
grid-based data. Maybe default to trilinear interp for grid-based
quantities and nearest neighbor for particle based quantities?
On Fri, Sep 25, 2015 at 4:46 PM, Nathan Goldbaum
I'd say nearest neighbor. Then it's also a generalization of what the FixedResolutionBuffer does.
On Friday, September 25, 2015, Matthew Turk
wrote: Hi everyone,
Thanks for the feedback -- I've made a bunch of changes and additions. One thing I wanted to ask was about 3D slicing that includes steps. For instance, in numpy style:
ds = yt.load(...) ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j, (-2.5, 'km') : (2.5, 'km'): 64j]
this should return a 128x256x64 3D array. But, how do we generate that?
The obvious thing would be to do either covering grid or arbitrary grids. The former requires alignment with cell boundaries, and the latter currently only supports particles. I think "arbitrary_grid" maps a lot more naturally to the situation, though. So it would require implementing mesh fields in the arbitrary_grid object, which is fine, but it's not clear to me the right *way* to do that. I think the choice might be between nearest neighbor and trilinear interpolation. So, for the *default* behavior, should we do:
* Trilinear interpolation (maybe nicer, but also subject to crazytimes with stuff that isn't a volume quantity, like mass) * Nearest neighbor (way, way faster, but also lower quality values in many cases)?
My inclination is #2, but I wanted a sanity check...
-Matt
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk
wrote: Hi all,
I'd very much appreciate feedback on this YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
The related PR that starts implementing them is here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-...
Two things that I think need some bikeshedding -- histogram and the step argument to slicing.
-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
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
Hi Cameron,
Yeah, a kwarg for the actual .arbitrary_grid would be great, but that
can't be expressed in the slicing notation (or rather, it can, but
it's unnatural). So getting the default is what I was hoping for; for
particle quantities, we'll just have it do the standard "deposit"
machinery which lets you do any type of interpolation you like, so
it's less of a thing.
-Matt
On Fri, Sep 25, 2015 at 7:13 PM, Cameron Hummels
How about default to one of the options, but have a kwarg to decide which method to choose? I sort of like trilinear interp but I'm just thinking of grid-based data. Maybe default to trilinear interp for grid-based quantities and nearest neighbor for particle based quantities?
On Fri, Sep 25, 2015 at 4:46 PM, Nathan Goldbaum
wrote: I'd say nearest neighbor. Then it's also a generalization of what the FixedResolutionBuffer does.
On Friday, September 25, 2015, Matthew Turk
wrote: Hi everyone,
Thanks for the feedback -- I've made a bunch of changes and additions. One thing I wanted to ask was about 3D slicing that includes steps. For instance, in numpy style:
ds = yt.load(...) ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j, (-2.5, 'km') : (2.5, 'km'): 64j]
this should return a 128x256x64 3D array. But, how do we generate that?
The obvious thing would be to do either covering grid or arbitrary grids. The former requires alignment with cell boundaries, and the latter currently only supports particles. I think "arbitrary_grid" maps a lot more naturally to the situation, though. So it would require implementing mesh fields in the arbitrary_grid object, which is fine, but it's not clear to me the right *way* to do that. I think the choice might be between nearest neighbor and trilinear interpolation. So, for the *default* behavior, should we do:
* Trilinear interpolation (maybe nicer, but also subject to crazytimes with stuff that isn't a volume quantity, like mass) * Nearest neighbor (way, way faster, but also lower quality values in many cases)?
My inclination is #2, but I wanted a sanity check...
-Matt
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk
wrote: Hi all,
I'd very much appreciate feedback on this YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
The related PR that starts implementing them is here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-...
Two things that I think need some bikeshedding -- histogram and the step argument to slicing.
-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
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I've implemented arbitrary_grid pulling from fluid fields with a port
of the pixelizer code; tests are added in current state of PR, too.
Still one more thing to do there, which is to get multiple fields in a
single pass.
On Fri, Sep 25, 2015 at 7:15 PM, Matthew Turk
Hi Cameron,
Yeah, a kwarg for the actual .arbitrary_grid would be great, but that can't be expressed in the slicing notation (or rather, it can, but it's unnatural). So getting the default is what I was hoping for; for particle quantities, we'll just have it do the standard "deposit" machinery which lets you do any type of interpolation you like, so it's less of a thing.
-Matt
On Fri, Sep 25, 2015 at 7:13 PM, Cameron Hummels
wrote: How about default to one of the options, but have a kwarg to decide which method to choose? I sort of like trilinear interp but I'm just thinking of grid-based data. Maybe default to trilinear interp for grid-based quantities and nearest neighbor for particle based quantities?
On Fri, Sep 25, 2015 at 4:46 PM, Nathan Goldbaum
wrote: I'd say nearest neighbor. Then it's also a generalization of what the FixedResolutionBuffer does.
On Friday, September 25, 2015, Matthew Turk
wrote: Hi everyone,
Thanks for the feedback -- I've made a bunch of changes and additions. One thing I wanted to ask was about 3D slicing that includes steps. For instance, in numpy style:
ds = yt.load(...) ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j, (-2.5, 'km') : (2.5, 'km'): 64j]
this should return a 128x256x64 3D array. But, how do we generate that?
The obvious thing would be to do either covering grid or arbitrary grids. The former requires alignment with cell boundaries, and the latter currently only supports particles. I think "arbitrary_grid" maps a lot more naturally to the situation, though. So it would require implementing mesh fields in the arbitrary_grid object, which is fine, but it's not clear to me the right *way* to do that. I think the choice might be between nearest neighbor and trilinear interpolation. So, for the *default* behavior, should we do:
* Trilinear interpolation (maybe nicer, but also subject to crazytimes with stuff that isn't a volume quantity, like mass) * Nearest neighbor (way, way faster, but also lower quality values in many cases)?
My inclination is #2, but I wanted a sanity check...
-Matt
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk
wrote: Hi all,
I'd very much appreciate feedback on this YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
The related PR that starts implementing them is here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-...
Two things that I think need some bikeshedding -- histogram and the step argument to slicing.
-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
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
Added the pixelizer, and updated the YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
Comments sought! If we can get the YTEP accepted, I will add
documentation and finish up the main PR.
-Matt
On Tue, Sep 29, 2015 at 1:37 PM, Matthew Turk
I've implemented arbitrary_grid pulling from fluid fields with a port of the pixelizer code; tests are added in current state of PR, too. Still one more thing to do there, which is to get multiple fields in a single pass.
On Fri, Sep 25, 2015 at 7:15 PM, Matthew Turk
wrote: Hi Cameron,
Yeah, a kwarg for the actual .arbitrary_grid would be great, but that can't be expressed in the slicing notation (or rather, it can, but it's unnatural). So getting the default is what I was hoping for; for particle quantities, we'll just have it do the standard "deposit" machinery which lets you do any type of interpolation you like, so it's less of a thing.
-Matt
On Fri, Sep 25, 2015 at 7:13 PM, Cameron Hummels
wrote: How about default to one of the options, but have a kwarg to decide which method to choose? I sort of like trilinear interp but I'm just thinking of grid-based data. Maybe default to trilinear interp for grid-based quantities and nearest neighbor for particle based quantities?
On Fri, Sep 25, 2015 at 4:46 PM, Nathan Goldbaum
wrote: I'd say nearest neighbor. Then it's also a generalization of what the FixedResolutionBuffer does.
On Friday, September 25, 2015, Matthew Turk
wrote: Hi everyone,
Thanks for the feedback -- I've made a bunch of changes and additions. One thing I wanted to ask was about 3D slicing that includes steps. For instance, in numpy style:
ds = yt.load(...) ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j, (-2.5, 'km') : (2.5, 'km'): 64j]
this should return a 128x256x64 3D array. But, how do we generate that?
The obvious thing would be to do either covering grid or arbitrary grids. The former requires alignment with cell boundaries, and the latter currently only supports particles. I think "arbitrary_grid" maps a lot more naturally to the situation, though. So it would require implementing mesh fields in the arbitrary_grid object, which is fine, but it's not clear to me the right *way* to do that. I think the choice might be between nearest neighbor and trilinear interpolation. So, for the *default* behavior, should we do:
* Trilinear interpolation (maybe nicer, but also subject to crazytimes with stuff that isn't a volume quantity, like mass) * Nearest neighbor (way, way faster, but also lower quality values in many cases)?
My inclination is #2, but I wanted a sanity check...
-Matt
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk
wrote: Hi all,
I'd very much appreciate feedback on this YTEP:
https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like...
The related PR that starts implementing them is here:
https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-...
Two things that I think need some bikeshedding -- histogram and the step argument to slicing.
-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
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
Cameron Hummels
-
Matthew Turk
-
Nathan Goldbaum