Project

General

Profile

Bug #1351

Data structure issue in V1724

Added by Rogers, Chris almost 10 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
RealData
Target version:
Start date:
04 October 2013
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

We had a DataStructure error in the control room running today. Looks like tofcalib reducer was failing with log file as attached. I believe the error is in file src/input/InputCppDAQData/UnpackEventLib.cc function int V1724DataProcessor::Process(MDdataContainer* aPartEventPtr)

int V1724DataProcessor::Process(MDdataContainer* aPartEventPtr) {
  // Cast the argument to structure it points to.
  // This process should be called only with MDfragmentV1724 argument.
  if ( typeid(*aPartEventPtr) != typeid(MDpartEventV1724) )  return CastError;
  MDpartEventV1724* xV1724Evnt = static_cast<MDpartEventV1724*>(aPartEventPtr);

  Json::Value pBoardDoc;
  Json::Value xfAdcHit;
  int xLdc, xGeo, xEquip, xPartEv;
  string xDetector = "unknown";
  if ( !xV1724Evnt->IsValid() )
    return GenericError;

  // Put static data into the Json
  pBoardDoc["ldc_id"]       = xLdc = this->GetLdcId();
  pBoardDoc["equip_type"] = xEquip = this->GetEquipmentType();
  pBoardDoc["time_stamp"]          = this->GetTimeStamp();
  pBoardDoc["phys_event_number"]   = this->GetPhysEventNumber();
  pBoardDoc["part_event_number"] = xPartEv = this->GetPartEventNumber();
  pBoardDoc["geo"]          = xGeo = xV1724Evnt->GetGeo();
  pBoardDoc["trigger_time_tag"]    = xV1724Evnt->GetTriggerTimeTag();
  // Loop over all the channels    
  for (unsigned int xCh = 0; xCh < V1724_NCHANNELS; xCh++) {
    unsigned int xSamples = ( xV1724Evnt->GetLength(xCh) )*V1724_SAMPLES_PER_WORD;
    for (unsigned int j = 0; j < xSamples; j++) {
      int sample = xV1724Evnt->GetSampleData(xCh,  // Channel ID
                                             j);  // Sample ID
      _data.push_back(sample);
    }
    xfAdcHit = pBoardDoc;
    this->set_pedestal();
    int charge_mm = this->get_charge(ceaMinMax);
    if ( !_zero_suppression ||
         (_zero_suppression && charge_mm > _zs_threshold) ) {
      xfAdcHit["charge_mm"]    = charge_mm;
      xfAdcHit["charge_pm"]    = this->get_charge(ceaPedMax);
      xfAdcHit["position_max"] = this->get_max_position();
      xfAdcHit["pedestal"]     = this->get_pedestal();
      DAQChannelKey* xKey = _chMap->find(xLdc, xGeo, xCh, xEquip);
      if (xKey) {
        xDetector = xKey->detector();
        xfAdcHit["channel_key"]   = xKey->str();
        xfAdcHit["detector"]      = xDetector;
      } else {
        xfAdcHit["detector"] = xDetector = "unknown";
      }
      xfAdcHit["channel"]        = xCh;

      ( *_docSpill )[xDetector][ xPartEv ][_equipment].append(xfAdcHit);
    }
    _data.resize(0);
  }

  return OK;
}

When the "detector" is "unknown", "channel_key" is not set and I believe this is causing the problem. I notice this is also a problem in some of the other DataProcessors. Propose to fix that we make an empty branch "channel_key" = "" when detector is unknown.


Files

reconstruct_daq_tofcalib_reducer.log (7.88 KB) reconstruct_daq_tofcalib_reducer.log Rogers, Chris, 04 October 2013 10:58

Related issues

Related to MAUS - Bug #1352: End-of-run dataflow issueClosedRogers, Chris05 October 2013

Actions
Related to MAUS - Support #1384: Reconstructing data from recent collection fails with CppError.OpenKaradzhov, Yordan03 December 2013

Actions
#2

Updated by Rogers, Chris almost 10 years ago

Note also excerpt from maus-input-transform.log

 1283 Polling celery queue
   1284     Celery task 2668a0a2-f142-4e11-a628-932b7bca6892 status is SUCCESS
   1285 Spills input: 44 Processed: 51 Failed 0
   1286     Celery task 4ccc290b-ddca-43f2-aa51-4cf61e5916a2 status is SUCCESS
   1287 Spills input: 44 Processed: 52 Failed 0
   1288 0 tasks remain in queue
   1289 Submitting task a109c5b0-3a7f-4516-97e6-ddbaf521235a
   1290 Getting event 
   1291 Run #: 5199
   1292 Event #: 0x130971c8
   1293 Type: 7
   1294 Length: 5019360
   1295 Data size: 5019288
   1296 ERROR in MDpartEventV1724::Init: INVALID particle Event
   1297 *** Unpacking exception in MDfragment::InitPartEventVector
   1298 while processing V1724 fragment (board Id: 8)
   1299 *** Unpacking exception in MDprocessManager::ProcessSubEvent :
   1300 while initializing the fragment
   1301 *** Unpacking exception in InputCppDAQData::getCurEvent() : 
   1302 DAQ Event skipped!
#3

Updated by Rogers, Chris almost 10 years ago

And the offending output from tofcalib reducer

Traceback (most recent call last):
  File "/home/mice/MAUS/.maus_release/src/common_py/ErrorHandler.py", line 162, in HandleCppException
    raise CppError(error_message)
ErrorHandler.CppError: In branch daq_data
In branch unknown
Failed to recognise all json properties V1724  at ObjectProcessor<ObjectType>::JsonToCpp
Traceback (most recent call last):
  File "/home/mice/MAUS/.maus_release/src/common_py/framework/merge_output.py", line 281, in execute
    run_again = will_run_until_ctrl_c and self._execute_inner_loop()
  File "/home/mice/MAUS/.maus_release/src/common_py/framework/merge_output.py", line 327, in _execute_inner_loop
    self.process_event(spill)
  File "/home/mice/MAUS/.maus_release/src/common_py/framework/merge_output.py", line 238, in process_event
    raise RuntimeError("Failed to execute Output")
RuntimeError: Failed to execute Output
#4

Updated by Rogers, Chris about 8 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

I presume this was fixed...

Also available in: Atom PDF