Recent changes to bugs

#157 TRCIO fails with SEG Y format 5

seismick — Fri, 06 Dec 2024 02:28:20 -0000

status: open --> closed

TRCIO fails with SEG Y format 5

seismick — Fri, 01 Nov 2024 02:16:17 -0000

If a SEG Y file was written in format 5 (IEEE 32-bit float), then the result is garbage. SEG Y was originally big endian. However that did not stop people writing in little-endian format (as with x86 CPUs). The code in segy.f90 tries to guess the byte order and swap when needed, but this logic seems to fail with SEG Y format 5. Comments in the code have format 5 as "IEEE Landmark SEG Y". Perhaps that was big-endian. So extra if clauses migh be needed in segy.f90 or trcio.f90 to correct the issue. cbyt trace viewer also suffers from same problem with SEG Y format 5.

TRCIO fails with SEG Y format 5

seismick — Fri, 01 Nov 2024 02:16:17 -0000

Ticket 157 has been modified: TRCIO fails with SEG Y format 5
Edited By: seismick (seismick)
Status updated: 'open' => 'closed'

#156 incorrect frequencies in FXDECON

seismick — Fri, 01 Nov 2024 02:06:49 -0000

status: open --> closed

incorrect frequencies in FXDECON

seismick — Tue, 17 Sep 2024 04:34:51 -0000

The index for the specified frequency is calculated like this:
obj%ifreq1 = nint(obj%freq_begobj%nfftp2/(2nyquist))
obj%ifreq2 = nint(obj%freq_endobj%nfftp2/(2nyquist))
Now after the real to complex FFT, there are nfft/2+1 complex values. The first is the zero frequency
(constant) component, the second is the fundamental (lowest) frequency and the last is Nyquist. The
above formula would be correct at Nyquist, but incorrect for low frequencies. For example, at 2 ms, Nyquist is 250 Hz. If user specified window length of 0.5 seconds, that is padded to 0.6 seconds for the FFT, so nfft=300 and obj%nfftp2=302. If user specified FREQ_BEG=1 Hz, then above yields
nint(0.604) and thus
obj%ifreq1=1, which is the zero Hertz component. The nearest frequency bin would be 1.667 Hz, the second array index. So instead, the formula should be:
obj%ifreq1 = nint(obj%freq_begnfft/(2nyquist))+1

The same code also appears in FXDENOIS and FXINTERP, so they would have to be modified too.

incorrect frequencies in FXDECON

seismick — Tue, 17 Sep 2024 04:34:51 -0000

Ticket 156 has been modified: incorrect frequencies in FXDECON
Edited By: seismick (seismick)
Status updated: 'open' => 'closed'

#155 AVOPCOMP SIGSEGV

seismick — Fri, 05 Jul 2024 12:07:32 -0000

status: open --> closed

AVOPCOMP SIGSEGV

seismick — Thu, 04 Jul 2024 01:10:38 -0000

AVOPCOMP works when only the eight-trace standard suite is input. But when velocity trace and seismic traces are added, it aborts with SIGSEGV on first gather. Found that the problem is that variable v_ptr was not initialised. It is used as array index, and so some large random number results in attempt to access invalid memory. The velocity trace is supposed to be the ninth trace in the input gather, and setting v_ptr to the index of the actual velocity trace fixes the problem.

AVOPCOMP SIGSEGV

seismick — Thu, 04 Jul 2024 01:10:38 -0000

Ticket 155 has been modified: AVOPCOMP SIGSEGV
Edited By: seismick (seismick)
Status updated: 'open' => 'closed'

#152 undefined variable in ppavo.f90

seismick — Tue, 02 Jul 2024 03:04:44 -0000

status: open --> closed