Mailman 3 December 2014 - yt-dev

Field naming proposal
by Nathan Goldbaum 05 Jan '15

05 Jan '15

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

9 20

Anyone have a copy of the m33 FITS file?
by Nathan Goldbaum 30 Dec '14

30 Dec '14

It looks like it was recently mistakenly deleted from yt-project.org/data. _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

4 5

paper
by Matthew Turk 29 Dec '14

29 Dec '14

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

2 1

Issue #967: HaloCatalog fails for a RockstarDataset with "format_revision" = 2 (yt_analysis/yt)
by Devin Silvia 23 Dec '14

23 Dec '14

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

1 0

Issue #966: Negative radius values in particle_spherical_position_radius fields (and some inconsistant values) (yt_analysis/yt)
by Benjamin Thompson 22 Dec '14

22 Dec '14

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

1 0

Issue #965: Create tests for eps_writer (yt_analysis/yt)
by John Wise 22 Dec '14

22 Dec '14

New issue 965: Create tests for eps_writer https://bitbucket.org/yt_analysis/yt/issue/965/create-tests-for-eps_writer John Wise: The eps_writer module needs some minimal tests in order to avoid breakage with any further updates. Responsible: jwise77 _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

Optionally resetting the random number generator stream in Rockstar
by Matthew Turk 19 Dec '14

19 Dec '14

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

2 2

Issue #964: Build documentation for PRs touching doc/ (yt_analysis/yt)
by Kacper Kowalik 19 Dec '14

19 Dec '14

New issue 964: Build documentation for PRs touching doc/ https://bitbucket.org/yt_analysis/yt/issue/964/build-documentation-for-prs-… Kacper Kowalik: Allow yt-fido to do full documentation build for PRs changing docs. Host it @ tests.yt-p.org Responsible: xarthisius _______________________________________________ yt-dev mailing list yt-dev(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

1 0

Freeze on new datasets
by Matthew Turk 19 Dec '14

19 Dec '14

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

1 0

RFC: YTEP-0021 for unstructured mesh
by Matthew Turk 18 Dec '14

18 Dec '14

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

1 0

yt-dev December 2014