Traffic of arguments in function events_loop for the various cities
expressed more concisely  with the user of DataVectors and PmapVectors
containers.

A KrCity computes and writes KrEvents, e.g, point-like events. This
means that the baricenter integrates all the time slices for a given
SiPM. Instead, a HitCity computes and writes HitEvents, in which the
baricenter (or any other position-finding algo) is computed
slice-by-slice. A HitCity is derived from a KrCity since both of them
use the same file_loop() function (which starts from pmaps).

Without the exit, the command-line test was passing with pretty greens
when the city was not found (e.g, a captured ModuleNotFound, print
that pytest captures and digests without telling anything and happy
ending in spite of wrong situation). Adding traceback still gives
printout when running in normal mode but provides diagnostics of the problem

The first few events are rejected by selection in the test sample in
Penthesilea, running 10 events guarantees that the city runs fully.

this function allows takes an s2sid_peak and slice number and returns
the sipm ids of sipms in that s2si, with their charges at slice number

This is needed to use the corresponding cython function rather than
previous python version.

Include in the list only slices with positive charge.

One has to take into account the possibility that the slice results in
an empty SiPM list. This is handled via SipmEmptyList exception.

In this case, the slice is looped away.

Cecilia is removed from cities. The simulation of the trigger will be
done shortly in Diomira.

Although it may be argued that we reinvent the wheel, the use of a
numerical NN is quite convenient when writing/reading pytables to/from
disk, as a proxy for NaN.

Cluster takes the std (not the rms) as argument. A number of
properties (Xrm and such) are modified accordingly.

The change of definition in Cluster (takes std, not rms) requires to
fix a number of tests.

hit_city inherits now from kr_city. Config. files modified accordingly.

Dorothea is now derived from KrCity, which centralizes the operations
of a city which computes and writes a KrEvent. In particular, in a
KrCity the position of the particle is computed integrating over all
temporal samples in SiPMs, but otherwise using the same
reco-algorithms (configurable) that can be used in HitCity (where
position is computed slice-by-slice).

Like other cities before her, Dorothea has been further simplified,
transfering most of its functionality to the base. In particular,
KrEvent is no longer created by Dorothea (the proper place to create a
KrEvent is in KrCity). Tests have been modified accordingly.

Penthesilea follows the same fate that other cities before, and gets
leaner and thinner (more invisible), transfering functionality to the
base. Following the existing model, it is the HitCity (and not a
derived slave) the one that creates the HitEvent.

The use of "Persistent" class is unnecessary and somewhat
confusing. Following the model of pmap classes, all other "persistent"
classes now include a method store that is used by the corresponding
writer for persistent storage. Thus, classes PersistentHitCollection
and PersistentKrEvent have been sent to Valhaya.

Several tests use now HitCollection and KrEvent rather than
PersistentHitCollection etc. Notice that instantiation to persistent
classes is no longer done in Dorothea or Penthesilea, but in the base.

Dead code removed, some cosmetics applied.

Dorothea must call kr_city.con (it was calling hit_city.conf)

Some times Corona may find an empty list, in which case an exception
is raised.

To follow the standard convention

This PR simplifies the structure of the cities, making then one step
closer to the goal of being truly invisibles. The most important
features are:

  1-Most cities have the same run() method, that now goes to the
    base (only Zaira needs to re-write the run() method).

  2- Cities reading RWF (Isidora and Irene) have the same file_loop()
    method, that now goes to their common base.

  3-Cities reading PMAPS (Dorothea and Penthiselea) have the same
    file_loop() method that now goes to their common base (Dorothea
    and Penthiselea both inherit now from HitCity).

  4-A counter class allows easy bookeping and common go() method.

Overall, the concrete cities are much thiner and simpler, with
considerable reduction of noise and sizeable repayment of TD).

s2si automatically set its peaks to be the peaks in s2d even if the
s2sid did not have all those peaks. this has been fixed

find_s12 sometimes initialized the start of the first peak to the
incorrect time. this has been fixed and a test has been added.

a function in pmap_functions_c was printing a few integers for each
event

