Dear developers,

I have noticed that scdb is not able to import events that contain nan values. That might be the expected behaviour and I am fine with that, but I wanted to report this particular case just to be sure is not a bug.

What happened is that I processed some data in playback (scautopick, scanloc, screloc, scevent) using the --ep option. Due to a misconfiguration of NonLinLoc, its XML output was lacking the lat/lon/depth uncertainty. An example of the output follows:

<latitude>
  <value>46.51048231</value>
  <uncertainty>-nan</uncertainty>
</latitude>
<longitude>
  <value>8.476244074</value>
  <uncertainty>-nan</uncertainty>
</longitude>
<depth>
  <value>-1.4119125</value>
  <uncertainty>-nan</uncertainty>
</depth>

I initially didn't notice the nan values and I imported the output with scdb, but I couldn't see the events in the database, only the picks. Then I realized the problem with nans.

I wonder what is the most suitable behaviour that SeisComP should have. Should the nan not being exported in the first place? Should the nan be read and imported in the db? Is the current behaviour already fine? What do you think?

thanks
Luca

just a minor thing, but the tag 5.5.3 was created on a separate branch than v5:

I have found an issue on the master branch that doesn't happen on branch v5. Due to the recent changes on master (Add support to extend configuration structs with plugins) I thought this might be related and I am reporting it.

The xml configuration that crashes scconfig can be found here.

The crash is related to this line and it looks like in my case it->second is null. If I add a check on it being null everything works fine, but I don't have the visibility to understand neither the full problem nor the correct bug fix.

Here are the details:

I am working on two projects where we have several boreholes with multiple sensors per borehole. In this scenario, when I use the PickerView or the AmplitudeView the "sorting by distance" feature doesn't work well because the GUIs consider only the epicenter distance instead of the hypocenter distance and the events are so close to the sensors that the difference in their elevation matters.

I was considering providing a PR to fix this, but after reviewing the code of PickerView and AmplitudeView I have the feeling that they were never meant to be used for such local processing where the hypocenter vs epicenter distance is relevant.

Do you think it would make sense to fix this use case?

Hi devs,
on one hand the documentation of the initialization configuration methods i.e.

• Which Application::init() method the documentation is referring to?

Perhaps this is a little bit petty. Anyway, I think the documentation could be clearer. What's your opinion on that?

The theoretical arrivals on the picker and amplitude GUIs are not properly computed when an origin has a negative depth. This is because the negative depth is set to +1km when calling the travel time table implementations . See here and here.

While I understand the "safety belt" intentions behind this choice, it would be much better to add the depth check in the travel time table implementation themselves. That would allow other TTT implementations that handle negative depths to work properly.

What do you think?

Thanks,
Luca

I am working in playback with some data that contains gaps. scautopick worked fine until I enabled "AIC". With "AIC" as picker scautopick stops processing the stream after the first gap is found.

Here is the results of running scautopick on streams 56G1 and 56G2 when "AIC" is NOT used.

And here with "AIC".

I am running scautipick with gapInterpolation enabled and maxGapLength 4.5 sec

Hi,

I tried to compile the latest commits of SeisComP4 on macOS 10.14.6.

It worked pretty well until it failed to compile setInterval() for the new messaging service in master/apps/messaging/scmaster/timer.cpp.
https://github.com/SeisComP/common/blob/master/apps/messaging/scmaster/timer.cpp

On macOS there is no itimerspec structure (or the POSIX timer functions (timer_*())
(and no timerfd_create() and timerfd_settime()) since it's Linux / glibc specific (I thinj),
and neither Homebrew or macports can install glibc 2.31.

Maybe I could rewrite setInterval with clock_gettime, since macOS 10.12 now supports clock_gettime()
https://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x

Do you think that clock_gettime() could be used to create a setInterval() function ?

Any suggestions is greatly appreciated.

Here's the compilation output:

        struct itimerspec newValue;
                          ^
/Users/gilles/Development/seiscomp4-git/seiscomp4-macos/src/base/common/apps/messaging/scmaster/timer.cpp:60:9: note: forward declaration of 'itimerspec'
        struct itimerspec newValue;
               ^
/Users/gilles/Development/seiscomp4-git/seiscomp4-macos/src/base/common/apps/messaging/scmaster/timer.cpp:64:41: error: use of undeclared identifier 'TFD_NONBLOCK'
                _fd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);

