Skip to content

Tags: mwinn2/AliceO2

Tags

nightly-20181001

Toggle nightly-20181001's commit message
DPL: example of how to create a custom GUI

Sometimes it can be handy to create a custom GUI to inspect contents of
a messages, state of the algorithm or simply some custom controls in a
quick, throw away, manner. The example in
`Framework/Core/test/test_CustomGUI.cxx` shows how to do that using the
same kind of toolkit used by the DPL debug GUI.

Notice that in order to keep things simple, the example will open one
new window per initGUI() and requires redrawing on each iteration.

nightly-20180930

Toggle nightly-20180930's commit message
DPL: Initialize things in the init function and not elsewhere

Solving a memory problem in the digitizer workflow by moving the initialization
of the TPC digitizer into the actual init lambda.

Before it was done in the "getDataProcessorSpec" function. This is not a good place
since in fact every single DPL processor/process with evaluate this function (if it needs it
or not) upon topology creation.
In this case, every single DPL processor was instantiating pixels of a TPC readout chamber...
even though it was not actually doing TPC stuff.

We need to be careful about that. Some other data structures such as shared_ptrs need to be revised
in different places.

On the other hand, I think there is no need that every single processor evaluates the whole topology
at startup. This should really be done by a single master processor which communicates the topology
to the forks. This would also avoid such problems.

nightly-20180929

Toggle nightly-20180929's commit message
DPL: Initialize things in the init function and not elsewhere

Solving a memory problem in the digitizer workflow by moving the initialization
of the TPC digitizer into the actual init lambda.

Before it was done in the "getDataProcessorSpec" function. This is not a good place
since in fact every single DPL processor/process with evaluate this function (if it needs it
or not) upon topology creation.
In this case, every single DPL processor was instantiating pixels of a TPC readout chamber...
even though it was not actually doing TPC stuff.

We need to be careful about that. Some other data structures such as shared_ptrs need to be revised
in different places.

On the other hand, I think there is no need that every single processor evaluates the whole topology
at startup. This should really be done by a single master processor which communicates the topology
to the forks. This would also avoid such problems.

nightly-20180928

Toggle nightly-20180928's commit message
Implementing parallel processing in the tpc-reco-workflow

Moving TPC reco workflow definition to separate file and creating library for module
TPCWorkflow with reco workflow and processor specs.

Parallel workflow can be configured using option '--tpc-lanes n'

Added features:
- workflow option --tpc-lanes
- DigitReaderSpec fan out
- CATrackerSpec fan in
- adding input type 'digitizer' to connect directly to the digitizer workflow
- adjusting data descriptions to output of digitizer workflow ('DIGITS', 'DIGITSMCTR').
- forwarding empty data sets at end of processing.
- adjusting processor names: prefix tpc

nightly-20180927

Toggle nightly-20180927's commit message
Adding missing option '--tracker-options' to tracker spec

This has actually been forgotten to be added to the options definition while
it was already queried. Have to check why the error message slipped through.

The TPCCATracking worker class can be initialized with a string of options,
e.g. now one can specify --tracker-options "refX=83"

nightly-20180926

Toggle nightly-20180926's commit message
Fix inconsistency warning for TPC digit labels

Warning had a logic error.

nightly-20180925

Toggle nightly-20180925's commit message
DPL: support dangling inputs

Those are inputs which do not have a counterpart in the workflow
spec definition but which can be treated automatically by either
the framework (e.g. in the case of conditions) or by the deployment
system (e.g. in the case of deploying on the O2 farm, we should get
the input directly from the TimeframeBuilder.

nightly-20180924

Toggle nightly-20180924's commit message
Removing dependencies from module DataFormats/Headers

Introducing bucket for module DataFormats/Headers with minimal dependencies

nightly-20180923

Toggle nightly-20180923's commit message
Removing dependencies from module DataFormats/Headers

Introducing bucket for module DataFormats/Headers with minimal dependencies

nightly-20180922

Toggle nightly-20180922's commit message
Removing dependencies from module DataFormats/Headers

Introducing bucket for module DataFormats/Headers with minimal dependencies