Hi all,
I've just issued a pull request that bears some developer discussion.
Right now yt is a bit of a wild west in terms of the field naming
convention for fields that reference a coordinate system. See for example,
see issue 947:
https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-for-…
I'd like to propose a naming convention for fields that reference a
coordinate system. Gas and particle fields should be of the form:
(field_type, "<particle?>_<vector_field_name>_<coordinate>")
while index fields for coordinates should be of the form:
("index", "<coordinate>")
This fits within our existing field naming convention for cartesian
coordinates, e.g.:
("gas", "velocity_x")
(ptype, "particle_velocity_y")
as well as our convention for index coordinate fields, e.g.:
("index", "x")
("index", "spherical_theta")
This means that index fields do not need to explicitly reference themselves
as positions. So we *won't* have field names like:
("index", "position_x")
I don't like the above construction because it's a bit redundant ("index"
implies that we are talking about a position or something similar).
Some existing field names will need to be changed to fit this. In
particular, some of the index fields will need to be renamed to be more
verbose ("index", "spherical_r") becomes ("index", "spherical_radius") and
(ptype, "particle_spherical_position_radius") becomes (ptype,
"particle_position_spherical_radius").
Wherever an existing field name needs to change, I propose we mark the
existing field name for deprecation, stub it out, and make it an alias for
the field with the new field name. In a future release, we can then remove
the deprecated fields.
I've implemented this for the particle fields (for the most part) in PR
1378:
https://bitbucket.org/yt_analysis/yt/pull-request/1378
I'm happy to update the field naming YTEP if this proposed field naming
scheme gets approval in this thread.
What do you all think? Question, concerns?
-Nathan
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
Nathan and I are taking a whack at getting a paper outline together. I
transferred the repo I started in April of 2013 (!!) over the yt_analysis
and if anybody wants to start hacking away, feel free. Right now our short
term goals are outline, importing existing text, and then figuring out some
things to write. I'm going to try to shoulder a lot of the burden for
authoring text.
More info later, but feel free to either hack away, put stuff in the
outline, leave comments, or write back to this list with thoughts. Or,
ignore it for now! :) All are good options, just wanted to make sure that
folks were in the loop.
-Matt
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
New issue 967: HaloCatalog fails for a RockstarDataset with "format_revision" = 2
https://bitbucket.org/yt_analysis/yt/issue/967/halocatalog-fails-for-a-rock…
Devin Silvia:
HaloCatalog hits a Key Error for a rockstar halo dataset read from a rockstar halo binary filel. The value of halos_ds.parameters['format_revision'] is 2. If I change this to "0" before the halo catalog call, there doesn't seem to be a problem. This is an issue for a newly created rockstar halo list. A halo list created for the same dataset with an older version of rockstar seems to end up with "format_revision" value of 0.
The command that fails is:
hc = HaloCatalog(data_ds=data_ds, halos_ds=halos_ds, output_dir=os.path.join(tmpdir, 'halo_catalog'))
The traceback is here: http://paste.yt-project.org/show/5290/
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
New issue 966: Negative radius values in particle_spherical_position_radius fields (and some inconsistant values)
https://bitbucket.org/yt_analysis/yt/issue/966/negative-radius-values-in
Benjamin Thompson:
>From discussion within this PR
[https://bitbucket.org/yt_analysis/yt/pull-request/1308/wip-particle_cylindr…
I have found that particle_spherical_position_radius (as well as my newly proposed particle_cylindrical_position_radius) produces negative radius values.
```
#!python
sphere["particle_cylindrical_position_radius"].min()
```
-6.41156882532e+23 cm
```
#!python
sphere["particle_spherical_position_radius"].min()
```
-7.83826739716e+23 cm
wheras sphere["particle_spherical_radius"] does not
```
#!python
sphere["particle_spherical_radius"].min()
```
1.25498335796e+20 cm
FYI particle_spherical_radius is more of a direct copy from how the fluid fields compute the spherical radius.
Interestingly enough. Both these methods produce different results too.
E.g
```
#!python
sphere["particle_spherical_radius"][20]
```
returns 2.37463756333e+23 cm
and
```
#!python
sphere["particle_spherical_position_radius"][20]
```
returns
5.0064012169e+22 cm
FYI the two different methods for calculating these radii are. For "spherical_position_radius"
```
#!python
def _particle_spherical_position_radius(field, data):
"""
Radial component of the particles' position vectors in spherical coords
on the provided field parameters for 'normal', 'center',
'bulk_velocity',
"""
normal = data.get_field_parameter('normal')
center = data.get_field_parameter('center')
bv = data.get_field_parameter("bulk_velocity")
pos = spos
pos = YTArray([data[ptype, pos % ax] for ax in "xyz"])
theta = get_sph_theta(pos, center)
phi = get_sph_phi(pos, center)
pos = pos - np.reshape(center, (3, 1))
sphr = get_sph_r_component(pos, theta, phi, normal)
return sphr
registry.add_field((ptype, "particle_spherical_position_radius"),
function=_particle_spherical_position_radius,
particle_type=True, units="cm",
validators=[ValidateParameter("normal"),
ValidateParameter("center")])
```
and "spherical_radius"
```
#!python
def _particle_radius(field, data):
return get_radius(data, "particle_position_")
registry.add_field((ptype, "particle_radius"),
function=_particle_radius,
validators=[ValidateParameter("center")],
units="cm", particle_type = True,
display_name = "Particle Radius")
# this is just particle radius but add it for ease of use
registry.add_field((ptype, "particle_spherical_radius"),
function=_particle_radius,
particle_type=True, units="cm",
validators=[ValidateParameter("normal"),
ValidateParameter("center")])
```
I have noticed in the fluid gas fields, we are using instead.
```
#!python
def _spherical_r(field, data):
coords = get_periodic_rvec(data)
return data.ds.arr(get_sph_r(coords), "code_length").in_cgs()
```
which returns positive radii as expected.
So basically. Which "radius" calculation should be used for spherical radii? I am thinking a similar sort of manner as done in the fluid fields.
In summary
1) Why are we getting negative radius for particle_spherical_position_radius
2) Why
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
I've just pushed a change to the fork of Rockstar I have on bitbucket that
adds a default-off compile-time setting that governs whether or not the
random stream is reset following the call to "random_sleep" that governs
how the clients connect to the server.
https://bitbucket.org/MatthewTurk/rockstar/commits/cf88fc3f9c1c9f0768005be5…
This addresses something that's come up on this list before. I think it
should make runs completely deterministic (it does in my case) and will fix
the halo finding and halo analysis tests. They are now, in my tests,
bitwise identical between runs whereas before I was getting definitely
non-bitwise results. (This is noted in the paper.)
I wanted to make this a parameter, but I wasn't able to figure out how to
do it without breaking API compatibility. So eventually, this should make
its way upstream, but for now, it should (if compiled correctly!) fix the
tests.
If you're building rockstar at home:
RNG_FLAGS=-DRESET_RNG_STREAM make clean lib
should get it for you.
-Matt
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
For various reasons, we need to freeze any new datasets being added to
yt-project.org/data/ . I've also removed a bunch of redundant and
uncompressed files in that subdirectory.
We'll have a new solution sometime in the next 60 days, and at that time
we'll also have a way to upload new data much more easily.
-Matt
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all,
I've issued a pull request for an early pass at defining how to handle
unstructured mesh data.
https://bitbucket.org/yt_analysis/ytep/pull-request/47/adding-ytep-0021-for…
I would really, really appreciate any feedback. If the YTEP as written is
too opaque or poorly organized, feel free to leave suggestions. If there
are spots where I've completely missed something or sidestepped it without
digging int, that would be extremely useful, too. As I note in the
alternative implementation area, I'm not sure I got the namespacing right,
and I'm not sure that the way I've thought about the data and how
individuals would want to interact with it is right, either, but I did try
to think though how *I'd* want to interact with it.
Also, as I mentioned in the PR, I think this could be a gateway to
improving support for particle/discrete data too.
-Matt
_______________________________________________
yt-dev mailing list
yt-dev(a)lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
