[yt-users] error in light_ray periodic ray creation
Britton Smith
brittonsmith at gmail.com
Wed Aug 1 06:33:13 PDT 2012
Hi Josh,
I've push a fix that adds a tolerance for checking when a ray reaches the
edge of the domain as you suggested. If you update your development yt
install, it should be all set.
Britton
On Mon, Jul 30, 2012 at 2:39 PM, Joshua Eric Moloney <
Joshua.Moloney at colorado.edu> wrote:
> Britton,
>
> I updated to the yt-dev branch with your fix in it, but it still doesn't
> seem to have fixed the problem. I reran my script (modified for the update
> version of yt) with the same seed values, and it fails in the same place
> with an identical error.
>
> The light ray segment that it fails on is
>
> [ 0.16103374 0.78830872 0.24846128] to [ 0.13268221 0.49455532
> 1.2770327 ]
>
> which is still getting split into subsegments:
>
>
> [[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 subsegment that it actually fails on is
>
> Getting subsegment: [0.14031833857011128, 0.5736740852620702,
> 0.99999999999999989] to [0.14031833857011128, 0.5736740852620702, 1.0]
>
> which I think confirms that the issue is a rounding error leading to the
> segment not getting split properly. (It looks like the start and endpoints
> in the third dimension are exactly one bit off.) One thing I didn't notice
> before is this error will probably only occur if you're using your
> ion_balance module to get ion fractions, because it fails on a call for
> interpolation. This wouldn't happen with any of the standard fields (I
> think) so all it would do is attach a subsegment with nothing in it and
> continue. I'll send the exact script I'm using to you off list in case
> there's something I'm doing wrong in there.
> - Josh
>
>
> On Sat, Jul 28, 2012 at 2:23 PM, Britton Smith <brittonsmith at gmail.com>wrote:
>
>> Hi Josh,
>>
>> I think I was able to find the source of the error. There was a case in
>> which rays start on the edge of the domain and are oriented outward that I
>> hadn't accounted for correctly. I've just pushed a fix for this to the
>> development branch of yt. If you update to the yt branch within the repo,
>> it should be fine. However, there was also a minor change in the LightRay
>> api, so you'll need to adjust your script a little bit. If you change your
>> script to resemble something like the following:
>> http://paste.yt-project.org/show/2579/
>> everything should be fine.
>>
>> Let me know if you encounter any more issues.
>>
>> Britton
>>
>>
>> On Fri, Jul 27, 2012 at 7:18 PM, Britton Smith <brittonsmith at gmail.com>wrote:
>>
>>> 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
>>>>
>>>>
>>
>> _______________________________________________
>> 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/20120801/1b9dc95c/attachment.htm>
More information about the yt-users
mailing list