|
|
| sdurl |
| |
|
| sdapikey |
| |
|
| sdtoken |
| |
|
| maxsize |
| |
|
| maxhole |
| |
|
| aligned |
| |
|
| segsize |
| |
|
| threads |
| |
|
| legaltag |
| |
|
| writeid |
| |
|
| seismicmeta |
| |
◆ __init__()
| def openzgy.impl.file.SDConfig.__init__ |
( |
|
self, |
|
|
|
context |
|
) |
| |
Process an iocontext for seismic store, doing consistency checks
and applying fallbacks from environment variables and hard coded
defaults.
The context itself should be a dict or equivalent. The code also
supports the older style using a class instance with attributes.
That feature is deprecated and will be removed. It violates the
principle of least surprise.
A fully specified iocontext has the following attributes:
sdurl: string
Where to contact the seismic store service.
Defaults to $OPENZGY_SDURL.
sdapikey: string
Authorization for application to access the seismic store API.
Defaults to $OPENZGY_SDAPIKEY.
sdtoken: string
User credentials. Set to $OPENZGY_TOKEN if not found,
beware that this might not be secure. The code will no longer
use the token last saved by sdcfg as a fallback. If this is
desired you must specify "FILE:carbon.slbapp.com" as the token.
Caveat: The sdcfg token is not refreshed so it might time out
after an hour. Run "sdutil auth idtoken > /dev/null" to refresh.
maxsize: int specified in MB between 0 and 1024.
Zero is taken to mean do not consolidate.
Tell the reader to try to consolidate neighboring bricks
when reading from seismic store. This is usually possible
when the application requests full traces or at least traces
traces longer then 64 samples. Setting maxsize limits this
consolidation to the specified size. The assumption is that
for really large blocks the per-block overhead becomes
insignificant compared to the transfer time.
Consolidating requests has higher priority than using
multiple threads. So, capping maxsize might allow more
data to be read in parallel.
Note that currently the spitting isn't really smart. With a
64 MB limit and 65 contiguous 1 MB buffers it might end up
reading 64+1 MB instead of e.g. 32+33 MB.
Note that the low level reader should not assume that
requests are capped at this size. They might be larger
e.g. when reading the header information.
Defaults to $OPENZGY_MAXSIZE_MB if not specified, or 2 MB.
maxhole: int specified in MB between 0 and 1024.
This applies when consolidate neighboring bricks when
reading from seismic store. Setting maxhole > 0 tells the
reader that it is ok to also consolidate requests that are
almost neighbors, with a gap up to and including maxhole.
The data read from the gap will be discarded unless picked
up by some (not yet implemented) cache.
For cloud access with high bandwidth (cloud-to-cloud) this
should be at least 2 MB because smaller blocks will take
just as long to read. For low bandwidth cloud access
(cloud-to-on-prem) it should be less. If a fancy cache
is implemented it should be more. For accessing on-prem
ZGY files it probably makes no difference.
Defaults to $OPENZGY_MAXHOLE_MB if not specified, or 2 MB.
aligned: int in MB between 0 and 1024.
This is similar to the maxhole parameter. If set, starting
and ending offsets are extended so they both align to the
specified value. Set this parameter if the lower levels
implement a cache with a fixed blocksize and when there is
an assumpton that most reads will be aligned anyway.
TODO-Worry: Handling reads past EOF may become a challenge
for the implementation.
Defaults to $OPENZGY_ALIGNED_MB if not specified, or zero.
segsize: int in MB between 0 and 16*1024 (i.e. 16 GB).
Defaults to $OPENZGY_SEGSIZE_MB if not specified, or 1 GB.
threads: int between 1 and 1024.
Use up to this many parallel requests to seismic store
in order to speed up processing. This applies to individual
reads in the main API. So the reads must be for a large
area (i.e. covering many bricks) for the setting to be
of any use. Set to $OPENZGY_NUMTHREADS if not found,
and 1 (i.e. no threading) if the environment setting is
also missing.
Whether it is useful to set the variable depende on the
application. Apps such as Petrel/BASE generally do their
own multi threading, issuing multiple read requests to
the high level API in parallel. In that case it might
not be useful to also parallelize individual requests.
legaltag: string, possibly empty.
The legaltag stored in the file. Used only on create.
writeid:
I don't know what this is for. Ask the seismic store team.
seismicmeta:
a dictionary of additional information to be associated
with this dataset in the data ecosystem. Currently used
only on create, although SDAPI allows this to be set on
an existing file by calling {get,set}SeismicMeta().
When set via an environment variable (strictly for testing)
this needs to be the string representation of the json data.
When set from a program a Python dict is expected.
_debug_trace:
For debugging and unit tests only.
Callback to be invoked immediately before a read or write
is passed on to seismic store. Typically used to verify
that consolidating bricks works as expected. Can only be
set programmatically. Not by an environment variable.
◆ extra()
| def openzgy.impl.file.SDConfig.extra |
( |
|
self | ) |
|
Legaltag, writeid, and seismicmeta are usually packed
into a single "extra" dictionary when creating a new file.
If any of them are unset they will be excluded from the
dictionary instead of being passed as some default value.
CAVEAT: The keys in the "extra" dictionary are not
supposed to be hard coded as I do here. They are defined in
seismic-store-client-api-cpp/src/src/core/Constants.{cc,h}.
Cannot access that file here.
NOTE: Python dicts have an undefined sort order, as does
json. To simplify testing I sort the keys in the "extra" dict.
If SDAPI for some reason should require a specific ordering
then "seismicmeta" needs to be passed as a string.
The documentation for this class was generated from the following file:
