[yt-users] error in light_ray periodic ray creation

Fri Jul 27 16:18:16 PDT 2012

Hi Josh,

I'm not sure what's causing that as it's never happened to me before. I'm
away from my computer at the moment but I will take a look at this later.
Is the script you're using unaltered?  If not, please send me the one
you're using off-list.

Also, please make sure to send emails to the list from the address that you
signed up with. Otherwise, it has to be approved by the moderator each time.

Britton
On Jul 27, 2012 7:05 PM, "Joshua Eric Moloney" <Joshua.Moloney at colorado.edu>
wrote:

> The install I'm running should be the latest stable version of the code:
>
> The current version of the code is:
>
> ---
> c23cb264f04c (stable)
> ---
>
> -Josh
>
>
> On Fri, Jul 27, 2012 at 4:54 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:
>
>> Hi Joshua,
>>
>> I can't speak to the problem you're having specifically.  However, since
>> there have been some recent updates to the light ray, it would help us to
>> figure out what's happening if you could reply with the output of the "yt
>> instinfo" command, run on the command line.
>>
>> Cheers,
>>
>> Nathan
>>
>> On Jul 27, 2012, at 3:49 PM, Joshua Eric Moloney wrote:
>>
>> Hi all,
>>
>> I've been trying to get a script (provided to me by Britton) working to
>> create a bunch of light rays from an Enzo simulation. Depending on the
>> initial seed value, it makes some of them correctly but eventually fails
>> with the following error:
>>
>> Traceback (most recent call last):
>>   File "make_light_rays.py", line 32, in <module>
>>     get_los_velocity=True, get_nearest_galaxy=False)
>>   File "/home/student/jomo9722/Enzo/
>> yt-x86_64/src/yt-hg/yt/analysis_modules/light_ray/light_ray.py", line
>> 275, in make_light_ray
>>     (sub_ray[field])])
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
>> line 319, in __getitem__
>>     self.get_data(key)
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
>> line 508, in get_data
>>     if field not in ("dts", "t") and self._generate_field(field):
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
>> line 349, in _generate_field
>>     self[field] = self.pf.field_info[field](self)
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.py",
>> line 316, in __call__
>>     dd = self._function(self, data)
>>   File
>> "/data/moloney/cosmology_test/test_new/ion_balance/SD93IonBalance.py", line
>> 178, in _ion_number_density
>>     return solarAbundance[atom] * data[fractionField] *
>> data['Metallicity'] * \
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
>> line 319, in __getitem__
>>     self.get_data(key)
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
>> line 508, in get_data
>>     if field not in ("dts", "t") and self._generate_field(field):
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
>> line 349, in _generate_field
>>     self[field] = self.pf.field_info[field](self)
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/data_objects/field_info_container.py",
>> line 316, in __call__
>>     dd = self._function(self, data)
>>   File
>> "/data/moloney/cosmology_test/test_new/ion_balance/SD93IonBalance.py", line
>> 193, in _ion_fraction_field
>>     fraction = na.power(10, interp(data))
>>   File
>> "/home/student/jomo9722/Enzo/yt-x86_64/src/yt-hg/yt/utilities/linear_interpolators.py",
>> line 44, in __call__
>>     x_i = (na.digitize(x_vals, self.x_bins) - 1).astype('int32')
>> ValueError: Both x and bins must have non-zero length
>>
>> Working through the debugger, I found that for the segment where it
>> failed the periodic_ray function had produced the following list of
>> segments.
>>
>> [[array([ 0.16103374,  0.78830872,  0.24846128]), array([ 0.14031834,
>> 0.57367409,  1.        ])], [array([ 0.14031834,  0.57367409,  1.
>> ]), array([ 0.14031834,  0.57367409,  1.        ])], [array([ 0.14031834,
>> 0.57367409,  0.        ]), array([ 0.13268221,  0.49455532,  0.2770327 ])]]
>>
>> The second segment here has identical start and end points, which is
>> leading yt to try to interpolate a field with nothing in it (and therefore
>> throwing the above error). It seems that what's happening is that due to
>> rounding errors the first segment being produced actually has a value < 1
>> for the third dimension so that when it checks to see if the segment hit
>> any of the box walls it thinks that it didn't. It then tries to start a new
>> segment that's already at the boundary of the box, producing a ray segment
>> containing 0 grid cells.
>>
>> Has anyone run into this problem before, and is there a fix for it
>> floating around out there somewhere? If not I could probably work something
>> up that checks to see if the distance from the segment endpoint to the wall
>> is < SmallNumber and set it equal to the value at the wall if it is.
>>
>> Thanks.
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20120727/214b77bb/attachment.htm>