ProfileND: soliciting opinions
Hi all, So Matt and I are using the pressure of the yt / Athena workshop coming up in a few days to get some things ironed out with unitrefactor, and I've come up on an issue that I'd like to get feedback on with regard to the setup of ProfileND objects. Let's take Profile1D as an example: prof = Profile1D(sp, "density", 32, rho_min, rho_max, True, weight_field="density") prof.add_fields(["temperature","velocity_magnitude"]) You can access the dependent fields dict-like, as you should: prof["temperature"] which gives you the average value of that field in the bin. However, we have no "easy" way to get the values of the independent field (in this case, "density") at the bin centers. There are a couple of attributes for the values of this field, but oddly they give the same thing: prof.x_bins == values of the field at bin edges prof.x == values of the field at bin edges Is there a reason for this? My proposal is to make prof.x (and the corresponding prof.y and prof.z for Profile2D and Profile3D) the values at the bin centers. Best, John Z
+1 on this change. On Mon, Feb 3, 2014 at 4:42 PM, John ZuHone <jzuhone@gmail.com> wrote:
Hi all,
So Matt and I are using the pressure of the yt / Athena workshop coming up in a few days to get some things ironed out with unitrefactor, and I've come up on an issue that I'd like to get feedback on with regard to the setup of ProfileND objects.
Let's take Profile1D as an example:
prof = Profile1D(sp, "density", 32, rho_min, rho_max, True, weight_field="density") prof.add_fields(["temperature","velocity_magnitude"])
You can access the dependent fields dict-like, as you should:
prof["temperature"]
which gives you the average value of that field in the bin. However, we have no "easy" way to get the values of the independent field (in this case, "density") at the bin centers. There are a couple of attributes for the values of this field, but oddly they give the same thing:
prof.x_bins == values of the field at bin edges
prof.x == values of the field at bin edges
Is there a reason for this? My proposal is to make prof.x (and the corresponding prof.y and prof.z for Profile2D and Profile3D) the values at the bin centers.
Best,
John Z _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I am +1 on this provided that prof.x_bins, etc. remains with the values of the fields at bin edges. On Mon, Feb 3, 2014 at 4:43 PM, j s oishi <jsoishi@gmail.com> wrote:
+1 on this change.
On Mon, Feb 3, 2014 at 4:42 PM, John ZuHone <jzuhone@gmail.com> wrote:
Hi all,
So Matt and I are using the pressure of the yt / Athena workshop coming up in a few days to get some things ironed out with unitrefactor, and I've come up on an issue that I'd like to get feedback on with regard to the setup of ProfileND objects.
Let's take Profile1D as an example:
prof = Profile1D(sp, "density", 32, rho_min, rho_max, True, weight_field="density") prof.add_fields(["temperature","velocity_magnitude"])
You can access the dependent fields dict-like, as you should:
prof["temperature"]
which gives you the average value of that field in the bin. However, we have no "easy" way to get the values of the independent field (in this case, "density") at the bin centers. There are a couple of attributes for the values of this field, but oddly they give the same thing:
prof.x_bins == values of the field at bin edges
prof.x == values of the field at bin edges
Is there a reason for this? My proposal is to make prof.x (and the corresponding prof.y and prof.z for Profile2D and Profile3D) the values at the bin centers.
Best,
John Z _______________________________________________ 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
+1. While we're talking about profiles, it would be nice if I could specify the bin limits in the create_profile function - right now they are hard coded to come from the Extrema derived quantity. This would make it a bit more straightforward to make a ProfilePlot or PhasePlot with custom axes limits. It would also be nice if ProfileND returned YTArrays, that's something I was planning to add soonish, but if you guys handle it that would be great. -Nathan On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone@gmail.com> wrote:
I am +1 on this provided that prof.x_bins, etc. remains with the values of the fields at bin edges.
Yes, that would remain the same. _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
+1.
While we're talking about profiles, it would be nice if I could specify the bin limits in the create_profile function - right now they are hard coded to come from the Extrema derived quantity. This would make it a bit more straightforward to make a ProfilePlot or PhasePlot with custom axes limits.
I think the idea of create profiles was to stay super minimalist, and encourage using the actual objects for more complex operations. I'm not sure I want to bolt more arguments on rather than making ProfileND easier. Specifying bin edges manually could be neat, though, especially for non-uniform bins...
It would also be nice if ProfileND returned YTArrays, that's something I was planning to add soonish, but if you guys handle it that would be great.
Optimistically, no more than 36 hours for that. :) I also hope to have a wrapper for a array_like_field type thing too, to make it easier to copy and duplicate units. Thoughts on that? Matt
-Nathan
On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone@gmail.com> wrote:
I am +1 on this provided that prof.x_bins, etc. remains with the
values of the fields at bin edges.
Yes, that would remain the same. _______________________________________________ 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
Unless I'm mistaken I think all Nathan wanted was to be able to specify the min and max of the entire profile, not arbitrary bin edges. John ZuHone Laboratory for High-Energy Astrophysics NASA/Goddard Space Flight Center 8800 Greenbelt Rd., Mail Code 662 Greenbelt, MD 20771 (w) 301-286-2531 (m) 781-708-5004 john.zuhone@nasa.gov jzuhone@gmail.com
On Feb 3, 2014, at 5:57 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
+1.
While we're talking about profiles, it would be nice if I could specify the bin limits in the create_profile function - right now they are hard coded to come from the Extrema derived quantity. This would make it a bit more straightforward to make a ProfilePlot or PhasePlot with custom axes limits.
I think the idea of create profiles was to stay super minimalist, and encourage using the actual objects for more complex operations. I'm not sure I want to bolt more arguments on rather than making ProfileND easier.
Specifying bin edges manually could be neat, though, especially for non-uniform bins...
It would also be nice if ProfileND returned YTArrays, that's something I was planning to add soonish, but if you guys handle it that would be great.
Optimistically, no more than 36 hours for that. :) I also hope to have a wrapper for a array_like_field type thing too, to make it easier to copy and duplicate units. Thoughts on that?
Matt
-Nathan
On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone@gmail.com> wrote:
I am +1 on this provided that prof.x_bins, etc. remains with the values of the fields at bin edges.
Yes, that would remain the same. _______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Mon, Feb 3, 2014 at 2:57 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
+1.
While we're talking about profiles, it would be nice if I could specify the bin limits in the create_profile function - right now they are hard coded to come from the Extrema derived quantity. This would make it a bit more straightforward to make a ProfilePlot or PhasePlot with custom axes limits.
I think the idea of create profiles was to stay super minimalist, and encourage using the actual objects for more complex operations. I'm not sure I want to bolt more arguments on rather than making ProfileND easier.
Agreed, to a point. The issue is that it's not straightforward to create a custom PhasePlot or ProfilePlot. The docstrings mention being able to construct a custom profile with create_profile, but create_profile doesn't really offer much customization. ProfileND offers plenty of customization, but there are no docstrings in ProfileND or any subclasses so it's not exactly a user-friendly operation right now. ProfileND is also not in the yt.mods namespace. Adding docstrings to ProfileND and adding it to yt.mods would satisfy my concerns, I think.
Specifying bin edges manually could be neat, though, especially for non-uniform bins...
It would also be nice if ProfileND returned YTArrays, that's something I was planning to add soonish, but if you guys handle it that would be great.
Optimistically, no more than 36 hours for that. :) I also hope to have a wrapper for a array_like_field type thing too, to make it easier to copy and duplicate units. Thoughts on that?
Not totally sure what you mean, can you expand with a little bit more detail?
Matt
-Nathan
On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone@gmail.com> wrote:
I am +1 on this provided that prof.x_bins, etc. remains with the values of the fields at bin edges.
Yes, that would remain the same. _______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Mon, Feb 3, 2014 at 3:05 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Mon, Feb 3, 2014 at 2:57 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
+1.
While we're talking about profiles, it would be nice if I could specify the bin limits in the create_profile function - right now they are hard coded to come from the Extrema derived quantity. This would make it a bit more straightforward to make a ProfilePlot or PhasePlot with custom axes limits.
I think the idea of create profiles was to stay super minimalist, and encourage using the actual objects for more complex operations. I'm not sure I want to bolt more arguments on rather than making ProfileND easier.
Agreed, to a point. The issue is that it's not straightforward to create a custom PhasePlot or ProfilePlot. The docstrings mention being able to construct a custom profile with create_profile, but create_profile doesn't really offer much customization.
ProfileND offers plenty of customization, but there are no docstrings in ProfileND or any subclasses so it's not exactly a user-friendly operation right now. ProfileND is also not in the yt.mods namespace.
Looking again, it seems I was mistaken about Profile[1,2,3]D not being in the yt.mods namespace. That said, my concerns about docstrings still stand.
Adding docstrings to ProfileND and adding it to yt.mods would satisfy my concerns, I think.
Specifying bin edges manually could be neat, though, especially for non-uniform bins...
It would also be nice if ProfileND returned YTArrays, that's something I was planning to add soonish, but if you guys handle it that would be great.
Optimistically, no more than 36 hours for that. :) I also hope to have a wrapper for a array_like_field type thing too, to make it easier to copy and duplicate units. Thoughts on that?
Not totally sure what you mean, can you expand with a little bit more detail?
Matt
-Nathan
On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone@gmail.com> wrote:
I am +1 on this provided that prof.x_bins, etc. remains with the values of the fields at bin edges.
Yes, that would remain the same. _______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
+1 on having .x be the bin centers, and .x_bins being edges. That said, what is the protocol for calculating the center of logarithmically spaced bins? Is it .x = (.x_bins[:1] + .x_bins[1:])/2 or .x = 10**( (np.log10(.x_bins[:1]) + np.log10(.x_bins[1:]))/2 ) On Mon, Feb 3, 2014 at 3:05 PM, Nathan Goldbaum <nathan12343@gmail.com>wrote:
On Mon, Feb 3, 2014 at 2:57 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343@gmail.com> wrote:
+1.
While we're talking about profiles, it would be nice if I could specify the bin limits in the create_profile function - right now they are hard coded to come from the Extrema derived quantity. This would make it a bit more straightforward to make a ProfilePlot or PhasePlot with custom axes limits.
I think the idea of create profiles was to stay super minimalist, and encourage using the actual objects for more complex operations. I'm not
sure
I want to bolt more arguments on rather than making ProfileND easier.
Agreed, to a point. The issue is that it's not straightforward to create a custom PhasePlot or ProfilePlot. The docstrings mention being able to construct a custom profile with create_profile, but create_profile doesn't really offer much customization.
ProfileND offers plenty of customization, but there are no docstrings in ProfileND or any subclasses so it's not exactly a user-friendly operation right now. ProfileND is also not in the yt.mods namespace.
Adding docstrings to ProfileND and adding it to yt.mods would satisfy my concerns, I think.
Specifying bin edges manually could be neat, though, especially for non-uniform bins...
It would also be nice if ProfileND returned YTArrays, that's something I was planning to add soonish, but if you guys handle it that would be great.
Optimistically, no more than 36 hours for that. :) I also hope to have a wrapper for a array_like_field type thing too, to make it easier to copy and duplicate units. Thoughts on that?
Not totally sure what you mean, can you expand with a little bit more detail?
Matt
-Nathan
On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone@gmail.com> wrote:
I am +1 on this provided that prof.x_bins, etc. remains with the
values
of the fields at bin edges.
Yes, that would remain the same. _______________________________________________ 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
_______________________________________________ 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
On Feb 3, 2014, at 6:29 PM, Sam Skillman <samskillman@gmail.com> wrote:
+1 on having .x be the bin centers, and .x_bins being edges. That said, what is the protocol for calculating the center of logarithmically spaced bins? Is it .x = (.x_bins[:1] + .x_bins[1:])/2 or .x = 10**( (np.log10(.x_bins[:1]) + np.log10(.x_bins[1:]))/2 )
I'm not sure, but your second expression is reducible to: .x = np.sqrt(.x_bins[:-1]*.x_bins[1:]) And I think you meant that to be ":-1"
I'm all for minimalism, but being able to easily specify the limits on a profile/phaseplot is a bread and butter operation. I'm +1 for making this doable from the initial ProfilePlot/PhasePlot call. On Mon, Feb 3, 2014 at 6:40 PM, John ZuHone <jzuhone@gmail.com> wrote:
On Feb 3, 2014, at 6:29 PM, Sam Skillman <samskillman@gmail.com> wrote:
+1 on having .x be the bin centers, and .x_bins being edges. That said, what is the protocol for calculating the center of logarithmically spaced bins? Is it .x = (.x_bins[:1] + .x_bins[1:])/2 or .x = 10**( (np.log10(.x_bins[:1]) + np.log10(.x_bins[1:]))/2 )
I'm not sure, but your second expression is reducible to:
.x = np.sqrt(.x_bins[:-1]*.x_bins[1:])
And I think you meant that to be ":-1" _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (6)
-
Britton Smith -
j s oishi -
John ZuHone -
Matthew Turk -
Nathan Goldbaum -
Sam Skillman