Hello,
I'm trying to define a new metal field and compare to the old, but the new
field doesn't have any numbers on the colorbar! Changing units and setting
minorticks "on" didn't help with this.
[image: Inline image 1][image: Inline image 2]
import yt
filename = "/Users/file_name_vela_sim.d"
ds = yt.load(filename)
def _SN_metal_dens(field, data):
return data[('gas','metal_ia_density')]+
data[('gas','metal_ii_density')]
yt.add_field(("gas", "sn_metal_density"), function=_SN_metal_dens,
units="g/cm**3")
p1 = yt.ProjectionPlot(ds,0,("gas", "sn_metal_density"), width = (1, "Mpc"))
p2 = yt.ProjectionPlot(ds,0,("gas", "metal_density"), width = (1, "Mpc"))
p1.set_cbar_minorticks(("gas", "sn_metal_density"),"on")
p2.set_cbar_minorticks(("gas", "metal_density"),"on")
p1.set_unit(("gas", "sn_metal_density"), 'g/cm**2')
p1.save()
p2.save()
How do I get a normal colorbar plot with numbers with a user-defined field?
--
Physics Department UC Santa Cruz
1156 HIGH STREET, SANTA CRUZ, CA 95064
916-749-2940
Hi yt-users!
I have a simulation run on Enzo that has a best resolution cell size of ~40
pc. I would like to be able to compare my run to observations that are at
a resolution of ~200 pc. I want to save a bunch of data in a fits file
with that resolution. It looks like the way to do this is to create an
arbitrary_grid object. If someone has a better method, please tell me!
So I have my artbitrary_grid object, and I am making arrays of fields:
xp = arbgridobj['x']
...etc....
xp = np.array(xp)
...etc...
my code keeps crashing when I try to get a user-defined field for my
arbitrary_grid object. If I try to get the field for a cut_region my code
runs just fine. Is user-defined fields + arbitrary_grid objects just
something that yt can't do or is there some different way to make this
happen than in a cut_region?
Thanks!!
Best,
Stephanie
--
Dr. Stephanie Tonnesen
Alvin E. Nashman Postdoctoral Fellow
Carnegie Observatories, Pasadena, CA
stonnes(a)gmail.com
Hi Nathan, hi Prateek,
before I look into the frontend and try to modify it, I wonder:
1. Is possible to define units for a new field in the Enzo output (there
are units conversion factors for certain quantities in Enzo, but I don't
now if this somehow enters the data dumps)?
2. Could I "teach" yt to assume certain units for a field which it
interprets as dimensionless on the fly, i.e. in a python session? If so,
how?
Cheers,
wolfram
On 05.08.2017 20:14, yt-users-request(a)lists.spacepope.org wrote:
> Send yt-users mailing list submissions to
> yt-users(a)lists.spacepope.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> or, via email, send a message with subject or body 'help' to
> yt-users-request(a)lists.spacepope.org
>
> You can reach the person managing the list at
> yt-users-owner(a)lists.spacepope.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yt-users digest..."
>
>
> Today's Topics:
>
> 1. Re: problem with units when defining difference of
> velocity-like fields (Prateek Gupta)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 5 Aug 2017 04:48:11 +0530
> From: Prateek Gupta <prateekgidolia(a)gmail.com>
> To: Discussion of the yt analysis package
> <yt-users(a)lists.spacepope.org>
> Subject: Re: [yt-users] problem with units when defining difference of
> velocity-like fields
> Message-ID:
> <CAJcogBoDbsRseqcbuEVdKP0Z9p9LvhO_TkjHYeOgykTbQt0Phg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I think just applying units to AveMomtX field while defining will work if
> you derived it in yt. May be while defining a new field (AveMomtX), it
> doesn't get units of momentum, it seems as "dimensionless" quantity.
> But if you are taking AveMomtX as a new field from Enzo itself, after
> modification of Enzo code, then yt required to know about this that
> this(AveMomtX) is also the field in Enzo.
>
>
> Best Regards
> -Prateek Gupta
>
> On Thu, Aug 3, 2017 at 6:07 PM, Nathan Goldbaum <nathan12343(a)gmail.com>
> wrote:
>
>> What are the units of AveMomtX right now? It seems it's getting read in as
>> dimensionless, probably because it's not a field yt knows about. To fix
>> this error you will need to apply units to the AveMomtX field in your field
>> definition. If you've modified the Enzo code to add this new field to your
>> Enzo outputs, you could also modify yt's Enzo frontend to "teach" yt about
>> the new field you've added. See yt/frontends/enzo/fields.py, specifically
>> the known_other_fields tuple.
>>
>> On Thu, Aug 3, 2017 at 3:28 AM Wolfram Schmidt <
>> wolfram.schmidt(a)uni-hamburg.de> wrote:
>>
>>> Dear all,
>>>
>>> I encountered a problem when defining a the fluctuation of the velocity
>>> with respect to a smoothed velocity as derived field in yt:
>>>
>>> def _fluc_velocity_x(field, data):
>>> return data["x-velocity"] - data["AveMomtX"]/data["density"]
>>>
>>> ds.add_field("fluc_velocity_x", function=_fluc_velocity_x,
>>> force_override=True)
>>>
>>> Here x-velocity and density are standard baryon fields defined in Enzo
>>> and AveMomtX is an additional baryon field for smoothed momentum.
>>>
>>> When I load a data dump and execute the above definition, I get the
>>> following error:
>>>
>>> /lrz/sys/tools/python/2.7_anaconda_nompi/lib/python2.7/
>>> site-packages/yt/units/yt_array.py
>>> in sanitize_units_add(this_object, other_object, op_string)
>>> 126 if isinstance(ret, YTArray):
>>> 127 if not inp.units.same_dimensions_as(ret.units):
>>> --> 128 raise YTUnitOperationError(op_string, inp.units,
>>> ret.units)
>>> 129 ret = ret.in_units(inp.units)
>>> 130 # If the other object is not a YTArray, the only valid case
>>> is adding
>>>
>>> YTUnitOperationError: The subtraction operator for YTArrays with units
>>> (code_velocity) and (code_length**3/code_mass) is not well defined.
>>>
>>> After looking into
>>> http://yt-project.org/doc/analyzing/units/fields_and_unit_conversion.html
>>> ,
>>> I tried
>>>
>>> ds.add_field("fluc_velocity_x", units="cm/s", function=_fluc_velocity_x,
>>> force_override=True)
>>>
>>> but this results in the same error as before. Apparently, the problem is
>>> that yt does not recognize that momentum divided by density is a
>>> velocity and therefore cannot match the units to the first term
>>> (x-velocity).
>>>
>>> There are unit conversion functions such as .in_cgs(), but they are not
>>> applicable to the data objects in the above definition.
>>>
>>> So can anyone tell me how to fix this?
>>>
>>> Cheers,
>>>
>>> Wolfram
>>>
>>>
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users(a)lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users(a)lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>>
>
Greetings,
I am very proud to announce the release of version 2.0 of ytree!
ytree <https://github.com/brittonsmith/ytree> is tool for working with
merger-tree data from multiple
sources and for generating merger-trees from Gadget FoF/SUBFIND
catalogs. For a brief example of using ytree on merger-tree data,
have a look at this notebook
<https://github.com/brittonsmith/ytree/blob/master/doc/source/notebooks/In...>
.
This is significant update to ytree in terms of both usability and
speed. Updates include:
- tree building and field i/o now occur on-demand resulting in a huge
speedup.
- support for yt-like derived fields that can be defined with simple
functions.
- support for yt-like alias fields allowing for universal field naming
conventions to simplify writing scripts for multiple data formats.
- support for analysis fields which allow users to save the results of
expensive halo analysis to fields associated with each halo.
- significantly improved documentation
<http://ytree.readthedocs.io/en/latest/> including a guide to adding
support for new file formats.
- all fields in consistent-trees and Rockstar now fully supported with
units.
- an optimized format for saving and reloading trees for fast field
access.
ytree can be installed with pip:
pip install ytree
or from source, by going to https://github.com/brittonsmith/ytree
git clone https://github.com/brittonsmith/ytree
cd ytree
pip install -e .
Full documentation can be found at
http://ytree.readthedocs.io/.
ytree is an open-source community project. Please help make it better
with your contribution!
Thanks!
Britton
Dear all,
I encountered a problem when defining a the fluctuation of the velocity
with respect to a smoothed velocity as derived field in yt:
def _fluc_velocity_x(field, data):
return data["x-velocity"] - data["AveMomtX"]/data["density"]
ds.add_field("fluc_velocity_x", function=_fluc_velocity_x,
force_override=True)
Here x-velocity and density are standard baryon fields defined in Enzo
and AveMomtX is an additional baryon field for smoothed momentum.
When I load a data dump and execute the above definition, I get the
following error:
/lrz/sys/tools/python/2.7_anaconda_nompi/lib/python2.7/site-packages/yt/units/yt_array.py
in sanitize_units_add(this_object, other_object, op_string)
126 if isinstance(ret, YTArray):
127 if not inp.units.same_dimensions_as(ret.units):
--> 128 raise YTUnitOperationError(op_string, inp.units,
ret.units)
129 ret = ret.in_units(inp.units)
130 # If the other object is not a YTArray, the only valid case
is adding
YTUnitOperationError: The subtraction operator for YTArrays with units
(code_velocity) and (code_length**3/code_mass) is not well defined.
After looking into
http://yt-project.org/doc/analyzing/units/fields_and_unit_conversion.html,
I tried
ds.add_field("fluc_velocity_x", units="cm/s", function=_fluc_velocity_x,
force_override=True)
but this results in the same error as before. Apparently, the problem is
that yt does not recognize that momentum divided by density is a
velocity and therefore cannot match the units to the first term
(x-velocity).
There are unit conversion functions such as .in_cgs(), but they are not
applicable to the data objects in the above definition.
So can anyone tell me how to fix this?
Cheers,
Wolfram