Dear developers,

I would like to suggest a couple of changes to the TravelTimeTableInterface and hear your opinions on that.

1 - add a TravelTimeTableInterface::computeTravelTime method that returns only the travel time without additional information (no TravelTime is returned). This is because the travel time is the most requested information from the TravelTimeTableInterface throughout seiscomp and this change would allow to improve the overall performance, since returning only the travel time can potentially be less expensive than returning all the fields of the TravelTime class.

2 - add a field azimuth to the TravelTime class. This is to allow 3D velocity models in the future. In a 3D velocity model the azimuth of the take off angle is calculated by the travel time table, because the ray horizontal path can be reflected/refracted/bent the same way it happens with the vertical ray path on a 1D model. This change would make the existing 1D models return the azimuth computed by e.g. delazi.

What are your thoughts on this?

thanks,
Luca

Dear developers,

I was not able to compute magnitude in scolv for certain events and after some investigation I found out that there is a 0.5 pick weight threshold below which the picks are silently ignored. I have now fixed the issue on my side, so I do not need support.

I just wanted to suggest to make the threshold configurable and also to log the discarded picks so that careful users have a chance to find out what the GUIs are doing.

thanks
Luca

Dear Developers,

I have just updated seiscomp to version 4.1.1 from 4.0.3 and when I restarted the system scautopick crashes with the message "High frequency cutoff must be lower than Nyquist frequency" (below more details from gdb).

There are two possibilities:

• the configuration is not good but seiscomp didn't previously check that, while in version 4.1.1 it does so
• or a bug in a recent change? Unlikely but I was thinking at 7d8cca6 and 3b73a25

Would it be possible to catch the exception in scautopick and give more debugging information? E.g. what station, what configuration parameter and whether the error is in the bindings or in the plain configuration?

Thank you very much

Luca

# gdb --args scautopick --debug
[...]
17:52:58 [debug] Added processor on stream ON.SKEGG.00.HHZ    addr=0x7f0dd0
17:52:58 [debug] Current processor count: 12/12, object count: 4078
17:52:58 [debug] ON.SVIN.00.HHZ: created detector
17:52:58 [debug] Added processor on stream ON.SVIN.00.HHZ    addr=0x7f1d70
17:52:58 [debug] Current processor count: 13/13, object count: 4099
17:52:58 [debug] SI.BJA.00.HHZ: sensor gain frequency does not match overall gain frequency: 5.000000 != 1.000000
17:52:58 [debug] SI.BJA.00.HHZ: correct gain by factor 1.001819: 400000000.000000 -> 400727627.070111
17:52:58 [debug] SI.BJA.00.HHZ: created detector
17:52:58 [debug] Added processor on stream SI.BJA.00.HHZ    addr=0x7f2e00
17:52:58 [debug] Current processor count: 14/14, object count: 4120
terminate called after throwing an instance of 'std::runtime_error'
  what():  High frequency cutoff must be lower than Nyquist frequency

Thread 1 "scautopick" received signal SIGABRT, Aborted.
0x00007ffff5968438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5968438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff596a03a in __GI_abort () at abort.c:89
#2  0x00007ffff62ab84d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff62a96b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff62a9701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff62a9919 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff72f1ca4 in Seiscomp::Math::Filtering::IIR::(anonymous namespace)::init_bw_biquads_inplace(std::vector<Seiscomp::Math::Filtering::IIR::BiquadCoefficients, std::allocator<Seiscomp::Math::Filtering::IIR::BiquadCoefficients> >&, unsigned long, double, double, double, int) () from /home/sysop/seiscomp/lib/libseiscomp_core.so.14
#7  0x00007ffff72f3b21 in Seiscomp::Math::Filtering::IIR::ButterworthBandpass<double>::setSamplingFrequency(double) () from /home/sysop/seiscomp/lib/libseiscomp_core.so.14
#8  0x00007ffff72fd713 in Seiscomp::Math::Filtering::ChainFilter<double>::setSamplingFrequency(double) () from /home/sysop/seiscomp/lib/libseiscomp_core.so.14
#9  0x00007ffff72fd713 in Seiscomp::Math::Filtering::ChainFilter<double>::setSamplingFrequency(double) () from /home/sysop/seiscomp/lib/libseiscomp_core.so.14
#10 0x00007ffff7b5e615 in Seiscomp::Processing::WaveformProcessor::store(Seiscomp::Record const*) () from /home/sysop/seiscomp/lib/libseiscomp_client.so.14
#11 0x00007ffff7b5dc58 in Seiscomp::Processing::WaveformProcessor::feed(Seiscomp::Record const*) () from /home/sysop/seiscomp/lib/libseiscomp_client.so.14
#12 0x00007ffff7b635e4 in Seiscomp::Processing::Application::handleRecord(Seiscomp::Record*) () from /home/sysop/seiscomp/lib/libseiscomp_client.so.14
#13 0x00007ffff7b221fc in Seiscomp::Client::StreamApplication::dispatch(Seiscomp::Core::BaseObject*) () from /home/sysop/seiscomp/lib/libseiscomp_client.so.14
#14 0x00007ffff7b10e90 in Seiscomp::Client::Application::processEvent() () from /home/sysop/seiscomp/lib/libseiscomp_client.so.14
#15 0x00007ffff7b11391 in Seiscomp::Client::Application::run() () from /home/sysop/seiscomp/lib/libseiscomp_client.so.14
#16 0x0000000000426424 in Seiscomp::Applications::Picker::App::run() ()
#17 0x00007ffff6f1a10a in Seiscomp::System::Application::exec() () from /home/sysop/seiscomp/lib/libseiscomp_core.so.14
#18 0x000000000041f480 in main ()

clang & gcc fails to compile SeisComP v6:
Error at line 352 & 366 of common/libs/seiscomp/utils/timer.cpp

Line 352 & line 366 still contains boost::mutex
boost::mutex::scoped_lock lk(_mutex);

This works for me when replacing with:
std::lock_guard<std::mutex> lk(_mutex);

As reported by a user in the forum the conversion between SC3ML to QuakeML and vice versa is using the wrong units for the confidenceEllipsoid. The conversion schemas (1, 2 and 3) assume seiscomp confidenceEllipsoid units are kilometer, but they are meters.

I have been testing my code with Valgrind and I found this issue, so I am reporting it in case you might want to fix that.

==2777831== Conditional jump or move depends on uninitialised value(s)
==2777831==    at 0x484C4EC: assertion_result (output.cpp:117)
==2777831==    by 0x484C4EC: Seiscomp::Unittest::OutputObserver::assertion_result(boost::unit_test::assertion_result) (output.cpp:106)
==2777831==    by 0x161553: boost::unit_test::framework::assertion_result(boost::unit_test::assertion_result) (framework.ipp:1741)
==2777831==    by 0x19B7FA: boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...) [clone .constprop.0] (test_tools.ipp:370)
==2777831==    by 0x1AA699: check_frwd<boost::test_tools::check_is_close_t, double, double, boost::math::fpc::percent_tolerance_t<int> > (impl.hpp:92)
==2777831==    by 0x1AA699: (anonymous namespace)::testCatalogEqual(boost::intrusive_ptr<Seiscomp::HDD::Catalog const>, boost::intrusive_ptr<Seiscomp::HDD::Catalog const>) (dd.cpp:341)
==2777831==    by 0x1B9E55: void test_dd_single_eventcase::_impl<unsigned long>(unsigned long const&) (dd.cpp:447)
==2777831==    by 0x1BB4F5: void test_dd_single_eventcase::test_method<unsigned long const&>(unsigned long const& const&) (dd.cpp:420)
==2777831==    by 0x199F91: operator() (function_template.hpp:763)
==2777831==    by 0x199F91: operator() (execution_monitor.ipp:1368)
==2777831==    by 0x199F91: boost::detail::function::function_obj_invoker0<boost::detail::forward, int>::invoke(boost::detail::function::function_buffer&) (function_template.hpp:137)
==2777831==    by 0x16E574: operator() (function_template.hpp:763)
==2777831==    by 0x16E574: do_invoke<boost::shared_ptr<boost::detail::translator_holder_base>, boost::function<int()> > (execution_monitor.ipp:290)
==2777831==    by 0x16E574: boost::execution_monitor::catch_signals(boost::function<int ()> const&) (execution_monitor.ipp:879)
==2777831==    by 0x16E60A: boost::execution_monitor::execute(boost::function<int ()> const&) (execution_monitor.ipp:1277)
==2777831==    by 0x16E6FD: boost::execution_monitor::vexecute(boost::function<void ()> const&) (execution_monitor.ipp:1377)
==2777831==    by 0x173FAE: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::function<void ()> const&, unsigned long) (unit_test_monitor.ipp:49)
==2777831==    by 0x1A7291: boost::unit_test::framework::state::execute_test_tree(unsigned long, unsigned long, boost::unit_test::framework::state::random_generator_helper const*) (framework.ipp:823)