S2Si sets its peaks to be those present in s2d. This is unacceptable
when the sipms do not have signal during the one or more of the peaks
in s2d. this has been fixed by check_s2d_and_s2sid_share_peaks in
pmaps.pyx.

Daemons (see Nother Lights) are people's (external) souls in Lyra's
world. In IC daemons are slave (or companions) objects that can be
invoked from cities.

Consider for example the problem to add monitoring histograms to a
given city. One solution is to write all the monitoring code in the
city itself. Master would not like that for sure. The city becomes
immediately cumbersome, and the code booking and filling histograms
proliferates quickly. Plus, monitoring is tipically not stable, since
the critical histograms tend to vary with time.

The alternative is that the city calls a monitoring script (ms). At init
level, the city will call the init level of the ms (say to book
histograms). Then, at run level the city calls the run method of the
ms (fill histograms) and finally, at at the end level the city calls
the end method of the ms (save histograms to disk).

The scheme is quite general, and applies to any type of script that a
given city wants to invoke to delegate any task. Thus, a daemon is
defined as an object with an __init__() method, a run method and an
end method.

Daemons live in the new daemons directory (package) in IC. In this
commit, we define the base class and two toy daemons (Lyra and
Asriel). The daemons are defined by the variable deamons in the
corresponding city, which is associated to a list of names, each name
representing one daemon (the city will invoke all of them). The code
for daemon invocation is also defined in this commit.

Method run can now read the list of daemons, invoke them and set them
to the class instances. In addition, run calls now the metod go and
the method end.

Method end calls the end method of all daemons and returns the counter
dictionary.

In the spirit of testing the command line, this test runs irene with a
configuration file that invokes two toy daemons, Lyra and Asriel.

In several tests we need to change cnt = city.run() by
city.run()
cnt = city.end()

Add daemons to IC

Daemons (see Northern Lights) are people's (external) souls in Lyra's
world. In IC, daemons are slave (or companions) objects that can be
invoked from cities.

Consider for example the problem to add monitoring histograms to a
given city. One solution is to write all the monitoring code in the
city itself. Master forbids! The city becomes
immediately cumbersome, and the code booking and filling histograms
proliferates quickly. Plus, monitoring is typically not stable, since
the critical histograms tend to vary with time.

The alternative is that the city calls a monitoring script (ms). At init
level, the city will call the init level of the ms (say to book
histograms). Then, at run level the city calls the run method of the
ms (fill histograms) and finally, at at the end level the city calls
the end method of the ms (save histograms to disk).

The scheme is quite general, and applies to any type of script that a
given city wants to invoke to delegate any task. Thus, a daemon is
defined as an object with an init() method, a run method and an
end method.

Daemons live in the new daemons directory (package) in IC. In this
PR we add to IC the functionality to handle daemons.

  1-The config files for cities can now define the presence of daemons
    by adding a variable called (surprise!) daemons which is set to a
    list of names (see irene_example_daemon_config.conf)

  2-The method drive in base city parses the names and calls function
    invoke_daemons() to return instances of the corresponding classes,
    which must be defined in the daemon directory (see examples
    lyra.py and asriel.py).

  3-Also in drive, the instances of the daemons are set as attributes
    of the cities, which can now call them.

  4-A new method, in base_cities, called end() calls the end() method
    of the daemons. The run method of the daemons are called by the
    concrete cities.

Base cities has been refactored to introduce three new cities:

1) RawCity: a city that reads RawData.
2) PmpCity: a city that reads PMAPS.
3) DstCity: a city that reads DSTs (KDSts), formely called MapCity.

Inheritance from those cities provides common functionality for the
file_loop() method. Thus, Irene, Isidora and Diomira, all are
RawCities (although Diomira reads MCRD while Irene and Isidora read
RWF), Dorothea and Penthesilea are PmpCities and Zaira is so far the
only example of a DstCity (but there will be likely others).

The cities still keep a linear scheme of inheritance, since
DeconvolutionCity inherits from RawDataCity propagating the
functionality to Irene and Isidora (both of them Deconvolution cities)
while KrCity inherits from DstCity, propagating the functionality to
Dorothea and Penthesilea.

