R1 Information and Comments
- As everybody probably realised, the demo about R1 made
on Nov 16 showed many problems and opened many issues.
I'm glad to see that almost all the issues have been addressed at the Santa
Fe meeting and either a solution has been found
or adequate actions to undertake have been decided. Here is a resume of what
happened, with some ideas for the next release. At the bottom of the page
you will find links to the build results and some graphs.
- One of the newest problems we saw can be considered solved,
or at least a workaround has been found:
the crash of the Cpp Default Container due to TELCAL is actually the same
which happened earlier in the integration for CORRELATOR. It is a problem
addressed in ALMASW2003033 and should disappear with gcc 3.x (so with ACS
3.0).
To make things work within R1 it is enough not to start the CORR and TELCAL
channels (i. e. let EXEC do this).
(For curious people: this was not seen before because it appeared only after
the use of the python script for the CONTROL
initialistion. I can give you more details if you want).
- The fact that events were not found by EXEC (a part one
from CORR) can be considered a failure of the release. But in the past days
I've been working together with people in Socorro, in particular Dave and
Sohaila and the reasons of the problem have been better understood.
In one word, I think it is again a problem of bad comunication.
The EXEC subsystem uses a configuration files where the "events"
are listed. The syntax of this file seems unknown to the most part of the
developers and myself; it is not totally clear what to write in the field
"name", what to write in the field "type".
Also, digging into the code, the implementation can also vary a lot: for CONTROL,
for example, if the event name "ALMA.Control.ExecBlockEvent" is
used (initially, that one seemed to be the correct syntax to use), nothing
is detected. If then "EXECEVENTS" (a const string found grepping
over the source code and ICDs) is used, EXEC manages to find it.
By the way, note that earlier that name was thought to be a channel.
I think that some action from HLA is needed to better define all these things
(namely, events and channels, their attributes and their names - and naming
conventions to follow - and their implementation).
I hope that for next release the EXEC configuration file will be completed
and will give the expected results without too many troubles.
For the record: at the moment CORR event and EXECEVENTS from CONTROL are the
events detected.
- As some of you saw at the demo, it was not possible to
simply start EXEC to have everything work: some manual steps were needed.
In particular: we had to start the channels before starting EXEC to avoid
error messages from the EXEC output.
This because EXEC starts consumers before the channels were created. This
problem should disappear with ACS 3.0, where the consumer, when started, will
poll until the channel is active.
- Another manual step was the initialisation of CONTROL and
PIPELINE.
This should also disappear for next release. At the Santa Fe meeting the subsystem
states have been better defined and this should make possible a clean startup
of all subsystems from the EXEC GUI without any manual intervention.
- Some other problems have been translated in SPRs and I will not repeat them here.
- Finally I want to mention that we did not manage to do
more (and maybe it was possible) because we had to spend a lot of time the
first month of the integration to have everything compiling fine.
This because it was the first time we were using the ICD structure and many
conflicts had to be solved before going on with the unit test and system test
preparation.
Hopefully for the next release the compilation will go smoothly. We'll see
if the freezing of the ICDs the 15th of the month will improve things.