==2777831==  Uninitialised value was created by a heap allocation
==2777831==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2777831==    by 0x186174: boost::unit_test::ut_detail::global_configuration_impl<Seiscomp::Unittest::Output>::test_start(unsigned long) (global_fixture.hpp:91)
==2777831==    by 0x199F91: operator() (function_template.hpp:763)
==2777831==    by 0x199F91: operator() (execution_monitor.ipp:1368)
==2777831==    by 0x199F91: boost::detail::function::function_obj_invoker0<boost::detail::forward, int>::invoke(boost::detail::function::function_buffer&) (function_template.hpp:137)
==2777831==    by 0x16E574: operator() (function_template.hpp:763)
==2777831==    by 0x16E574: do_invoke<boost::shared_ptr<boost::detail::translator_holder_base>, boost::function<int()> > (execution_monitor.ipp:290)
==2777831==    by 0x16E574: boost::execution_monitor::catch_signals(boost::function<int ()> const&) (execution_monitor.ipp:879)
==2777831==    by 0x16E60A: boost::execution_monitor::execute(boost::function<int ()> const&) (execution_monitor.ipp:1277)
==2777831==    by 0x16E6FD: boost::execution_monitor::vexecute(boost::function<void ()> const&) (execution_monitor.ipp:1377)
==2777831==    by 0x173FAE: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::function<void ()> const&, unsigned long) (unit_test_monitor.ipp:49)
==2777831==    by 0x179231: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:1644)
==2777831==    by 0x183E99: boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**) (unit_test_main.ipp:248)
==2777831==    by 0x5D4D0B2: (below main) (libc-start.c:308)
==2777831== 

Dear developers,

I have been thinking at this check here and I do not believe it is a good idea to hide problems. I would rather prefer the travel time table to throw an exception and let the caller decide what it is the best way to handle it. Trying to cope with a bad input is usually not the best approach for an api. It is normally better to communicate the error and let the caller address the issue in the most appropriate way since it is the caller that knows better.

What do you think?

Luca

Hi devs,

I noted that properties such as e.g. the pick's filterID are prefixed with the resource identifier when the output is exported to QuakeML. The properties are not prefixed when exporting to Trunk (i.e. SeisComP ML). Is this behaviour desired? If yes, why?

Note that once filter identifiers are prefixed, they cannot be used straight away with SeisComP's filter factory facility. That is, the prefix needs to be removed again before creating a filter , since otherwise the filter identifier is invalid in the context of the SeisComP filter grammar.

Dear developers,

I believe there is a bug in here. It looks like that only the hypycentral depth is considered when computing the vertical distance between source and receiver, but not the station elevation.

Luca

Dear developers,

this is a proposal that requires some work on your side, so if there is no interest please feel free to close the issue.

I wrote some code that reads NonLinLoc grid files and I use them as travel time tables. I initially wanted to register the code as a plugin that implements the TravelTimeTableInterface, which would allow to use the grids with any module, especially scolv. This is interesting because that would enable 3D velocity models in SeisComP. Unfortunately that is not possible because the current interface is not suitable for NonLinLoc grids (or the grids are not suitable for SeisComP):

• the current interface computes travel times between any two locations while NonLinLoc grids work between any point and a specific station
• NonLinLoc computes only P and S and not all the phase types available with Locsat and libtau

In case you are interested in following up the idea please let me know.

Hi, the full database string including password is logged when the -d or --database flag is used. There are various places in the following function this can occur:

https://github.com/SeisComP/common/blob/master/libs/seiscomp/client/application.cpp#L1823.

It would probably be better to obfuscate the password like is done in other places.

Hello,
When compiling on macOS including the recent commits (16-17 August 2020), I get the following compilation error. Could this be related to the recent changes? Compiling prior to integrating these changes with commits up to 14 August 2020 included works just fine.

Many thanks for giving a look!