The base clase formely called SensorResponseCity has been renamed to
MonteCarloCity. It inherits from RawCity (since it reads raw data) and
provides the functionality for Sensor Response Simulation AND Trigger
simulation.

Configuration files have been refactored to reflect the new
inheritance structure of cities. Thus, raw_data_city.conf includes
city.conf while deconvolution_city.conf now includes
raw_data_city.conf, and son on.

This general-use function was in the wrong place and has been
relocated.

There are two types of Raw Waveforms, RWF and MCRD. A RawCity defines
by configuration which type of raw waveform is using. The exception
UnknownRWF is raised if an unknown type of Raw Waveform (other than
 or MCRD)

This commits continues the refactoring of base_cities.
The most important addition is the TriggerEmulationCity, which allows
the emulation of the trigger. Class MonteCarloCity inherits now from
TriggerEmulationCity (which provides the capability to read Raw
Waveforms), and Diomira inherits from MoteCarloCity (and thus from
TriggerEmulationCity). This scheme allows Diomira to read raw
data (MCRD), simulate sensor response (functionality from
MonteCarloCity) and emulate trigger (functionality from
TriggerEmulationCity).

In addition, this commit includes:

1. legal and credits
2. cosmetics
3. re-organization of methods
4. Class PmpCity is rebaptized PCity (to avoid confusion with
PmapCity)

The Trigger filter module selects events that pass the trigger. This
commits fixes bugs and completes the code that is now passing tests.

Exceptions FileLoopMethodNotSet and EventLoopMethodNotSet are added to
the IC suite. Those exceptions are triggered if the file_loop (or
event_loop) method defined in the base class are nor superseeded.

All parameters in find_s12 function must be provided by the calling
functions find_s1 and find_2. Consequently, no optional parameters
have been left.

Diomira has been refactored so that, in addition to simulate sensor
response it can now emulate the S2 trigger (and select events that
pass the trigger). Tests have been fixed accordingly.

All configuration files have been adapted to reflect the changes in
base_cities and in Diomira and friends.

File trigger_emulation_city.conf now defines the trigger emulation

PATH_OUT was pointing to the wrong spot.

This PR transfers to Diomira the functionality intended for Cecilia
who knows rests in peace until next incarnation. The PR introduces
also a number of improvements, whose need has been revealed by the
need to emulate the trigger. Specifically in this PR:

Base cities has been refactored to introduce three new cities:

    RawCity: a city that reads RawData.
    PCity: a city that reads PMAPS.
    DstCity: a city that reads DSTs (KDSts), formely called MapCity.

Inheritance from those cities provides common functionality for the
file_loop() method. Thus, Irene, Isidora and Diomira, all are
RawCities (although Diomira reads MCRD while Irene and Isidora read
RWF), Dorothea and Penthesilea are PCities and Zaira is so far the
only example of a DstCity (but there will be likely others).

The cities still keep a linear scheme of inheritance, since
DeconvolutionCity inherits from RawCity propagating the
functionality to Irene and Isidora (both of them Deconvolution cities)
while KrCity inherits from DstCity, propagating the functionality to
Dorothea and Penthesilea.

Furthermore this PR adds a TriggerEmulationCity, which allows
the emulation of the trigger. The base clase formerly called
SensorResponseCity has been renamed to MonteCarloCity and made to
inherit from TriggerEmulationCity (which provides the capability to
read RawWaveforms). Finally, Diomira inherits from MoteCarloCity (and
thus from TriggerEmulationCity). This scheme allows Diomira to read
raw data (MCRD), simulate sensor response (functionality from
MonteCarloCity) and emulate trigger (functionality from
TriggerEmulationCity).

Configuration files have been refactored to reflect the new
inheritance structure of cities.

If the user specifies a negative run number, the result obtained will
be the same as the absolute value of that run number. The negative
sign implies that config file is for MC.

This PR changes the way we use the DB. Instead of using just run
number 0 for MC, now the idea is to put a negative number. The
configuration obtained will be the same as the one from the same
positive run number. The negative sign will indicate that is an MC
file.

