[yt-users] ray objects
Matthew Turk
matthewturk at gmail.com
Wed Aug 17 11:24:57 PDT 2011
Elizabeth,
If you check, the sum of dts should be 1.0. Tracking this down, what
I saw happening on my machine (after I was able to replicate the bug)
was that the dts were being set correctly but the t values were not.
The terminating value would have t = 0. I used this test script:
http://paste.enzotools.org/show/1749/
I've committed a fix in hash 6c31049e1a99. Because this touches the
Cython code, you will have to rebuild. If you use "yt instinfo -u"
this should rebuild the code for you.
-Matt
On Tue, Aug 16, 2011 at 4:03 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Elizabeth,
>
> On Tue, Aug 16, 2011 at 3:52 PM, Elizabeth Tasker <taskere at mcmaster.ca> wrote:
>> Hi Sam,
>>
>> I'm not sure that explains it. For instance, if I have:
>>
>> ray = pf.h.ray((13.20485952, 12.60900681, 15.99610771), (13.00047934,
>> 12.22629182, 15.98123388))
>>
>> I get:
>>
>> In [77]: print ray["x"]
>> -------> print(ray["x"])
>> yt : [INFO ] 2011-08-16 15:41:43,802 Getting field t from 28
>> yt : [INFO ] 2011-08-16 15:41:44,573 Getting field x from 28
>> [ 13.00390625 13.20703125 12.99609375 13.19921875 13.19921875
>> 13.19921875 13.19140625 13.19140625 13.19140625 13.18359375
>> 13.18359375 13.18359375 13.17578125 13.17578125 13.16796875
>> 13.16796875 13.16796875 13.16015625 13.16015625 13.16015625
>> 13.15234375 13.15234375 13.15234375 13.15234375 13.14453125
>> 13.14453125 13.14453125 13.13671875 13.13671875 13.13671875
>> 13.12890625 13.12890625 13.12890625 13.12109375 13.12109375
>> 13.12109375 13.11328125 13.11328125 13.10546875 13.10546875
>> 13.10546875 13.09765625 13.09765625 13.09765625 13.08984375
>> 13.08984375 13.08984375 13.08203125 13.08203125 13.08203125
>> 13.07421875 13.07421875 13.07421875 13.06640625 13.06640625
>> 13.06640625 13.05859375 13.05859375 13.05859375 13.05078125
>> 13.05078125 13.04296875 13.04296875 13.04296875 13.04296875
>> 13.03515625 13.03515625 13.03515625 13.02734375 13.02734375
>> 13.02734375 13.01953125 13.01953125 13.01953125 13.01171875
>> 13.01171875 13.01171875 13.00390625 13.00390625]
>>
>>
>> Which ends in the right place, but the first three values look very
>> confused. And dx in this case is the same throughout:
>>
>> In [78]: print ray["dx"]
>> -------> print(ray["dx"])
>> yt : [INFO ] 2011-08-16 15:43:37,576 Getting field dx from 28
>> [ 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125 0.0078125
>> 0.0078125]
>>
>> I did check out that page in the docs originally, but I ran into a couple of
>> problems. Firstly, I wasn't entirely clear whether 't' was a distance or a
>> time (I thought it might be a time based on a ray tracing scheme assuming
>> these were light rays... maybe that was dumb!). Secondly, the variable 'dt'
>> isn't available for me:
>
> 't' is the parameter, running from 0 .. 1. The corresponding dts
> parameter (which shows up in my help(pf.h.ray) call, buyt perhaps is
> not on the current doc page because of a rebuild lag) should be the
> width you are looking for.
>
> If you are starting at a cell corner it could be causing a confusion.
> Sam probably knows a bit more than I do about this. My guess is that
> somehow 't' is getting set incorrectly during the ray walk, and then
> during the sort operation it's coming back at the start of the ray
> value list.
>
> My current best guess is that the RayIntegrator.pyx code has multiple
> hits for "fully enclosed" checks, which should be replaced with "fully
> enclosed *and* not child masked."
>
> -Matt
>
>>
>> In [81]: print ray["dt"]
>> -------> print(ray["dt"])
>> yt : [INFO ] 2011-08-16 15:47:23,212 Getting field dt from 28
>> ---------------------------------------------------------------------------
>> KeyError Traceback (most recent call last)
>>
>> /1/home/taskere/yt/scripts/iyt in <module>()
>> ----> 1
>> 2
>> 3
>> 4
>> 5
>>
>> /1/home/taskere/yt/yt/data_objects/data_containers.py in __getitem__(self,
>> key)
>> 284 if key not in self.fields:
>> 285 self.fields.append(key)
>> --> 286 self.get_data(key)
>> 287 return self.data[key]
>> 288
>>
>> /1/home/taskere/yt/yt/data_objects/data_containers.py in get_data(self,
>> fields, in_grids)
>> 455 mylog.info("Getting field %s from %s", field,
>> len(self._grids))
>> 456 if field not in self.hierarchy.field_list and not
>> in_grids:
>> --> 457 if field not in ("dts", "t") and
>> self._generate_field(field):
>> 458 continue # True means we already assigned it
>> 459 self[field] = na.concatenate(
>>
>> /1/home/taskere/yt/yt/data_objects/data_containers.py in
>> _generate_field(self, field)
>> 436 return True
>> 437 else: # Can't find the field, try as it might
>> --> 438 raise KeyError(field)
>> 439
>> 440 def get_data(self, fields=None, in_grids=False):
>>
>> KeyError: 'dt'
>>
>> Although now I look once more, I do see that 't' is zero for the first three
>> values, so if it is a distance normalised to 1 (which would make a lot more
>> sense!) it does imply they are not corresponding to distances along the ray:
>>
>> In [82]: print ray["t"]
>> -------> print(ray["t"])
>> [ 0. 0. 0. 0.00848673 0.01945132 0.03986468
>> 0.04671206 0.06027804 0.0806914 0.08493739 0.10110477 0.12151813
>> 0.12316273 0.14193149 0.16138806 0.16234486 0.18275822 0.19961339
>> 0.20317158 0.22358495 0.23783872 0.24399831 0.26356426 0.26441167
>> 0.27606405 0.28482503 0.3052384 0.31428938 0.32565176 0.34606512
>> 0.35251471 0.36647849 0.38689185 0.39074004 0.40730521 0.42771857
>> 0.42896537 0.44813194 0.4671907 0.4685453 0.48895866 0.50541603
>> 0.50937203 0.52978539 0.54364136 0.55019875 0.57061212 0.5818667
>> 0.59102548 0.61143884 0.62009203 0.6318522 0.65226557 0.65831736
>> 0.67267893 0.69309229 0.69654269 0.71350566 0.73391902 0.73476802
>> 0.75433238 0.77299335 0.77474574 0.78881566 0.79515911 0.81121868
>> 0.81557247 0.83598583 0.84944401 0.8563992 0.87681256 0.88766934
>> 0.89722592 0.91763929 0.92589467 0.93805265 0.95846601 0.96412
>> 0.97887937]
>>
>>
>> Elizabeth
>>
>>
>>
>>
>> Sam Skillman wrote:
>>>
>>> Hi Elizabeth,
>>>
>>> So the issue here, I think, is that while the rays are sorted, they
>>> traverse varying sized cells. When you query the field 'x', you are
>>> actually querying the 'x' value of the cell that the ray intersects, not the
>>> position of the ray itself. This, in combination with the fact that fields
>>> like 'x' are cell centered, means that you can see weird jumps when you go
>>> from a highly refined cell to a root grid cell. You could check this by
>>> looking at what ray1['dx'] is, and if it is large for the second value, then
>>> this is the issue.
>>>
>>> If you'd like to recover the x,y, position of the ray at that point, I
>>> would use the field 't', which is the integral of dt (distance) along the
>>> ray. You could then use the starting position and the direction to recover
>>> the position along the ray.
>>>
>>> That said, if all you are worried about is the Density, it should in fact
>>> be giving you the ordered density values. If you were to
>>> matplotlib.pylab.plot(ray1['t'], ray1['Density']) it should give you a plot
>>> of the density along the ray.
>>>
>>> For reference, much of this is described here:
>>> http://yt.enzotools.org/doc/analyzing/generating_processed_data.html#line-queries-and-planar-integrals
>>>
>>> Best,
>>> Sam
>>>
>>> On Tue, Aug 16, 2011 at 12:49 PM, Elizabeth Tasker <taskere at mcmaster.ca
>>> <mailto:taskere at mcmaster.ca>> wrote:
>>>
>>> Hi,
>>>
>>> When you create a ray object with yt, e.g.
>>>
>>> ray1 = pf.h.ray([10,16,16], [10.3,16.1,16])
>>>
>>> I was expecting to get the values of the cells that lie inbetween
>>> those two sets of co-ordinates. Instead, it looks like the first
>>> two values back at the start and end points. .e.g.:
>>>
>>> -------> print(ray1["x"])
>>> Warning: divide by zero encountered in divide
>>> Warning: invalid value encountered in multiply
>>> Warning: divide by zero encountered in divide
>>> Warning: invalid value encountered in multiply
>>> yt : [INFO ] 2011-08-16 14:47:27,962 Getting field t from 92
>>> yt : [INFO ] 2011-08-16 14:47:28,972 Getting field x from 92
>>> [ 10.0078125 10.30078125 10.0234375 10.0390625 10.0390625
>>> 10.0546875 10.0703125 10.0859375 10.0859375 10.1015625
>>> 10.1171875 10.1328125 10.1328125 10.1484375 10.1640625
>>> 10.17578125 10.18359375 10.18359375 10.19140625 10.19921875
>>> 10.20703125 10.20703125 10.21484375 10.22265625 10.23046875
>>> 10.23046875 10.23828125 10.24609375 10.25390625 10.25390625
>>> 10.26171875 10.26953125 10.27734375 10.27734375 10.28515625
>>> 10.29296875]
>>>
>>> In [53]: print ray1["y"]
>>> -------> print(ray1["y"])
>>> yt : [INFO ] 2011-08-16 14:48:23,698 Getting field y from 92
>>> [ 16.0078125 16.09765625 16.0078125 16.0078125 16.0234375
>>> 16.0234375 16.0234375 16.0234375 16.0390625 16.0390625
>>> 16.0390625 16.0390625 16.0546875 16.0546875 16.0546875
>>> 16.05859375 16.05859375 16.06640625 16.06640625 16.06640625
>>> 16.06640625 16.07421875 16.07421875 16.07421875 16.07421875
>>> 16.08203125 16.08203125 16.08203125 16.08203125 16.08984375
>>> 16.08984375 16.08984375 16.08984375 16.09765625 16.09765625
>>> 16.09765625]
>>>
>>>
>>> Is that right? Should I ignore the first two values of ray1 when
>>> I'm examining the data, e.g. ray1["Density"]?
>>>
>>> Thanks!
>>>
>>> Elizabeth
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
More information about the yt-users
mailing list