Given that we have received a lot of help from one of our
Japanese colleagues, todays executive summary of offline work
is in the form of a haiku:

     Yesterday it worked
     But today it does not work.
     ATHENA's like that!


   At some point between tuesday evening and wednesday it seemed
like we had mastered bytestream decoding in the ATHENA. Juergen
and I had got an ATHENA algorithm to invoke bytestream decoding.
We started with CPM DAQ fragments - but the file we started
looking at seemed not to have any (according to Juergens run of
SimpleTBA) so we added a bytestream decoder for JEM DAQ fragments.

   At this point it became clear that
(a) we hadnt conveyed our requirements to Tadashi clearly enough
    (although we thought we had - but its hard to talk to him)
(b) we hadnt quite adopted the right approach

   It seems the bytestream conversion service has certain limits
and only likes to make one StoreGate object of a given class
despite StoreGate having a key mechanism. (Im not entirely sure
of this though).

   To try processing the JEM fragments in our favourite file
we temporarily removed the CPM bytestream decoder infrastructure.
Unfortunately at this point ATHENA decided to sulk. Bizarrely
the same RecExTB installation sulked in different ways for me
and Juergen - much more dramatically for Juergen. Especially
galling after he had so kindly, gently and patiently led me
through the steps of running my first ATHENA job the day before.


   Tadashi sensibly enough went into hiding yesterday afternoon
but we managed to talk to him again this morning. It now seems that
as we have several different kinds of ROD fragment (and/or several
instances of the same fragment in ATLAS) which we would ideally
like to process all at once, the example he initially showed us
(the MuCTPI) was not really appropriate. That is simpler and just
deals with one kind of fragment.

  So instead of a simple ByteStreamConverter service we really
need (I now think) a ByteStreamCollectionConverter. This can be
configured to process several ROD fragments at once and produce
one collection of them all. This needs some extra infrastructure
I didnt have time to investigate this afternoon especially since
the CTP team arrived with CMM cable wanting to test it.

  Juergen and I discussed the best immediate strategy and thought
that as the side of taking objects from Steves decoder and filling
ROOT structures will be similar in either SimpleTBA or RecExTB
environments that he should concentrate on that for the moment.

  We can try again to do the bytestream decoding properly with
a bit more understanding later.

  Right now I can see two approaches:
(a) the ideal solution seems to be the bytestream collection
    conversion of many fragments at once into a single container
(b) a quick and dirty alternative would be to make separate
    dummy subclasses of L1CaloRdoStore. This would I think allow
    the bytestream converter to be invoked four times to make
    four separate objects each of a different class. That might
    keep it happy.

  Since Juergen has just said he has persuaded ATHENA out of its
earlier sulk one of the above could be pursued. But perhaps a bit
of SimpleTBA for a while may be good to raise the spirits.