[yt-users] error in light_ray periodic ray creation

[Joshua Eric Moloney]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20120727/92b74c58/attachment.htm>