zgy_writer

[ksurf1]

zgy_writer

[ksurf1]

this code works. I would like to be able to set a compressor and lodcompressor

Does anyone have a syntax for using the compressor arguments to Writer ?

[trhallam]

Thanks for your feedback.

Ideally this code needs to be migrated to use pyzgy on the backend and as a natural xarray backend but that is low priority with focus being SEGY.

You can see the openzgy code in the pyzgy library which is a fork of the code from the OSDU implementation. It also uses the Python API reference implementation which does not natively support compression. Additional instructions must be followed on their website to install the ZFP compressor.

Otherwise:

• blocks are [64,64,64] by default.
• references to output type are given here

To change the output datatype, in the segysak code you could add additional checks for the datatype to select the correct format to output to ZgyWriter.

[ksurf1]

Hi Tony, Thanks for the info. I did modify your code for the datatype and datarange and it works. I was wondering how to go even further but it looks compression only is available for float datatype. Anyway I shared my modif on GitHub. Note: I am using octave and multi threading to read segy files and netcdf as storage. Writing goes mulch faster precasting the headers as uint32 swapping bytes correctly first. Thanks again. Good work.

On Thu, May 25, 2023 at 03:32 Tony Hallam ***@***.***> wrote: Thanks for your feedback. Ideally this code needs to be migrated to use pyzgy on the backend and as a natural xarray backend <https://docs.xarray.dev/en/stable/internals/how-to-add-new-backend.html> but that is low priority with focus being SEGY. You can see the openzgy code in the pyzgy library which is a fork of the code from the OSDU implementation <https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/seismic/open-zgy/-/tree/master/python/openzgy>. It also uses the Python API reference implementation which does not natively support compression. Additional instructions must be followed on their website to install the ZFP compressor. Otherwise: - blocks are [64,64,64] by default. - references to output type are given here <https://github.com/equinor/pyzgy/blob/36c8f4d640dd03510ca47569b8b36eaca0104334/openzgy/api.py#L138> To change the output datatype, in the segysak code you could add additional checks for the datatype to select the correct format to output to ZgyWriter. — Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZG2VEB4DWZBSG7EYR2ZR33XH4KJTANCNFSM6AAAAAAYLDB3OY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Vincent Favreau.

[da-wad]

@ksurf1 depending on your aims here, you may find converting your SEG-Y files to either the fully opensource seismic-zfp or Bluware's nearly-open compressed VDS format helps you further with disk space. Either of these could be read through segysak (writing would take effort) since they have segyio-like reading syntax available (pyvds for VDS). However, if you have more than half the volume as a constant value you'd win more from ZGY/VDS than seismic-zfp as the latter favours regularity in the data over identifying constant-value bricks in order to make offsets computable rather than requiring a disk location lookup for bricks.

[ksurf1]

Hi Tony, Openvds is a possibility but I don’t get requests yet. I am aware of the tools to create such files. Segy is the go to for archiving anyway. Zgy is for petrel users. Thanks for your time. How do I follow future developments ?

On Sun, May 28, 2023 at 01:35 David Wade ***@***.***> wrote: @ksurf1 <https://github.com/ksurf1> depending on your aims here, you may find converting your SEG-Y files to either the fully opensource seismic-zfp or Bluware's nearly-open compressed VDS format helps you further with disk space. Either of these could be read through segysak (writing would take *effort*) since they have segyio-like reading syntax available (pyvds for VDS). However, if you have more than half the volume as a constant value you'd win more from ZGY/VDS than seismic-zfp as the latter favours regularity in the data over identifying constant-value bricks in order to make offsets computable rather than requiring a disk location lookup for bricks. — Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZG2VEHYE7C2EQIMQROFKRTXILWZ7ANCNFSM6AAAAAAYLDB3OY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Vincent Favreau.

[ksurf1]

