I think Cameron, Britton, and Devin have done this for their Trident project - you might want to contact them. On Mon, Feb 15, 2016 at 3:23 PM, Bili Dong - Gmail wrote:

Hi Matt,

I've tried to construct the ray and ortho_ray objects, neither of which can reproduce the error. They work just fine. I haven't succeeded in tracing down the error yet, but I'll keep working on that.

Besides, I'm wondering if there are examples of successfully making light rays in a particle dataset? That may help figuring out what might go wrong.

Thanks, Bili

On Fri, Feb 12, 2016 at 12:42 PM, Matthew Turk wrote:

...

Hi Bili,

Hm, I'm honestly not sure. This looks like an oddity in the way the octree is being constructed in spatial dimensions. Any chance you can reproduce this with a ray or ortho_ray object, which should simplify the number of moving parts?

On Tue, Feb 9, 2016 at 2:04 PM, Bili Dong - Gmail wrote:

...

Hi yt users,

I'm trying to make a light ray for a gadget dataset using this script: http://paste.yt-project.org/show/6234/

But I get the following error:

```

/Users/qobilidop/repos/yt/yt/geometry/geometry_handler.py in fcoords(self) 320 c = obj.select_fcoords(self.dobj) 321 if c.shape[0] == 0: continue--> 322 ci[ind:ind+c.shape[0], :] = c 323 ind += c.shape[0] 324 return ci ValueError: could not broadcast input array from shape (81,3) into shape (40,3)

```

My yt is on the changeset d47150dfbde6.

I'm wondering if I'm doing it the correct way? And how could I solve the problem?

Thanks,

Bili

_______________________________________________ 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 Britton, I was using the yt sample dataset 'GadgetDiskGalaxy/snapshot_200.hdf5' to test the functionality. Thanks, Bili On Wed, Feb 24, 2016 at 2:39 AM, Britton Smith wrote:

Hi Bili,

My apologies for the long delay in replying to this thread. By now, I think you may be working with Trident. If things are working, that's great. However, Trident relies on much of the machinery that you were trying to use, so it's still possible that you see this error. The problem is likely related to how the LightRay generator is calculating the trajectory for the ray and not with the underlying ray machinery which it relies on. If it's possible for you to give me access to this dataset, I would be happy to take a look at this.

Britton

On Mon, Feb 15, 2016 at 9:30 PM, Nathan Goldbaum wrote:

...

I think Cameron, Britton, and Devin have done this for their Trident project - you might want to contact them.

On Mon, Feb 15, 2016 at 3:23 PM, Bili Dong - Gmail wrote:

...

Hi Matt,

I've tried to construct the ray and ortho_ray objects, neither of which can reproduce the error. They work just fine. I haven't succeeded in tracing down the error yet, but I'll keep working on that.

Besides, I'm wondering if there are examples of successfully making light rays in a particle dataset? That may help figuring out what might go wrong.

Thanks, Bili

On Fri, Feb 12, 2016 at 12:42 PM, Matthew Turk wrote:

...

Hi Bili,

Hm, I'm honestly not sure. This looks like an oddity in the way the octree is being constructed in spatial dimensions. Any chance you can reproduce this with a ray or ortho_ray object, which should simplify the number of moving parts?

On Tue, Feb 9, 2016 at 2:04 PM, Bili Dong - Gmail wrote:

...

Hi yt users,

I'm trying to make a light ray for a gadget dataset using this script: http://paste.yt-project.org/show/6234/

But I get the following error:

```

/Users/qobilidop/repos/yt/yt/geometry/geometry_handler.py in fcoords(self) 320 c = obj.select_fcoords(self.dobj) 321 if c.shape[0] == 0: continue--> 322 ci[ind:ind+c.shape[0], :] = c 323 ind += c.shape[0] 324 return ci ValueError: could not broadcast input array from shape (81,3) into shape (40,3)

```

My yt is on the changeset d47150dfbde6.

I'm wondering if I'm doing it the correct way? And how could I solve the problem?

Thanks,

Bili

_______________________________________________ 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

Hi all, I will take a look at this, but have limited time today. I think Britton's error tracking is right -- it's a difference in the tcoords and fcoords, which shouldn't happen. A few things that I will check are what happens if tcoords is chosen for orthogonal rays, which has a slightly different selection method, and what the input selector to the octree tcoords function is. On Thu, Feb 25, 2016 at 8:39 AM, Britton Smith wrote:

Hi Bili,

I have looked into this and it seems there are some problems with generating rays with particle datasets. I cannot tell whether yours is a special case, but what seems to be happening is that certain fields are being returned with different sizes. The error happens in the LightRay code because it first tries to access the "t" field, which comes back with size 40. After that, it tries to access one of the coordinate fields ("x", "y", or "z") and that is being returned with size 81, which doesn't fit into the arrays made to hold it that already have size 40.

Anyway, you're not seeing this when you make the ray yourself if you first try to access a field other than the "t" field. This results in the field arrays being made with the larger size. If you do this and then try to access the "t" array, you will find that the first 40 values have real numbers but that the rest are just uninitialized values.

Unfortunately, I haven't gotten much past this as I'm having trouble seeing where the fcoords for this particular object are getting generated. I have created an issue, which you can follow here: https://bitbucket.org/yt_analysis/yt/issues/1175/fcoords-and-tcoords-not-the...

That's about all I can do for now, but if anyone has any thoughts, help would be appreciated.

Britton

On Wed, Feb 24, 2016 at 7:21 PM, Bili Dong - Gmail wrote:

...

Hi Britton,

I was using the yt sample dataset 'GadgetDiskGalaxy/snapshot_200.hdf5' to test the functionality.

Thanks, Bili

On Wed, Feb 24, 2016 at 2:39 AM, Britton Smith wrote:

...

Hi Bili,

My apologies for the long delay in replying to this thread. By now, I think you may be working with Trident. If things are working, that's great. However, Trident relies on much of the machinery that you were trying to use, so it's still possible that you see this error. The problem is likely related to how the LightRay generator is calculating the trajectory for the ray and not with the underlying ray machinery which it relies on. If it's possible for you to give me access to this dataset, I would be happy to take a look at this.

Britton

On Mon, Feb 15, 2016 at 9:30 PM, Nathan Goldbaum wrote:

...

I think Cameron, Britton, and Devin have done this for their Trident project - you might want to contact them.

On Mon, Feb 15, 2016 at 3:23 PM, Bili Dong - Gmail wrote:

...

Hi Matt,

I've tried to construct the ray and ortho_ray objects, neither of which can reproduce the error. They work just fine. I haven't succeeded in tracing down the error yet, but I'll keep working on that.

Besides, I'm wondering if there are examples of successfully making light rays in a particle dataset? That may help figuring out what might go wrong.

Thanks, Bili

On Fri, Feb 12, 2016 at 12:42 PM, Matthew Turk wrote:

...

Hi Bili,

Hm, I'm honestly not sure. This looks like an oddity in the way the octree is being constructed in spatial dimensions. Any chance you can reproduce this with a ray or ortho_ray object, which should simplify the number of moving parts?

On Tue, Feb 9, 2016 at 2:04 PM, Bili Dong - Gmail wrote: > > Hi yt users, > > I'm trying to make a light ray for a gadget dataset using this > script: http://paste.yt-project.org/show/6234/ > > But I get the following error: > > ``` > > /Users/qobilidop/repos/yt/yt/geometry/geometry_handler.py in > fcoords(self) > 320 c = obj.select_fcoords(self.dobj) > 321 if c.shape[0] == 0: continue > --> 322 ci[ind:ind+c.shape[0], :] = c > 323 ind += c.shape[0] > 324 return ci > > ValueError: could not broadcast input array from shape (81,3) into > shape (40,3) > > ``` > > > My yt is on the changeset d47150dfbde6. > > > I'm wondering if I'm doing it the correct way? And how could I solve > the problem? > > > Thanks, > > Bili > > > _______________________________________________ > 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

_______________________________________________ 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 Cameron, No, I think it's unrelated -- probably clowser to the way selectors work. On Tue, Mar 1, 2016 at 8:46 AM, Cameron Hummels wrote:

