muonpi / detector-network-processor Goto Github PK

The parsing of detector log messages does not work properly.

The entire message with timestamp, key and value is written to the database instead of just the value.

Due to missing packages in debian bullseye which will be released soon, it would be beneficial to switch away from librestbed and to boost-beast to implement the REST service for the cluster code.

boost-beast also replaces the dependency on libcurl.

Examples can be found here:

https://www.boost.org/doc/libs/1_75_0/libs/beast/doc/html/beast/examples.html

A more advanced way to calculate coincidences and to resolve coincidence conflicts is in order.

Currently conflicting coincidences need to be kept together due to there not being a way to resolve those conflicts.

A possible way how to resolve them could be to score each partial coincidence and selecting only the highest scoring pairs as part of the coincidence.

Ultimately though there is always a potential for remaining conflicts due to incomplete datasets and each coincidence needs to be manually inspected.

Implement a function the Source::Mqtt to parse incoming l1events from mqtt. Without this, the implementation is incomplete and will not work together with local instances of the cluster.

Update the manfile for muondetector-cluster and all descriptions to be consistent with the current version.

Part of this is also the README.md in this repository.

Ditch the current implementation for configuration in the DNP for the implementation in libmuonpi

Migrate the codebase to use https://github.com/MuonPi/libmuonpi/ instead of everything in-code.

For doing more count rate measurements for distances < 1km I am setting up another local detector network.
Currently, the DNP seems only to store L1Events that fall within the dynamic coincidence time window which is given by the detector distance from GPS coordinates and the speed of light.

Is it possible that you change the time window such that we also include some background in the measurement? This would be helpful for analyzing the data afterwards.

A proposed scheme could be:

• For light-distances smaller 10us: store all data within a 10us window
• For light distances larger 10us: store data dynamically based on the detector distance
• Keep the hard upper distance cut at what it currently is (300us? km?)

In the attached figure, I plot the time differences between coincidence events from the DNP, and only events within the blue band (speed-of-light distance between the two detectors) are stored in the database. For me, it would be better to have more background, i.e. 10us as described above.

Thanks :)

Before releasing the code for version 1.0.0, the code needs to run correctly not only on the server but also as a local instance for a dense cluster.

Describe the bug
Restarting the cluster service results in a corrupted state of the new instance Due to a problem with the state saving code.

To Reproduce
restart the cluster on the server, you will see a lower than expected number of known detectors.

Expected behavior
A restart of the cluster should be unnoticeable from looking at the data.

Due to the highest boost version available on raspberry pi OS buster being 1.67, it might be advisable to support this version instead of 1.71 as minimum.
This however requires some rewriting due to differences between 1.67 and 1.71, specifically in boost:beast.

Though this would mean having to maintain two competing implementation of the rest_service class in code due to differences between boost versions 1.6x and 1.7x.

A segmentation fault happens upon creating the current log data when the map which stores the detector stations holds the objects directly, instead of using a std::unique_ptr.

To reproduce, use the commit 66d1a16

Backtrace:

  std::accumulate<double const*, double> (__first=0x7fffdf7ff000, __last=<optimized out>, __init=-nan(0xfffffffffff92))
      at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_numeric.h:141
  141             __init = _GLIBCXX_MOVE_IF_20(__init) + *__first;
  (gdb) backtrace
  #0  std::accumulate<double const*, double> (__first=0x7fffdf7ff000, __last=<optimized out>,
      __init=-nan(0xfffffffffff92))
      at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_numeric.h:141
  #1  muonpi::data_series<double, 100ul, false>::private_mean (this=<optimized out>)
      at include/analysis/dataseries.h:70
  #2  muonpi::data_series<double, 100ul, false>::{lambda()#1}::operator()() const (this=0x7fffc800b3b0)
      at include/analysis/dataseries.h:105
  #3  std::__invoke_impl<double, muonpi::data_series<double, 100ul, false>::{lambda()#1}&>(std::__invoke_other, muonpi::data_series<double, 100ul, false>::{lambda()#1}&) (__f=...)
      at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/invoke.h:60
  #4  std::__invoke_r<double, muonpi::data_series<double, 100ul, false>::{lambda()#1}&>(muonpi::data_series<double, 100ul, false>::{lambda()#1}&) (__fn=...)
      at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/invoke.h:113
  #5  std::_Function_handler<double (), muonpi::data_series<double, 100ul, false>::{lambda()#1}>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/std_function.h:291
  #6  0x0000000000503621 in std::function<double ()>::operator()() const (this=0x7fffc800b3b0)
      at /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/std_function.h:622
  #7  muonpi::cached_value<double>::get (this=0x7fffc800b3b0)
      at include/analysis/cachedvalue.h:43
  #8  muonpi::data_series<double, 100ul, false>::mean (this=0x7fffc800b080)
      at include/analysis/dataseries.h:136
  #9  muonpi::detector_station::current_log_data (this=0x7fffc800a5c8)
      at src/analysis/detectorstation.cpp:191
  #10 0x000000000050dc0c in muonpi::supervision::station::process (this=<optimized out>)
      at src/supervision/station.cpp:95
  #11 0x0000000000436638 in muonpi::sink::threaded<muonpi::detector_info_t<muonpi::location_t> >::step (
      this=0x7fffffffd068) at include/sink/base.h:156
  #12 0x00000000004887ea in muonpi::thread_runner::run (this=this@entry=0x7fffffffd070)
      at src/utility/threadrunner.cpp:114
  #13 0x000000000048924f in muonpi::thread_runner::exec (this=0x7fffffffd070)
      at src/utility/threadrunner.cpp:139
  #14 0x00007ffff7588ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
  #15 0x00007ffff7a90ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
  #16 0x00007ffff7294def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

all initial summaries to be saved to the database contain a value of NaN in most fields.

This stems from the fields being calculated, though upon initialisation there is no data. This needs to be fixed so that the initial value is 0, not nan.