For the usual application (search for S1 and S2 over the calibrated
sum), S1 is not rebinned and S2 is rebinned to 1 mus. However there
are other user cases. Specifically, when emulating the trigger, the
search for peaks over individual PMTs is done with waveforms that are
deconvoluted but not rebinned. Thus, it is a bad idea to hard-wire the
defaults. With this commit they are introduced as parameters.

The configuration file of diomira, pamp_city and
trigger_emulation_city are adapted to reflect correct values for all
parameters.

For unknown reasons, we were passing the wrong
calibration (sipm_adc_to_pes) constant to the simulation of the
pmts. Now fixed!

Diomira simulates the response of the PMTs FEE. It uses the data base
to pass the various calibration constants needed, including
deconvolution constants. However, it was assuming that run_number for
MC was *always* zero, as per the previous convention. This has changed
now (MC run number is negative and will match the corresponding run
number in data) and thus it is needed to propagate run_number all the
way up to FEE.

This small PR fixes a minor (major) issue.

DIOMIRA simulates both the response of the sensors and the
trigger. When emulating the response of the trigger, one is simulating
the search on the FPGA on peaks in individual PMTs. This search is
performed with the same algos used to search s1 and s2 in the
calibrated sum, but the individual PMTs are neither calibrated, nor
rebinned.

Consequently, the search for s1 and s2 must allow the possibility that
the waveform is not rebined (previously we never rebinned s1 but
always rebinned s2). This is done in this PR, together with defining
proper parameters for DIOMIRA.

Class Voxel is moved to event_model where it belongs.

Voxel, Hit and Cluster are all similar beasts. This is expressed by
defining a common ancestor BHit (actually BHit is equal to Voxel, but
we keep a separate definition for clarity). The inheritance chain
enhances the common structure of the objects and avoid duplications.

The refactoring of Cluster-Hit-Voxel has shown a feature that was
identified long ago and then forgotten. Namely, in a cluster, the
field called pos should be called posxy (since it describes a xy
point). This is now necessary to avoid conflict with the pos property
which is (ast it should) xyz.

A new test for Voxel has been added and all the tests have been
adapated (in particular to the change: pos to posxy in Cluster).

This function is used internally in tests, but function
compute_pmaps_from_rwf should be used in the API instead. Thus, it is
made private. Tests are modified accordingly.

CalibVectors rather than CalibParams

The current version of trigger emulation only emulates trigger on
S2. The condition of calling the emulation only if trigger_type is set
to S2, permits NOT to call the trigger emulation if the trigger
is set on S1 (or the user does not want to emulate the trigger)

Cecilia has merge her soul with that of Diomira and needs to further
configuration.

The Monte Carlo simulation produces occasional empty events, which are
characterized by flat waveforms running within the noise line. Irene
had already implemented a protection against those events, which
required that the sum of the zero-supressed waveforms were not
zero. However, a closely related cousin is an event whose
zero-supressed waveform yields a small number (due to noise
fluctuations) but still yields no s1 or s2 indexes on the search (e.g,
once a cut on 1-2 pes is imposed the waveform happens to be empty).

This commit expands the defence against such type of events, organizes
it in a function and adds counters for classification of the zombies.

This PR includes fixes needed to extend the functionality of
Penthesilea (so that it can call Paolina). The most significant change
is the re-factoring of the Voxel-Hit-Cluster classes that are now
organised consistently. All classes are derived from a BHit
class (which defines a base-hit (x,y,z,E) and is identical to Voxel,
which keeps a different name for clarity).

An old-standing issue related with Cluster has been fixed. Cluster had
a "pos" attribute which returned an (x,y) vector, while a "pos"
attribute of a hit should return an (x,y,z) vector, has it happens
now. The old "pos" in Cluster has been renamed to "posxy".

In addition a number of small miscellaneous fixes and improvements
have been implemented.

find_s12 is too big for no good reason. By splitting it up we are able
to easily find the s2pmt (s2s of the individual pmts). The code is
also more modular legible testable.