-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Errors to save 3D numpy array in segy file #235
Comments
Hi, and thanks for the detailed report! First of all, I'm sorry, but the example in the https://github.com/Statoil/segyio#examples section is slightly outdated, since Presumably, your volume is post-stack (in which
edit: corrected it should be:
|
For each
The range shown above is the double of the length of all inlines (actually I think I'm making some confusion with the values...however the error seems related to some |
If you do 345*188 gives 64860 and matches your
|
Unfortunately it raises another error:
It still seem related to the dimensions, but I can't see the problem! |
Interesting. That one should show up if the tracecount is not set up properly. What does |
For what it's worth, I just ran this:
No errors. |
It is really weird: it raised the same error and the output of Could be something related to my python installation or maybe another library I use?
|
I doubt there's something installed, but you never know. What's your segyio version? Can you post your full create function and all spec arguments? This does give me a few ideas for usability improvements and error messages. |
The version is
I did a quick test and maybe I found the problem...I think it is the amount of traces/file size. I cropped my data and then a file was generated without error message (using the "second method" to write the file). I was slightly increasing the size but it seems there is a limit of 42,190,800 bytes in the file size (when I tried to read a error message said the size indicated in the header was different form the actual data size). |
Interesting, what system are you running this on. This really looks like a 32/64 bit issue from your description, and I'd love to get to the bottom of that. |
I'm using Ubuntu |
Hi, I just reproduced your error on my Debian Stretch python 3.5 implementation, so this is not a system-specific issue for you. I'll figure out a fix for you! |
Thank you!! |
Ok, I think I figured it out. It was an overflow, but due to a 16-bit integer. Some context: when I read the standard, I must've misinterpreted (and really glossed over a VERY important detail) the wording "Number of data traces per ensemble" to mean "traces-in-this-file". This field is 2 bytes and overflows right away. During a refactoring pass, in order to generalise, I used this field to pass size information from I'll issue a fix on this as soon as possible. |
Very good news!! |
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
Ok, so I've written a tiny patch that should fix this issue. #236 I'm gonna let the CI do its business before I merge it into master (it should be quite safe) and release the next bugfix release of segyio. If you're savvy enough to build segyio yourself from source, I'd love it if you checked out the changes and tried if it solves your problem. If it does, the bugfix should be freely available sometime tomorrow. |
I have to run now, but I just want to thank you for using segyio and many thanks for a great bug report! We're obviously happy to help you with any other issues you might have. |
I've cloned and built it successfully, but I don't remember how to 'force' importing the version I've build. |
The typical way to do that would be either to overwrite your existing install (assuming it's |
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
My problem is Python is installed via Anaconda, so only editing the `
PYTHONPATH` didn't work...
I'll try a work around asap.
…On Wed, Mar 14, 2018 at 8:59 PM, Jørgen Kvalsvik ***@***.***> wrote:
The typical way to do that would be either to overwrite your existing
install (assuming it's pip --user it would be in ~/.local, otherwise
typically in /usr/local/) or manipulate the PYTHONPATH environment
variable to make sure your new version is picked up.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#235 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJrEtjbFJjVi68GdN2rfVF8jj7E5F12Xks5tea74gaJpZM4SpRuy>
.
--
Att,
Victor Almeida.
|
With my user and Anaconda installation I didn't find how to 'force' the build version.
|
Is this on Ubuntu? The installation script might be broken, and not properly installing the library to |
Yes, the file is in |
Ok, that means that the cmake You can manually copy or symlink the file from |
Manually copying didn't work, but creating symlink in |
I just tested now and it seems the error is still there:
Is it related to the trace length? I remember in somewhere it complained about a negative value for some input/output it was using. |
No, it's a bug internal to Did you apply my patch, or is this a clean checkout? |
I built from your repository ( |
Only if you check-out the |
hehe... |
@jokva I tested and the file was written! I write and read with segyio without problems! |
Not surprisng that Great that it now works - this has surely been a useful report. I'll figure out how to test for this and merge the patch upstream. Thank you again for your contribution. Please let me know how it works with OpendTect. |
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in equinor#235
The cheeky trick of passing the number of traceheaders in the binary header when creating new files, in a field that is not dedicated to number-of-traces-per-file, doesn't work because it's only 16 bits and overflows very fast, and SEG-Y allows for 32-bits of traces (governed by traceno). Instead, pass the override-number-of-traces argument to the internal filehandle constructor explicitly, and only consider that number if the binary header is also passed. This fixes the issue reported in #235
I was asking how to convert a numpy array(as data) to segy file.Previously have converted the same to segy file but it's 2d in nature i.e., I can't create 3d parameters say depth at particular inline/crossline,,can't define inline and cross line of my own etc etc.. |
https://segyio.readthedocs.io/en/latest/segyio.html#segyio.tools.from_array3D should do what you want. |
@jokva have seen it but the error I am now facing tells ":AttributeError: module 'segyio' has no attribute 'tools'" on running this command"segyio.tools.from_array3D(path,data)". |
@jokva got the seg-y file from 3d array but it doesn't contain any data ,,like while plotting it I can't access the specified inline and crossline also when am viewing it in my segy tool its void. |
I'm trying to write in a segy file a 3D data that I calculated and it is in the format of
numpy.ndarray
with shape(501, 64860)
(first dimension is time), so each column is a trace.First I tried to follow the example Make segy file from sctrach (https://github.com/Statoil/segyio#examples):
Then, it raised the error:
My second attempt was following (in some way) this:
I know there is at least one problem in this second attempt, the variable
spec.offsets
, the reason for the error:If I don't use this variable (as if I don't have the info to write in the header, so that I comment
#spec.offsets = range(188)
), the error message is:Just to mention, when I run the example from the repository main page (
Make segy file from sctrach
), a similar error message is shown:The text was updated successfully, but these errors were encountered: