error in light_ray periodic ray creation
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.
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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@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@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@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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
participants (3)
-
Britton Smith
-
Joshua Eric Moloney
-
Nathan Goldbaum