Hi Tony, I have a segy with a group scalar of -100 in bytes 71. This means the XYs must be divided by 100 to get a float from uint32. When I check the corners, they are all nan. I tried the defaults for cdpx cdpy, same result. I know my segy is correct and the byte positions are correct. Solution ? Python code from segysak.segy import segy_loader, well_known_byte_locs, segy_writer

fn = "path2segy.segy" ds = segy_loader(fn, iline=189, xline=193, cdpx=73, cdpy=77, offset=None)

ds.seis.calc_corner_points()

corners = tuple(ds.corner_points_xy[i] for i in [0, 3, 1, 2]) print(corners)

((nan, nan), (nan, nan), (nan, nan), (nan, nan))

…

On Sun, May 28, 2023 at 1:35 AM David Wade ***@***.***> wrote: @ksurf1 <https://github.com/ksurf1> depending on your aims here, you may find converting your SEG-Y files to either the fully opensource seismic-zfp or Bluware's nearly-open compressed VDS format helps you further with disk space. Either of these could be read through segysak (writing would take *effort*) since they have segyio-like reading syntax available (pyvds for VDS). However, if you have more than half the volume as a constant value you'd win more from ZGY/VDS than seismic-zfp as the latter favours regularity in the data over identifying constant-value bricks in order to make offsets computable rather than requiring a disk location lookup for bricks. — Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZG2VEHYE7C2EQIMQROFKRTXILWZ7ANCNFSM6AAAAAAYLDB3OY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- ---------------------------------------------------------- Vincent FAVREAU *"No one can make you feel inferior without your permission."~Eleanor Roosevelt*

[ksurf1]

The ds variable seems ok in terms of il xl dimensions but the coordinates ? Type: DatasetString form: <xarray.Dataset> Dimensions: (iline: 1234, xline: 1875, twt: 1001) Coordinates: * iline (il <...> None percentiles: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] coord_scalar: -100.0

…

On Tue, May 30, 2023 at 8:44 AM vincent favreau ***@***.***> wrote: Hi Tony, I have a segy with a group scalar of -100 in bytes 71. This means the XYs must be divided by 100 to get a float from uint32. When I check the corners, they are all nan. I tried the defaults for cdpx cdpy, same result. I know my segy is correct and the byte positions are correct. Solution ? Python code from segysak.segy import segy_loader, well_known_byte_locs, segy_writer > fn = "path2segy.segy" > ds = segy_loader(fn, iline=189, xline=193, cdpx=73, cdpy=77, offset=None) ds.seis.calc_corner_points() > corners = tuple(ds.corner_points_xy[i] for i in [0, 3, 1, 2]) > print(corners) ((nan, nan), (nan, nan), (nan, nan), (nan, nan)) On Sun, May 28, 2023 at 1:35 AM David Wade ***@***.***> wrote: > @ksurf1 <https://github.com/ksurf1> depending on your aims here, you may > find converting your SEG-Y files to either the fully opensource seismic-zfp > or Bluware's nearly-open compressed VDS format helps you further with disk > space. Either of these could be read through segysak (writing would take > *effort*) since they have segyio-like reading syntax available (pyvds > for VDS). However, if you have more than half the volume as a constant > value you'd win more from ZGY/VDS than seismic-zfp as the latter favours > regularity in the data over identifying constant-value bricks in order to > make offsets computable rather than requiring a disk location lookup for > bricks. > > — > Reply to this email directly, view it on GitHub > <#117 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AZG2VEHYE7C2EQIMQROFKRTXILWZ7ANCNFSM6AAAAAAYLDB3OY> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > -- ---------------------------------------------------------- Vincent FAVREAU *"No one can make you feel inferior without your permission."~Eleanor Roosevelt*

-- ---------------------------------------------------------- Vincent FAVREAU *"No one can make you feel inferior without your permission."~Eleanor Roosevelt*

[trhallam]

I've moved your second issue to #119 please put separate questions in separate issues.