Do you guys think this is related to the problem we encountered a few months ago with SPH datasets where regions of "zero" density were just filtered out of the LightRay to avoid NaNs and such? It seemed like our fix was too kludgy, but perhaps this is unrelated.

On Thu, Feb 25, 2016 at 6:39 AM, Britton Smith wrote:

...

Hi Bili,

I have looked into this and it seems there are some problems with generating rays with particle datasets. I cannot tell whether yours is a special case, but what seems to be happening is that certain fields are being returned with different sizes. The error happens in the LightRay code because it first tries to access the "t" field, which comes back with size 40. After that, it tries to access one of the coordinate fields ("x", "y", or "z") and that is being returned with size 81, which doesn't fit into the arrays made to hold it that already have size 40.

Anyway, you're not seeing this when you make the ray yourself if you first try to access a field other than the "t" field. This results in the field arrays being made with the larger size. If you do this and then try to access the "t" array, you will find that the first 40 values have real numbers but that the rest are just uninitialized values.

Unfortunately, I haven't gotten much past this as I'm having trouble seeing where the fcoords for this particular object are getting generated. I have created an issue, which you can follow here:

https://bitbucket.org/yt_analysis/yt/issues/1175/fcoords-and-tcoords-not-the...

That's about all I can do for now, but if anyone has any thoughts, help would be appreciated.

Britton

On Wed, Feb 24, 2016 at 7:21 PM, Bili Dong - Gmail wrote:

...

Hi Britton,

I was using the yt sample dataset 'GadgetDiskGalaxy/snapshot_200.hdf5' to test the functionality.

Thanks, Bili

On Wed, Feb 24, 2016 at 2:39 AM, Britton Smith wrote:

...

Hi Bili,

My apologies for the long delay in replying to this thread. By now, I think you may be working with Trident. If things are working, that's great. However, Trident relies on much of the machinery that you were trying to use, so it's still possible that you see this error. The problem is likely related to how the LightRay generator is calculating the trajectory for the ray and not with the underlying ray machinery which it relies on. If it's possible for you to give me access to this dataset, I would be happy to take a look at this.

Britton

On Mon, Feb 15, 2016 at 9:30 PM, Nathan Goldbaum wrote:

...

I think Cameron, Britton, and Devin have done this for their Trident project - you might want to contact them.

On Mon, Feb 15, 2016 at 3:23 PM, Bili Dong - Gmail wrote:

...

Hi Matt,

I've tried to construct the ray and ortho_ray objects, neither of which can reproduce the error. They work just fine. I haven't succeeded in tracing down the error yet, but I'll keep working on that.

Besides, I'm wondering if there are examples of successfully making light rays in a particle dataset? That may help figuring out what might go wrong.

Thanks, Bili

On Fri, Feb 12, 2016 at 12:42 PM, Matthew Turk wrote: > > Hi Bili, > > Hm, I'm honestly not sure. This looks like an oddity in the way the > octree is being constructed in spatial dimensions. Any chance you can > reproduce this with a ray or ortho_ray object, which should simplify the > number of moving parts? > > On Tue, Feb 9, 2016 at 2:04 PM, Bili Dong - Gmail > wrote: >> >> Hi yt users, >> >> I'm trying to make a light ray for a gadget dataset using this >> script: http://paste.yt-project.org/show/6234/ >> >> But I get the following error: >> >> ``` >> >> /Users/qobilidop/repos/yt/yt/geometry/geometry_handler.py in >> fcoords(self) >> 320 c = obj.select_fcoords(self.dobj) >> 321 if c.shape[0] == 0: continue >> --> 322 ci[ind:ind+c.shape[0], :] = c >> 323 ind += c.shape[0] >> 324 return ci >> >> ValueError: could not broadcast input array from shape (81,3) into >> shape (40,3) >> >> ``` >> >> >> My yt is on the changeset d47150dfbde6. >> >> >> I'm wondering if I'm doing it the correct way? And how could I solve >> the problem? >> >> >> Thanks, >> >> Bili >> >> >> _______________________________________________ >> 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

_______________________________________________ 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

-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org

_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org