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/documentationhttps://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
New issue 847: Total mass fails with zero particles
https://bitbucket.org/yt_analysis/yt/issue/847/total-mass-fails-with-zero...
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
New issue 846: Enzo inline frontend cannot access particle information
https://bitbucket.org/yt_analysis/yt/issue/846/enzo-inline-frontend-canno...
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 .
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
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
New issue 845: Subclass of YTArray throwing errors
https://bitbucket.org/yt_analysis/yt/issue/845/subclass-of-ytarray-throwi...
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
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
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-u...
>
> and then there's the units.f90 from RAMSES itself:
>
> https://bitbucket.org/rteyssie/ramses/src/81ab29b8a405e7ccf6bf30fd67582b4...
>
> 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/a14a150c7c81850df81346162bdaff27...
>>>>>>>>
>>>>>>>> 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
New issue 844: ProjectionCamera not in right-handed orientation
https://bitbucket.org/yt_analysis/yt/issue/844/projectioncamera-not-in-ri...
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-projec...
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.
