Mailman 3 May 2014 - yt-dev - {{ block.super }

Leave of presence
by Matthew Turk 16 Jun '14

16 Jun '14

Hey all, Just wanted to drop a line to let you know that the next couple weeks, particularly the next 10 days or so, are going to be pretty busy for me, so I might have much higher latency replying to emails and pull requests. Additionally, I think we should aim for a 3.0 final by the end of June at the *latest* so we can have something of a shakeout period before SciPy. If you're working on 3.0, please try to keep the trello boards updated: https://trello.com/yt_analysis The specific ones that we've been recording blockers and whatnot on are: https://trello.com/b/HCLLFxEE/documentation https://trello.com/b/Y5XV4Hod/yt-3-0 I won't be doing any documentation writing for at least a week and a half, but hopefully I'll be able to starting again in the beginning of June. I don't believe we have any major technical issues to work out before then, and I know Hilary, Cameron, Nathan, Stuart and John have all done a good job of pushing on docs. Thanks everybody, Matt

2 2

Issue #847: Total mass fails with zero particles (yt_analysis/yt)
by Aaron Smith 29 May '14

29 May '14

New issue 847: Total mass fails with zero particles https://bitbucket.org/yt_analysis/yt/issue/847/total-mass-fails-with-zero-p… Aaron Smith: After loading a Flash dataset (cosmological simulation) with gas and DM particles I tried to take the total mass within a subvolume but because there were no DM particles within the region it failed. The call should return zero mass, or at least some error handling should stop it from breaking. Note: reg.quantities.total_mass() works if reg = ds.h.all_data() but does not if reg = ds.sphere("max", (.2, "kpc")) for example. Traceback can be found at http://paste.yt-project.org/show/4699/ Responsible: jzuhone

1 0

Issue #846: Enzo inline frontend cannot access particle information (yt_analysis/yt)
by Brian Crosby 29 May '14

29 May '14

New issue 846: Enzo inline frontend cannot access particle information https://bitbucket.org/yt_analysis/yt/issue/846/enzo-inline-frontend-cannot-… Brian Crosby: Accessing particle fields with the Enzo inline frontend fails. For example, ('gas', 'matter_density') is fine, as is ('enzo', 'z-velocity'), but ('enzo', 'particle_velocity_z') and ('enzo', 'particle_mass') both fail. Traceback with the fields and derived fields printed out: http://paste.yt-project.org/show/4697/ And the script: http://paste.yt-project.org/show/4698/ I'm testing this with a 128^3 unigrid Enzo cosmology simulation and yt-3.0, changeset 3cfb38afe34d .

1 0

Hop in yt-3
by Brian O'Shea 27 May '14

27 May '14

Hi folks, I just tried to do some halo-finding with yt-3 using Hop (the current tip; rev 3cfb38afe34d), and it died somewhere after calling 'regroup' with this error: Traceback (most recent call last): File "hop.py", line 11, in <module> halo_list = HaloFinder(pf, subvolume=my_subregion) File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/analysis_modules/halo_finding/halo_objects.py", line 2440, in __init__ self._join_halolists() File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/analysis_modules/halo_finding/halo_objects.py", line 1889, in _join_halolists self._groups.sort(haloCmp) File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/analysis_modules/halo_finding/halo_objects.py", line 1888, in haloCmp return cmp(h1.center_of_mass()[0], h2.center_of_mass()[0]) File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/utilities/parallel_tools/parallel_analysis_interface.py", line 191, in single_proc_results retval = func(self, *args, **kwargs) File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/analysis_modules/halo_finding/halo_objects.py", line 158, in center_of_mass c = (com * pm).sum(axis=1) / pm.sum() File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/units/yt_array.py", line 648, in __rmul__ return YTArray(super(YTArray, self).__rmul__(lo)) File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/units/yt_array.py", line 910, in __array_wrap__ ret_class = get_binary_op_return_class(cls1, cls2) File "/mnt/a/u/sciteam/bwoshea/yt-3.0/src/yt-hg/yt/units/yt_array.py", line 1045, in get_binary_op_return_class raise RuntimeError("Operations are only defined on pairs of objects" RuntimeError: Operations are only defined on pairs of objectsin which one is a subclass of the other It was functional roughly two weeks ago (on May 10), when I successfully did halo-finding on the same machine with yt-3. Looking at the errors, it seems to be something more general than Hop functionality, but I'm not entirely sure. Does anybody have any thoughts on this? Also, for the sake of completeness, you can see my batch and python scripts: http://paste.yt-project.org/show/4681/ http://paste.yt-project.org/show/4682/ And the full output log from the run: http://paste.yt-project.org/show/4683/ And, again, this is using the current tip of yt-3. Thanks! --Brian

2 3

SciPy sprints
by John Zuhone 25 May '14

25 May '14

Hi all, Do we have any plans for sprints at SciPy? We might have discussed this before but I've forgotten. Unless we're all booked up I want to put up a vote for the GDF library. If we did that I would be happy to sprint on a possible FLASH implementation as a test. Best, John Z -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone(a)gmail.com john.zuhone(a)nasa.gov

2 1

Issue #845: Subclass of YTArray throwing errors (yt_analysis/yt)
by Matthew Turk 22 May '14

22 May '14

New issue 845: Subclass of YTArray throwing errors https://bitbucket.org/yt_analysis/yt/issue/845/subclass-of-ytarray-throwing… Matthew Turk: This script works for float64, but fails for float32. ``` #!python from yt.units import cm from yt.data_objects.octree_subset import YTPositionArray import numpy as np a = np.random.random(100).astype("float32") * cm a *= np.finfo(a.dtype).eps b = YTPositionArray(np.random.random((100, 3)).astype("float32"), input_units="cm") print type(b) b *= np.finfo(b.dtype).eps ``` It's also at paste 4674. Responsible: ngoldbaum

1 0

PhasePlot units+
by Sam Leitner 21 May '14

21 May '14

Hi yt folks, I ran into a problem with PhasePlot that's also apparent in the docs. See the last couple of plots here: http://yt-project.org/docs/dev-3.0/analyzing/units/units_and_plotting.html the color bar doesn't re-scale with set_unit changes currently. I couldn't easily reverse engineer what is done to get this right in e.g. slice plot (but, as a work-around, I just defined a new field with the correct units). Also, does PhasePlot have set_x/ylim functionality that I'm not finding? Thanks! Sam

2 2

[continued] RAMSES units bug in yt-3.0
by Sam Geen 21 May '14

21 May '14

Ah, very good, thanks for the link to that old PR! I was worried I was going crazy... in any case, whichever is the easiest way to make the position/length units consistent. By the way, I took a quick look at reading the grav_ files recently, although the output seems kind of strange, so I haven't issued a PR yet until I understand what it's doing (plus I still don't 100% understand the units). I suspect it might be reading in the wrong order or something. It also complicates the code, so it might be worth refactoring a bit to make a universal "AMR-like" data_structures/io interface for the files called hydro_, grav_, rt_, etc, rather than what I did which was to scatter a bunch of conditionals into the existing functions. On 13/05/2014 14:21, Matthew Turk wrote: > Hi Sam, > > So, here's an old pull request I found: > > http://hg.yt-project.org/yt-3.0/pull-request/62/adding-boxlen-to-ramses-uni… > > and then there's the units.f90 from RAMSES itself: > > https://bitbucket.org/rteyssie/ramses/src/81ab29b8a405e7ccf6bf30fd67582b4ed… > > I'm going to take care of this, update the PR, and ping you both. > (And maybe we should move to yt-dev? :) > > -Matt > > On Tue, May 13, 2014 at 8:17 AM, Sam Geen <samgeen(a)astro.ox.ac.uk> wrote: >> Huh, that difference in the max density is very strange. I can't think why >> you'd have that difference; it's not an obvious multiple. >> >> Actually, I'm looking at the code and it's possible that the particle >> positions are scaled from 0 to boxlen and the grid positions from 0 to 1, >> though I'd need to open up the raw values in a RAMSES file to confirm this. >> If this is true, I suppose one "fix" could be to hard-multiply the cell >> sizes by pf["boxlen"] when you load them so that the length units are >> consistent for all data. I *think* that the older version of yt-3.0 gave >> correct answers, though, so that should at least be a way to calibrate the >> new version. >> >> >> On 13/05/2014 14:01, nick moeckel wrote: >> >> I had a chance to test out an older and a newer version of yt-3 on a small >> dataset that has boxlen=10. This seems to confirm a boxlen**3 factor >> somewhere, although there's a further difference in the max density. >> >> more recent version (hg id -i gives f4838a2165c0): >> >> after dd = ds.all_data(): >> >> In [11]: dd.quantities.extrema('density') >> >> Out[11]: (2.00739832795e-28 g/cm**3, 4.54771338163e-24 g/cm**3) >> >> >> older version (hg id -i gives 3e8b733c9ee9): >> >> after dd = ds.h.all_data(): >> >> In [10]: dd.quantities.extrema('Density') >> >> Out[10]: [(2.0073983279492632e-25, 4.0079147772594363e-21)] >> >> >> >> On Fri, May 9, 2014 at 5:50 PM, Sam Geen <samgeen(a)astro.ox.ac.uk> wrote: >>> Yep, that looks like it should work. I'll try to run it on some particle >>> data when I get the time, but like I said I'm 99% sure the mass units should >>> be identical for both grid hydro and particle data. >>> >>> >>> On 09/05/14 17:46, Matthew Turk wrote: >>>> Hi Sam, >>>> >>>> Okay, I've looked over a bit, and I think the correct change would be: >>>> >>>> mass_unit = rho_u * length_unit**3. >>>> >>>> That should include the correct length unit, and I think will reduce >>>> "density" back to the "unit_d" that's in the parameter file. If this >>>> looks okay to you, I will push it, but I really do want to make sure >>>> the particle masses are correct. Can Nick or Romain provide a bit of >>>> guidance here? >>>> >>>> -Matt >>>> >>>> On Fri, May 9, 2014 at 11:25 AM, Sam Geen <samgeen(a)astro.ox.ac.uk> wrote: >>>>> OK, interesting. In theory RAMSES should have identical units for both >>>>> particles and gas. I can hunt down a run with particles to test if you >>>>> like. >>>>> >>>>> Thanks! >>>>> Sam >>>>> >>>>> >>>>> On 09/05/14 17:22, Matthew Turk wrote: >>>>>> Hi Sam, >>>>>> >>>>>> On reflection, I think this might be related to getting the *particle* >>>>>> masses correct. I will take a look at it as soon as I can. >>>>>> >>>>>> -Matt >>>>>> >>>>>> On Fri, May 9, 2014 at 11:00 AM, Sam Geen <samgeen(a)astro.ox.ac.uk> >>>>>> wrote: >>>>>>> Hmm, that looks like it should be "mass_unit = rho_u * length_unit**3" >>>>>>> in >>>>>>> line 492. You're right that it mentions the boxlength issue, though. >>>>>>> >>>>>>> >>>>>>> On 09/05/14 16:50, Matthew Turk wrote: >>>>>>>> Hi Sam, >>>>>>>> >>>>>>>> Okay, sounds good. Looking at how code unit attributes are set up: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://bitbucket.org/yt_analysis/yt/src/a14a150c7c81850df81346162bdaff271e… >>>>>>>> >>>>>>>> suggests to me that length_unit takes into account boxlen, and >>>>>>>> mass_unit does not. The comments have some indication why this might >>>>>>>> be. >>>>>>>> >>>>>>>> -Matt >>>>>>>> >>>>>>>> On Fri, May 9, 2014 at 10:46 AM, Sam Geen <samgeen(a)astro.ox.ac.uk> >>>>>>>> wrote: >>>>>>>>> Yep; both this and dd["density"] give cgs values that are too small >>>>>>>>> by >>>>>>>>> roughly a factor of boxlen**3. >>>>>>>>> >>>>>>>>> One other thing I need to try is to make sure I'm using the very >>>>>>>>> latest >>>>>>>>> version of YT; I've been playing around with the Ramses frontend so >>>>>>>>> it's >>>>>>>>> possible my version is somehow out of sync. Will let you know if >>>>>>>>> this >>>>>>>>> fixes >>>>>>>>> things. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/05/14 16:42, Matthew Turk wrote: >>>>>>>>>> Hi Sam, >>>>>>>>>> >>>>>>>>>> Can you verify the units are in fact incorrect in *cgs*? Something >>>>>>>>>> like this would work: >>>>>>>>>> >>>>>>>>>> ds = load(...) >>>>>>>>>> dd = ds.all_data() >>>>>>>>>> print dd.quantities.total_quantitiy("cell_mass").in_cgs() >>>>>>>>>> >>>>>>>>>> Your second message makes me wonder if there's just a slipup in how >>>>>>>>>> the units are returned. >>>>>>>>>> >>>>>>>>>> -Matt >>>>>>>>>> >>>>>>>>>> On Fri, May 9, 2014 at 10:37 AM, Sam Geen <samgeen(a)astro.ox.ac.uk> >>>>>>>>>> wrote: >>>>>>>>>>> Sorry for the spam; a second bug I've seen is that the density and >>>>>>>>>>> pressure >>>>>>>>>>> unit labels on figures appears to be broken; it seems to print a >>>>>>>>>>> latex-mangled code names for the units rather than the cgs name of >>>>>>>>>>> the >>>>>>>>>>> units; see attached example. Temperature is fine. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 09/05/14 16:28, Sam Geen wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Just to say that in the latest version of yt-3.0 (i.e. since >>>>>>>>>>>> various >>>>>>>>>>>> fields were renamed or re-implemented), I've found a bug in the >>>>>>>>>>>> implementation of "cell_mass", which is giving results that are >>>>>>>>>>>> too >>>>>>>>>>>> low >>>>>>>>>>>> in >>>>>>>>>>>> my runs; I believe the issue is that it's missing a factor of >>>>>>>>>>>> pf["boxlen"]**3 (which is of course only a problem if boxlen is >>>>>>>>>>>> not >>>>>>>>>>>> 1). >>>>>>>>>>>> The >>>>>>>>>>>> previous "CellMass_Msun" worked fine. If I get time I might take >>>>>>>>>>>> a >>>>>>>>>>>> look >>>>>>>>>>>> and >>>>>>>>>>>> issue a pull request, but otherwise I'm just flagging this in >>>>>>>>>>>> case >>>>>>>>>>>> someone >>>>>>>>>>>> else runs into problems; you can just manually multiply the >>>>>>>>>>>> result >>>>>>>>>>>> by >>>>>>>>>>>> pf["boxlen"]**3 until it's fixed. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Sam >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> _______________________________________________ >>>>>> 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 >>>> _______________________________________________ >>>> 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 >> >> >> >> _______________________________________________ >> 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 >> > _______________________________________________ > yt-users mailing list > yt-users(a)lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

3 8

Issue #844: ProjectionCamera not in right-handed orientation (yt_analysis/yt)
by Cameron Hummels 21 May '14

21 May '14

New issue 844: ProjectionCamera not in right-handed orientation https://bitbucket.org/yt_analysis/yt/issue/844/projectioncamera-not-in-righ… Cameron Hummels: It appears that the ProjectionCamera is not in the right-handed orientation like the PlotWindow objects are. You can see this in the docs here: http://yt-project.org/docs/dev-3.0/visualizing/plots.html#off-axis-projecti… The 'off_axis_projection' calls ProjectionCamera, which yields an image with the disk horizontal, although in the next script the exact same L and north_vector are used but with OffAxisProjectionPlot, which yields an image with the disk vertical. I know the camera is getting rewritten right now, so this may change, but I just wanted to list it here in case this issue wasn't resolved after the scene PR.

1 0

Issue #843: YTArray and YTQuantity need docstrings (yt_analysis/yt)
by Cameron Hummels 20 May '14

20 May '14

New issue 843: YTArray and YTQuantity need docstrings https://bitbucket.org/yt_analysis/yt/issue/843/ytarray-and-ytquantity-need-… Cameron Hummels: These two classes need some basic docstrings since they're new and play an integral role in 3.0.

1 0

yt-dev May 2014