[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