ValueError on Map_Texture as a result of X & Y values of []

[LZarri]

Hello @dbuscombe-usgs @danhamill

I am getting a "ValueError: zero-size array to reduction operation minimum which has no identity" while using map_texture. The error happens regularly at the third "getting point cloud" of my sonar file, which I assume is the third chunk. After putting "print X" & "print Y" above the offending line I determined that the cause of this error is values of [] for both X and Y. Can this chunk be bypassed? I am currently using a chunk delineator of 5 degrees.

Thank you, Liam

[danhamill]

@LZarri

I have gotten that error before, usually with really small scans. In your case, chunk 3 might be really small. Have you tried using different chunk sizes?

[LZarri]

Yes, I have tried chunk sizes of 'h5', 'h10', 'd100' and '1' and I continue to get error messages

[LZarri]

Any suggestions on this one? Every module is now working except for map_texture, in which I continue to get this problem. Let me know if there is any more info I can provide.

Best, Liam

[danhamill]

Is this the same scan you were working up in the previous thread?

On Fri, Sep 2, 2016 at 1:49 PM, LZarri notifications@github.com wrote:

Any suggestions on this one? Every module is now working except for map_texture, in which I continue to get this problem. Let me know if there is any more info I can provide.

Best, Liam

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dbuscombe-usgs/PyHum/issues/28#issuecomment-244483893, or mute the thread https://github.com/notifications/unsubscribe-auth/AK_TUhRJ9G79H3e8LEwjnV0XGcPqsxvWks5qmIvDgaJpZM4JIgAU .

[LZarri]

Yes, although this problem persists for many of the scans I have tried

[danhamill]

Ok. The only reason I asked was I saw it completed the read module in 5 seconds. I have also had a hard time processing small scans(i.e. .SON files less than 1MB).

I have also encountered this error and don’t know what is going on. I spend some time earlier this week trying to figure it out and concluded

X, Y, merge = trim_xys(X, Y, merge, index)

returns empty arrays. I think something strange is happening in the cwt.c script.

@dbuscombe-usgs what do you think might be going on? ​

On Fri, Sep 2, 2016 at 2:27 PM, LZarri notifications@github.com wrote:

Yes, although this problem persists for many of the scans I have tried

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dbuscombe-usgs/PyHum/issues/28#issuecomment-244491415, or mute the thread https://github.com/notifications/unsubscribe-auth/AK_TUkaCT1dVJpKB-sTvdlBTUmQQ9rZHks5qmJSpgaJpZM4JIgAU .

[dbuscombe-usgs]

The arrays are empty because no texture lengthscales were computed by the texture module. This is most likely because you chose a value of maxscale that was too high. The default is 20. That means that for a window size of 100, the maximum scale returned will be 5 (100/20). If the window size is 40, the maximum scale will be 2 (40/20). Use a smaller maximum scale. Ideally, the maximum scale value should be tied to the window size in order to get a consistent maximum scale

[dbuscombe-usgs]

I suggest using 'maxscale = win / 5'. This will provide consistent scaling between the choice of window size, and the largest lengthscale permitted from the wavelet analysis