Undefined symbols for architecture x86_64:
"Seiscomp::Math::Filtering::IIR::ButterworthBandpass::ButterworthBandpass(int, double, double, double)", referenced from:
Seiscomp::Processing::BKPicker::calculatePick(int, double const*, int, int, int&, int&, int&, double&, boost::optionalSeiscomp::Processing::Picker::Polarity&) in bk.cpp.o
Seiscomp::Processing::GFZPicker::calculatePick(int, double const*, int, int, int&, int&, int&, double&, boost::optionalSeiscomp::Processing::Picker::Polarity&) in gfz.cpp.o
"Seiscomp::Math::Filtering::IIR::ButterworthHighpass::ButterworthHighpass(int, double, double)", referenced from:
Seiscomp::Processing::AmplitudeProcessor_Mwp::computeAmplitude(Seiscomp::NumericArray const&, unsigned long, unsigned long, unsigned long, unsigned long, double, Seiscomp::Processing::AmplitudeProcessor::AmplitudeIndex*, Seiscomp::Processing::AmplitudeProcessor::AmplitudeValue*, double*, double*) in Mwp.cpp.o
Seiscomp::Processing::QcProcessorSpike::_setFilter(double) in qcprocessor_spike.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libseiscomp_client.14.1.0.dylib] Error 1
make[1]: *** [src/base/common/libs/seiscomp/CMakeFiles/seiscomp_client.dir/all] Error 2

I stumbled across this code and I was wondering why the PublicObjectCache::find looks for the object in the list of registered objects and not in the cache itself. It feels inconsistent with the rest of the PublicObjectCache API.

Also, I was wondering what is the design behind the "registered objects". What is the purpose of having registered objects?

Thank your for your help.

Luca

Hi devs,

while implementing unittests for a concrete implementation of Seiscomp::Client::StreamApplication I run into the issue that the inventory_ member of the Seiscomp::Client::Inventory singleton instance i.e.

void MyApplication::done() {
   ...
   Seiscomp::Client::Inventory::Instance()->setInventory(nullptr);
}

which would do the job. However, IMO it would be cleaner to add this line to

What do you think?

EDIT: Correct namespace

Core::toString() has fixed precision of 10, which means that, eg., double loses precision when serialized as XML. We cannot be sure that 10 digits precision is sufficient for all use cases.

Suggest using ostream.precision(std::numeric_limits<T>::max_digits10)

See: https://en.cppreference.com/w/cpp/types/numeric_limits/max_digits10

This is just a question. I had a look at the code in here and I noticed that SAC is not supported, although the actual SacRecord implementation exists. This is just a curiosity, but also I would like to understand if there are limitations to be aware of, since I need to implement my own Record format.

Thanks.

Hi devs,

there is the following constructor which allows creating a GenericRecord from a Record

I noticed an inconsistency of the RecordStream::addStream method across different implementations.

It seems to me that SDSArchive and File recordstreams allow only one time window (startTime, endTime) per stream (net.sta.loc.cha) to be requested. More precisely, whenever a second call to addStream happens on the same stream (net.sta.loc.cha), that call erases the previous time window (startTime, endTime) requested.

Looking at the code the behaviour seems to be wanted like that and not a bug. Can you confirm that?

However I feel that is a big inconsistency compared to other RecordStream implementations, because it invalidates the portability of the code across different RecordStreams.

thanks.

• tremor pulse type enumeration misses the "r"
  

  common/libs/xml/0.12/sc3ml_0.12.xsd

  Line 160 in 8b0e478

  <xs:enumeration value="temor pulse"/>

cheers
jerome

Hi,

I stumpled over the issue that a buffered record might be fed twice when registering an instance of processing::TimeWindowProcessor in

Particularly, it is the last buffered record which is the one fed twice iff the instance of processing::TimeWindowProcessor did not finish during registration, already. The record is fed a second time here

Have you been aware of this issue? Is this by design?

I'm aware the record's fed twice are usually dropped with

What do you think about performing the check client-side for processing::TimeWindowProcessors? I.e. by means of e.g. adding

if ( it->second->lastRecord() == rec ) continue;

before

Compiling with clang (and g++-13.2) (with C++11 or C++14) the following error is displayed in common/libs/seiscomp/messaging/database/websocket_private.h for class:

class WebsocketProxy : public Seiscomp::IO::DatabaseInterface, virtual Seiscomp::Core::InterruptibleObject {

clang error:

class WebsocketProxy InterruptibleObject implicitly declared private in 
/src/base/common/libs/seiscomp/messaging/database/websocket_private.h:37:24: note: implicitly declared private here
                       virtual Seiscomp::Core::InterruptibleObject {
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I fixed it by appending public to virtual like this:

class WebsocketProxy : public Seiscomp::IO::DatabaseInterface,
                       virtual public Seiscomp::Core::InterruptibleObject {

But I'm not 100% sure if this is correct....

In common/libs/seiscomp/gui/map/projections/mercator.cpp at line 23, it should be:

#include <seiscomp/gui/map/texturecache.ipp>
instead of
#include <seiscomp3/gui/map/texturecache.ipp>

then it compiles fine (at least on macOS)

Hi devs,

is there a clean way for concrete implementations of Seiscomp::System::Application to guarantee that certain plugins are always loaded when being run? If I understand the Seiscomp::System::PluginRegistry API correctly facilities for forced plugin loading are currently not provided.

Though, there is a hacky workaround i.e. to modify both _configuration and _baseSettings members in an overloaded version of Seiscomp::System::Application::initPlugins(). Can you think of a cleaner approach of implementing this feature?

Thanks.

Daniel

As per title, I have just noticed that there is a small bug in the computation of phase residuals. I will take care of providing a PR, but I am going on holiday so I am creating this PR for future reference and to let you know there is a bug.

The residuals in 'GridSearch+LeastSquares' are computed by computeProbDensity based on the values of cellTravelTimes. cellTravelTimes should be updated by the call to locateLeastSquares, but they are not. This is the bug.

Dear developers,

I have been working on a couple of projects where they need a locator for very local seismicity (few kms and few hundreds of meters). In this scenario I cannot use the default SeisComP locators because they do not take into consideration station elevations, negative source depths and neither their travel time table models do.

We also use borehole sensors , which means the locator has to take into consideration that the earthquakes can happen also above the sensors. Basically many assumptions valid for regional seismicity break at this small scales.

The only locator that works pretty well is NonLinLoc, but to achieve a good location resolution the number of iterations for the Octtree method has to be set so high that it doesn't fit well for real-time applications, especially if you intend to use NonLinLoc within scanloc.

So I wrote this simple locator , which is the perfect complement to the homogeneous travel time table.

I wonder if you are interested in merging this code into SeisComP, since I don't get anything from keeping it in a separate repository. In case you are interested, just let me know and I will provide a PR where we can discuss improvements and changes required for the integration.

best
Luca

Hi devs,

a question regarding

As a client of this API and according to the documentation I'd expect that the returned value is always >= 0. Though, the implementation is different, see:

I.e. the comparison is performed based on absolute values, however the returned value may still be negative.

Is this on purpose?

Dear developer,

it seems that the recent changes to mseedrecord.cpp caused an infinite loop while reading certain miniseed files. I found the bug while reading from an SDS archive. From the logs I can see the following:

[error/SDS] exc: -1, Fatal error occured during reading record from stream
[error/SDS] exc: -1, Retrieving the record length failed
[error/SDS] exc: -1, Retrieving the record length failed
[error/SDS] exc: -1, Retrieving the record length failed
[error/SDS] exc: -1, Retrieving the record length failed
[error/SDS] exc: -1, Retrieving the record length failed
[...same error forever...]

From the debugger I can see the issue is caused by a combination of MSeedRecord::read() and the SDSArchive::next():

• MSeedRecord::read() throws LibmseedException("Retrieving the record length failed")
• then SDSArchive::next() catches it and tries to read the stream again
• ... but it will throws again with the same error as before...
• ...the exception will be catched again
• ... and the stream tried to be read again
• ....and that continues forever

MSeedRecord::read() fails repeatedly because the input stream, which is passed in input, is in an invalid state and never updated. The stream status is checked at the begin of the method. The check fails every time, the method throws, but the stream is left unchanged. That leads to the infinite loop.

Hope this helps

Hello

We are using v5.4.0 and none of the button or menu to Maximise visible amplitude or its shortcut (s) work to rescale the seismogram in the selected station picker window (it does still work in the mutli-station waveform section subplot).

Is this already fixed in newer versions maybe?

Cheers

Fred

Hi,

I had been running master branch (quite well!) on python3.11 but after a recent refresh now getting this error when trying to run scolv

$ seiscomp exec scolv
terminate called after throwing an instance of 'Seiscomp::Core::DuplicateClassname'
  what():  CharArray
Aborted (core dumped)

the scolv splash screen shows up momentarily before crashing. below is the backtrace

$ gdb scolv

Reading symbols from scolv...
(No debugging symbols found in scolv)
(gdb) r
Starting program: /data/seiscomp/bin/scolv 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x15554d78d700 (LWP 67831)]
[New Thread 0x15554ce6d700 (LWP 67832)]
terminate called after throwing an instance of 'Seiscomp::Core::DuplicateClassname'
  what():  CharArray

Thread 1 "scolv" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00001555515cd859 in __GI_abort () at abort.c:79
#2  0x0000155551856911 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x000015555186238c in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x0000155551861369 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x0000155551861d21 in __gxx_personality_v0 () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00001555517adbef in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#7  0x00001555517ae281 in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#8  0x000015555186269c in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00001555527875fe in Seiscomp::Core::Generic::ClassFactoryInterface<Seiscomp::Core::BaseObject>::RegisterFactory(Seiscomp::Core::Generic::ClassFactoryInterface<Seiscomp::Core::BaseObject>*, bool) ()
   from /data/seiscomp/lib/libseiscomp_core.so.16
#10 0x0000155552786f69 in Seiscomp::Core::Generic::ClassFactoryInterface<Seiscomp::Core::BaseObject>::ClassFactoryInterface(Seiscomp::Core::RTTI const*, bool) () from /data/seiscomp/lib/libseiscomp_core.so.16
#11 0x000015555274e1b2 in Seiscomp::Core::Generic::ClassFactory<Seiscomp::Core::BaseObject, Seiscomp::NumericArray<char> >::ClassFactory(char const*, bool) () from /data/seiscomp/lib/libseiscomp_core.so.16
#12 0x0000155527f9e75e in __static_initialization_and_destruction_0(int, int) () from /data/seiscomp/lib/libseiscomp_core.so.15
#13 0x0000155527f9ea4c in _GLOBAL__sub_I_typedarray.cpp () from /data/seiscomp/lib/libseiscomp_core.so.15
#14 0x0000155555537b9a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe238, env=env@entry=0x7fffffffe248) at dl-init.c:72
#15 0x0000155555537ca1 in call_init (env=0x7fffffffe248, argv=0x7fffffffe238, argc=1, l=<optimized out>) at dl-init.c:30
#16 _dl_init (main_map=0x555555845760, argc=1, argv=0x7fffffffe238, env=0x7fffffffe248) at dl-init.c:119
#17 0x000015555170b985 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:182
#18 0x000015555553c43d in dl_open_worker (a=a@entry=0x7fffffffc910) at dl-open.c:758
#19 0x000015555170b928 in __GI__dl_catch_exception (exception=<optimized out>, operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:208
#20 0x000015555553b60a in _dl_open (file=0x555555809630 "/data/seiscomp/share/plugins/rtddloc.so", mode=-2147483390, caller_dlopen=<optimized out>, nsid=-2, argc=1, argv=0x7fffffffe238, env=0x7fffffffe248) at dl-open.c:837
#21 0x0000155550c6534c in dlopen_doit (a=a@entry=0x7fffffffcb30) at dlopen.c:66
#22 0x000015555170b928 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffcad0, operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:208
#23 0x000015555170b9f3 in __GI__dl_catch_error (objname=0x5555555e22b0, errstring=0x5555555e22b8, mallocedp=0x5555555e22a8, operate=<optimized out>, args=<optimized out>) at dl-error-skeleton.c:227
#24 0x0000155550c65b59 in _dlerror_run (operate=operate@entry=0x155550c652f0 <dlopen_doit>, args=args@entry=0x7fffffffcb30) at dlerror.c:170
#25 0x0000155550c653da in __dlopen (file=<optimized out>, mode=<optimized out>) at dlopen.c:87
#26 0x00001555527f6297 in Seiscomp::System::PluginRegistry::open(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /data/seiscomp/lib/libseiscomp_core.so.16
#27 0x00001555527f574f in Seiscomp::System::PluginRegistry::loadPlugins() () from /data/seiscomp/lib/libseiscomp_core.so.16
#28 0x00001555527f5be6 in Seiscomp::System::PluginRegistry::loadConfiguredPlugins(Seiscomp::Config::Config const*) () from /data/seiscomp/lib/libseiscomp_core.so.16
#29 0x000015555279592f in Seiscomp::System::Application::initPlugins() () from /data/seiscomp/lib/libseiscomp_core.so.16
#30 0x0000155552796bbd in Seiscomp::System::Application::init() () from /data/seiscomp/lib/libseiscomp_core.so.16
#31 0x00001555538c67b5 in Seiscomp::Client::Application::init() () from /data/seiscomp/lib/libseiscomp_client.so.16
#32 0x000015555501b051 in Seiscomp::Gui::Application::init() () from /data/seiscomp/lib/libseiscomp_qt.so.16
#33 0x0000155552795569 in Seiscomp::System::Application::exec() () from /data/seiscomp/lib/libseiscomp_core.so.16
#34 0x00001555527954d8 in Seiscomp::System::Application::operator()() () from /data/seiscomp/lib/libseiscomp_core.so.16
#35 0x000055555559ae71 in main ()

Have tried to make clean and reinstall without help. scolv on a different machine with same current master branch install works running python3.8 so I can only guess there is something intrinsic to py3.11 here although not sure why that would be.

edit: the other difference is the machine giving me this problem also has a catalog loaded and the one that works does not.

Ubuntu 20.04.5 LTS
python3.11.1
numpy 1.25.5
gcc 9

Thanks for having a look!

I know that macOS is not supported but since the replacement of boost::scoped_lock with std::lock_guard commit 7ba8429
the compiled applications crash on macOS.

Common crash from all the compiled applications comes from the function Seiscomp::Util::Timer::Loop

I changed:
Core::Sleep(1); with the standard C++11 function
[std::this_thread::sleep_for(std::chrono::milliseconds(1000))

but it doesn't fix the crashes.

Has this code been tested on other OSes, like Windows ?
Of course LINUX isn't affected since it uses normal timer via "SC_HAS_TIMER_CREATE".

However macOS doesn't have the built-in functions epoll_ctl nor kqueue and time.h
For time.h it could be added with the following code (but still epoll_ctl error)
https://gist.github.com/lundman/731d0d7d09eca072cd1224adb00d9b9e

Also compiling this C++11 std::lock code with clang-compiler works on macOS:
https://en.cppreference.com/w/cpp/thread/lock

Here's the common Crash log which happens with command seiscomp update-config or from the GUI-applications, e.g: scrttv or scolv.

Note at line 7: Seiscomp::Util::Timer::Loop()`

Thread 3 Crashed:
0   libsystem_kernel.dylib        	    0x7ff8056937ce __pthread_kill + 10
1   libsystem_pthread.dylib       	    0x7ff8056cbf30 pthread_kill + 262
2   libsystem_c.dylib             	    0x7ff8055eaa49 abort + 126
3   libc++abi.dylib               	    0x7ff805684c72 abort_message + 241
4   libc++abi.dylib               	    0x7ff805676d3f demangling_terminate_handler() + 47
5   libc++abi.dylib               	    0x7ff8056840cb std::__terminate(void (*)()) + 6
6   libc++abi.dylib               	    0x7ff805684070 std::terminate() + 32
7   libseiscomp_core.16.0.0.dylib 	       0x11525c1fb Seiscomp::Util::Timer::Loop() + 91
8   libseiscomp_core.16.0.0.dylib 	       0x11525df52 decltype(std::declval<void (*)()>()()) std::__1::__invoke[abi:v160006]<void (*)()>(void (*&&)()) + 18
9   libseiscomp_core.16.0.0.dylib 	       0x11525df2d void std::__1::__thread_execute[abi:v160006]<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (*)()>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (*)()>&, std::__1::__tuple_indices<>) + 29
10  libseiscomp_core.16.0.0.dylib 	       0x11525dc92 void* std::__1::__thread_proxy[abi:v160006]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (*)()>>(void*) + 98
11  libsystem_pthread.dylib       	    0x7ff8056cc202 _pthread_start + 99
12  libsystem_pthread.dylib       	    0x7ff8056c7bab thread_start + 15

Maybe you have some tips on how to fix this ? any help is greatly appreciated.
Thanks!