updated examples for 3.0 volume rendering
Is there any updated examples for using the yt 3.0 volume rendering? For instance, looking at this: http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend... The field name is no longer simply "Density", but now, for my data, I need to use a tuple like: field = ('boxlib', 'magvel') And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at: dd.quantities["Extrema"](field) I get: (124.858613718 dimensionless, 18061918.0546 dimensionless) (not sure why they are dimensionless, but that's a different problem). Finally, if I try to make a transfer function, like: tf = ColorTransferFunction((mi, ma)) I get: NameError: name 'ColorTransferFunction' is not defined I just synced up with the development version today. Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
Hi Mike, You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark. On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
(not sure why they are dimensionless, but that's a different problem).
If you do type(dd.quantities["Extrema"](field)[0]) you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
Finally, if I try to make a transfer function, like:
tf = ColorTransferFunction((mi, ma))
I get:
NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon. The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html as well as in the following pull request: https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
I just synced up with the development version today.
Mike
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find. That said, if you want a lower-friction option, 'downgrading' to the development bookmark should go a long way. To do that, navigate to your checking of the yt mercurial repository and issue the following sequence of commands: hg up development python setup.py develop Hope that's helpful. Please let us know if you have any further questions or concerns. -Nathan
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
(not sure why they are dimensionless, but that's a different problem).
If you do
type(dd.quantities["Extrema"](field)[0])
you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
Finally, if I try to make a transfer function, like:
tf = ColorTransferFunction((mi, ma))
I get:
NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon.
The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here:
http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
as well as in the following pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
I just synced up with the development version today.
Mike
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find.
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
I made a bit more progress here, but I get an error in amr_kdtree/amr_kdtree.py in line 257, it does dds = grid.dds.ndarray_view() but grid.dds is already an ndarray, so this should be dds = grid.dds still not through the cam.snapshot() part of my script, but I got everything up to there working. On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote: Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
(not sure why they are dimensionless, but that's a different problem).
If you do
type(dd.quantities["Extrema"](field)[0])
you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
Finally, if I try to make a transfer function, like:
tf = ColorTransferFunction((mi, ma))
I get:
NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon.
The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here:
http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
as well as in the following pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
I just synced up with the development version today.
Mike
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find.
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
ok, final update -- I am able to do a basic volume rendering, but I need to set no_ghost=True if this is False, then there is a units error in sanitize_units_add. Perhaps when the ghost-cells are added, that is done as a normal ndarray and not a YTarray? Similar issues arise if I try to draw_coordinate_vectors() On Fri, Mar 28, 2014 at 7:26 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I made a bit more progress here, but I get an error in
amr_kdtree/amr_kdtree.py
in line 257, it does
dds = grid.dds.ndarray_view()
but grid.dds is already an ndarray, so this should be
dds = grid.dds
still not through the cam.snapshot() part of my script, but I got everything up to there working.
On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote: Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
(not sure why they are dimensionless, but that's a different problem).
If you do
type(dd.quantities["Extrema"](field)[0])
you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
Finally, if I try to make a transfer function, like:
tf = ColorTransferFunction((mi, ma))
I get:
NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon.
The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here:
http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
as well as in the following pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
I just synced up with the development version today.
Mike
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find.
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
Hi Mike,
On Friday, March 28, 2014, Michael Zingale
I made a bit more progress here, but I get an error in
amr_kdtree/amr_kdtree.py
in line 257, it does
dds = grid.dds.ndarray_view()
That line indicates that it should be a YTArray, or at least it is for the other frontends. I've issued a PR for an alternate fix here: https://bitbucket.org/yt_analysis/yt/pull-request/779/ensure-griddds-is-a-yt... Thanks for the testing, I don't think the boxlib frontend has seen much use since we ported it to use the new field and unit system. You might also be interested in fields.py in the boxlib frontend. You should be able to edit the tuples that define "known" on-disk fields to include the ones in your dataset. The tuples look like this: ("eden", (eden_units, ["energy_density"], None)) The format is the boxlib field name in the first entry, and then a three-element tuple in the second entry, containing the units of the field, a list of aliases to 'universal' yt fields defined in the yt.fields namespace (you can take a look at the field definitions in the yt/fields/ folder), and a display name. If the display name is None, plot labels will be automatically generated based on the field name.
but grid.dds is already an ndarray, so this should be
dds = grid.dds
still not through the cam.snapshot() part of my script, but I got everything up to there working.
On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote: Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
On Fri, Mar 28, 2014 at 4:52 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
ok, final update -- I am able to do a basic volume rendering, but I need to set
no_ghost=True
if this is False, then there is a units error in sanitize_units_add. Perhaps when the ghost-cells are added, that is done as a normal ndarray and not a YTarray?
Similar issues arise if I try to draw_coordinate_vectors()
Can you report these issues on our bug tracker? A test script that fails for you would be especially helpful.
On Fri, Mar 28, 2014 at 7:26 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I made a bit more progress here, but I get an error in
amr_kdtree/amr_kdtree.py
in line 257, it does
dds = grid.dds.ndarray_view()
but grid.dds is already an ndarray, so this should be
dds = grid.dds
still not through the cam.snapshot() part of my script, but I got everything up to there working.
On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote: Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
(not sure why they are dimensionless, but that's a different problem).
If you do
type(dd.quantities["Extrema"](field)[0])
you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
Finally, if I try to make a transfer function, like:
tf = ColorTransferFunction((mi, ma))
I get:
NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon.
The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here:
http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
as well as in the following pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
I just synced up with the development version today.
Mike
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find.
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Thanks. I see in there
def _temperature(field,data):
mu = data.get_field_parameter("mu")
return ( (data.pf.gamma-1.0) * mu * mh *
data["thermal_energy"] / (kboltz * data["density"]) )
is it the case that yt will assume a gamma-law gas?
On Fri, Mar 28, 2014 at 7:53 PM, Nathan Goldbaum
On Fri, Mar 28, 2014 at 4:52 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
ok, final update -- I am able to do a basic volume rendering, but I need to set
no_ghost=True
if this is False, then there is a units error in sanitize_units_add. Perhaps when the ghost-cells are added, that is done as a normal ndarray and not a YTarray?
Similar issues arise if I try to draw_coordinate_vectors()
Can you report these issues on our bug tracker? A test script that fails for you would be especially helpful.
On Fri, Mar 28, 2014 at 7:26 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I made a bit more progress here, but I get an error in
amr_kdtree/amr_kdtree.py
in line 257, it does
dds = grid.dds.ndarray_view()
but grid.dds is already an ndarray, so this should be
dds = grid.dds
still not through the cam.snapshot() part of my script, but I got everything up to there working.
On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote:
Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?
For instance, looking at this:
http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend...
We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
The field name is no longer simply "Density", but now, for my data, I need to use a tuple like:
field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
And then when I look at the extrema, I no longer take the [0] index, as that just gives the min, but instead if I look at:
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
dd.quantities["Extrema"](field)
I get:
(124.858613718 dimensionless, 18061918.0546 dimensionless)
(not sure why they are dimensionless, but that's a different problem).
If you do
type(dd.quantities["Extrema"](field)[0])
you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
Finally, if I try to make a transfer function, like:
tf = ColorTransferFunction((mi, ma))
I get:
NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon.
The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here:
http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
as well as in the following pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
I just synced up with the development version today.
Mike
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find.
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
On Fri, Mar 28, 2014 at 7:59 PM, Michael Zingale
Thanks. I see in there
def _temperature(field,data): mu = data.get_field_parameter("mu") return ( (data.pf.gamma-1.0) * mu * mh * data["thermal_energy"] / (kboltz * data["density"]) )
is it the case that yt will assume a gamma-law gas?
Only if temperature isn't defined -- the field system is set up now to be able to dynamically swap these in and out, so we definitely should. -Matt
On Fri, Mar 28, 2014 at 7:53 PM, Nathan Goldbaum
wrote: On Fri, Mar 28, 2014 at 4:52 PM, Michael Zingale
wrote: ok, final update -- I am able to do a basic volume rendering, but I need to set
no_ghost=True
if this is False, then there is a units error in sanitize_units_add. Perhaps when the ghost-cells are added, that is done as a normal ndarray and not a YTarray?
Similar issues arise if I try to draw_coordinate_vectors()
Can you report these issues on our bug tracker? A test script that fails for you would be especially helpful.
On Fri, Mar 28, 2014 at 7:26 PM, Michael Zingale
wrote: I made a bit more progress here, but I get an error in
amr_kdtree/amr_kdtree.py
in line 257, it does
dds = grid.dds.ndarray_view()
but grid.dds is already an ndarray, so this should be
dds = grid.dds
still not through the cam.snapshot() part of my script, but I got everything up to there working.
On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale
wrote: On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote: Hi Mike,
You've hit a bunch of big changes we've been making recently. If you want to get back to the version of yt before we merged these big changes in, you'll need to update to the 'development' bookmark. Right now you're on the 'experimental' bookmark.
Oh... lucky me.
On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale
wrote: > > Is there any updated examples for using the yt 3.0 volume rendering? > > For instance, looking at this: > > > http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend... We haven't finished updating the docs yet. In-development docs (including some out-of-date information that we need to update) are available here: http://yt-project.org/docs/dev-3.0/
> > > The field name is no longer simply "Density", but now, for my data, I > need to use a tuple like: > > field = ('boxlib', 'magvel')
We no longer have a 'Density' field, since this introduces ambiguities for Enzo data and to create a consistent naming scheme for fields. The new name is 'density'. See: http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
> > > And then when I look at the extrema, I no longer take the [0] index, > as that just gives the min, but instead if I look at: >
That true, we've simplified the derived quantity API somewhat. This fixes a long-standing issue at the cost of breaking some old user scripts. As you can see we are planning to break backward compatibility somewhat for the final yt 3.0 release.
> > dd.quantities["Extrema"](field) > > I get: > > (124.858613718 dimensionless, 18061918.0546 dimensionless)
> > (not sure why they are dimensionless, but that's a different > problem). >
If you do
type(dd.quantities["Extrema"](field)[0])
you will see that it is a new type, YTQuantity, which is a new class we've defined to handle units for scalar data. YTArray does the same thing for array data. More detail here: http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
These are 'dimensionless' because the boxlib frontend does not know what the appropriate units are for the 'magvel' field. It may be the case that we could modify the frontend to detect the units
> > Finally, if I try to make a transfer function, like: > > tf = ColorTransferFunction((mi, ma)) > > I get: > > NameError: name 'ColorTransferFunction' is not defined
I think this was an oversight on Matt's part. Thanks for the report! For now you should be able to import ColorTransferFunction from yt.visualization.volume_rendering.api, but this should be fixed soon.
The reason this happened is that we've changed the way imports work in the top-level yt namespace in the interest of yt behaving more like a 'normal' scientific python package. More detail is available here:
http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
as well as in the following pull request:
https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
> > > I just synced up with the development version today. > > Mike > >
We're working hard to update the docs and get the code into shape to release. If you're ok with dealing with not having fully up-to-date docs, we'd really appreciate you trying out the changes to the code, letting us know what you think, and reporting any bugs you find.
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
> > > > -- > Michael Zingale > Associate Professor > > Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, > NY 11794-3800 > phone: 631-632-8225 > e-mail: Michael.Zingale@stonybrook.edu > web: http://www.astro.sunysb.edu/mzingale > > _______________________________________________ > yt-users mailing list > yt-users@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
ok, one issue for Maestro is that there are 2 temperatures. For low Mach
flows, you don't need an energy equation formally, but we carry one in
Maestro anyway. So you can get the temperature with or without the energy
(enthalpy actually). So it would be nice if we could specify which of the
temperature fields we want to use with yt (they are named "tfromp" and
"tfromh").
On Fri, Mar 28, 2014 at 8:00 PM, Matthew Turk
On Fri, Mar 28, 2014 at 7:59 PM, Michael Zingale
wrote: Thanks. I see in there
def _temperature(field,data): mu = data.get_field_parameter("mu") return ( (data.pf.gamma-1.0) * mu * mh * data["thermal_energy"] / (kboltz * data["density"]) )
is it the case that yt will assume a gamma-law gas?
Only if temperature isn't defined -- the field system is set up now to be able to dynamically swap these in and out, so we definitely should.
-Matt
On Fri, Mar 28, 2014 at 7:53 PM, Nathan Goldbaum
wrote: On Fri, Mar 28, 2014 at 4:52 PM, Michael Zingale
wrote: ok, final update -- I am able to do a basic volume rendering, but I
to set
no_ghost=True
if this is False, then there is a units error in sanitize_units_add. Perhaps when the ghost-cells are added, that is done as a normal ndarray and not a YTarray?
Similar issues arise if I try to draw_coordinate_vectors()
Can you report these issues on our bug tracker? A test script that fails for you would be especially helpful.
On Fri, Mar 28, 2014 at 7:26 PM, Michael Zingale
wrote: I made a bit more progress here, but I get an error in
amr_kdtree/amr_kdtree.py
in line 257, it does
dds = grid.dds.ndarray_view()
but grid.dds is already an ndarray, so this should be
dds = grid.dds
still not through the cam.snapshot() part of my script, but I got everything up to there working.
On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale
wrote: On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum
wrote: > > Hi Mike, > > You've hit a bunch of big changes we've been making recently. If you
> want to get back to the version of yt before we merged these big changes in, > you'll need to update to the 'development' bookmark. Right now you're on > the 'experimental' bookmark. >
Oh... lucky me.
> > > On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale >
wrote: >> >> Is there any updated examples for using the yt 3.0 volume rendering? >> >> For instance, looking at this: >> >> >> http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rend... > > > We haven't finished updating the docs yet. In-development docs > (including some out-of-date information that we need to update) are > available here: http://yt-project.org/docs/dev-3.0/ > >> >> >> The field name is no longer simply "Density", but now, for my data, I >> need to use a tuple like: >> >> field = ('boxlib', 'magvel') > > > We no longer have a 'Density' field, since this introduces ambiguities > for Enzo data and to create a consistent naming scheme for fields. The new > name is 'density'. See: > http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html thanks for the list. Maestro has it's own fun with variables (two definitions for temperature, several pressures, etc., magvel above is not simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay attention to these definitions.
>> >> >> And then when I look at the extrema, I no longer take the [0] index, >> as that just gives the min, but instead if I look at: >> > > That true, we've simplified the derived quantity API somewhat. This > fixes a long-standing issue at the cost of breaking some old user
> As you can see we are planning to break backward compatibility somewhat for > the final yt 3.0 release. > >> >> dd.quantities["Extrema"](field) >> >> I get: >> >> (124.858613718 dimensionless, 18061918.0546 dimensionless) > > >> >> (not sure why they are dimensionless, but that's a different >> problem). >> > > If you do > > type(dd.quantities["Extrema"](field)[0]) > > you will see that it is a new type, YTQuantity, which is a new class > we've defined to handle units for scalar data. YTArray does the same thing > for array data. More detail here: > http://yt-project.org/docs/dev-3.0/analyzing/units/index.html > > These are 'dimensionless' because the boxlib frontend does not know > what the appropriate units are for the 'magvel' field. It may be
need scripts. the case
> that we could modify the frontend to detect the units > >> >> Finally, if I try to make a transfer function, like: >> >> tf = ColorTransferFunction((mi, ma)) >> >> I get: >> >> NameError: name 'ColorTransferFunction' is not defined > > > I think this was an oversight on Matt's part. Thanks for the report! > For now you should be able to import ColorTransferFunction from > yt.visualization.volume_rendering.api, but this should be fixed soon. > > The reason this happened is that we've changed the way imports work in > the top-level yt namespace in the interest of yt behaving more like a > 'normal' scientific python package. More detail is available here: > > http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html > > as well as in the following pull request: > > https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff > >> >> >> I just synced up with the development version today. >> >> Mike >> >> > > We're working hard to update the docs and get the code into shape to > release. If you're ok with dealing with not having fully up-to-date docs, > we'd really appreciate you trying out the changes to the code, letting us > know what you think, and reporting any bugs you find. >
yeah, I'm happy to keep playing with this version if it helps. The reason I updated today is because Matt told me that he had incorporated the Maestro field info that I sent him.
>> >> >> >> -- >> Michael Zingale >> Associate Professor >> >> Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, >> NY 11794-3800 >> phone: 631-632-8225 >> e-mail: Michael.Zingale@stonybrook.edu >> web: http://www.astro.sunysb.edu/mzingale >> >> _______________________________________________ >> yt-users mailing list >> yt-users@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >> > > > _______________________________________________ > yt-users mailing list > yt-users@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org >
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
participants (3)
-
Matthew Turk
-
Michael Zingale
-
Nathan Goldbaum