Seitosh issueshttps://git.scc.kit.edu/Seitosh/Seitosh/-/issues2021-11-09T11:14:48+01:00https://git.scc.kit.edu/Seitosh/Seitosh/-/issues/27stuploxx: origin of time scale shall be adjusted dynamically in interactive mode2021-11-09T11:14:48+01:00we7765stuploxx: origin of time scale shall be adjusted dynamically in interactive modeBehavior in interative mode:
reload (r): data is regenerated and reloaded. The displayed time window remains unchanged, the new data may (partially or completely) lie outside the displayed time window. This behavior appears reasonable.
...Behavior in interative mode:
reload (r): data is regenerated and reloaded. The displayed time window remains unchanged, the new data may (partially or completely) lie outside the displayed time window. This behavior appears reasonable.
timewindow init (t-i): The displayed time window is adapted to the available data. Now all the data that have been read in are shown in the time window. The timescale is correct.
The problem reported here relates to the origin of the time axis from which the counting starts (midnight on a specified date). This origin remains unchanged with a reload or t-i. If a seismogram window in interactive mode remains open for several days, time is counted from an origin far in the past. That makes the timescale difficult to read.
Whether this is a feature or a bug can be discussed. In practice we rarely use persistent interactive windows. Whether the main goal of interactive windows is to stay open for days can also be discussed.
However, it is also a fact that windows in auto-refresh mode dynamically adjust their time origin. So: it works (just needs to be implemented).we7765we7765https://git.scc.kit.edu/Seitosh/Seitosh/-/issues/24libdatrwxx: MiniSEED format specification2017-11-14T20:47:13+01:00we7765libdatrwxx: MiniSEED format specificationGive a proper account of MiniSEED format specifications, which the library relies on. Tell which exceptions are known and which exceptions are handled by the library.
Possibly rework the reading module, such that becomes flexible and ...Give a proper account of MiniSEED format specifications, which the library relies on. Tell which exceptions are known and which exceptions are handled by the library.
Possibly rework the reading module, such that becomes flexible and conforms to the format definition more closely. Consider the read full binary records from the files and to present them to different decoding units.
II-data for the iSTS1 is written in
encoding format: IEEE double precision floating point (5)
Consider to implement this.we7765we7765https://git.scc.kit.edu/Seitosh/Seitosh/-/issues/15stuploxx: plot panel margin2017-11-14T20:47:14+01:00we7765stuploxx: plot panel marginThe per-file option sf: should adjust a panel margin relative to the actual value range used in the panel. This currently is not the case, since margins are calculated from signal values.The per-file option sf: should adjust a panel margin relative to the actual value range used in the panel. This currently is not the case, since margins are calculated from signal values.we7765we7765https://git.scc.kit.edu/Seitosh/Seitosh/-/issues/8libdatrwxx: handle full SeismicUnix headers2017-11-14T20:47:14+01:00we7765libdatrwxx: handle full SeismicUnix headersThis refers to tickets [#81](http://gpitrsvn.gpi.uni-karlsruhe.de:8000/TFSoftware/ticket/81) and [#82](http://gpitrsvn.gpi.uni-karlsruhe.de:8000/TFSoftware/ticket/82) in TFSoftware:
libdatrwxx looses the rich content of SeismicUnix he...This refers to tickets [#81](http://gpitrsvn.gpi.uni-karlsruhe.de:8000/TFSoftware/ticket/81) and [#82](http://gpitrsvn.gpi.uni-karlsruhe.de:8000/TFSoftware/ticket/82) in TFSoftware:
libdatrwxx looses the rich content of SeismicUnix headers upon reading data files. By passing the contents in the trace FREE block in well formatted character strings they could be made available to the SeismicUnix writing functions and thus could appropriately be restored in the output file. SeismicUnix input/output is provided in source code found at [src/libs/libdatrwxx/su](src/libs/libdatrwxx/su). The SU module in libdatrwxx currently does neither produce trace free blocks of type sff::FREE (in function void isustream::readheader()) not does it write such blocks (in function void osustream::writetrace(const Tfseries::Tcoc& series)). Appropriate evaluation of Seismic Unix trace header fields and conversion to and from sff::FREE containers should be implemented as member function of datrw::su::SUheader in [src/libs/libdatrwxx/su/suheader.cc](src/libs/libdatrwxx/su/suheader.cc).
Niklas, if you plan to work on this, a discussion of implementation strategy and data containers provided and used in libdatrwxx might be helpful or even necessary.
A remark taken from TFSoftware ticket [#81](http://gpitrsvn.gpi.uni-karlsruhe.de:8000/TFSoftware/ticket/81):
Since the different header fields are of different variable type, the functions behind suascii are quite elaborate. Although they are straight forward, it would require an additional amount of code to implement this functionality. Its usefulness within the framework of libdatrwxx is questionable.
See
SU41/src/su/main/suascii.c
and
SU41/src/su/lib/hdrpkge.c
as well as
SU41/src/su/include/hdr.h
SU41/src/su/include/Makefile
SU41/src/su/include/mkhdr.c
SU41/src/su/include/mkprehdr.sh
SU41/src/su/include/offsets.h
and others.niklas.thielniklas.thiel