Minutes of SG Meeting of 04 11 99

Present:   T.Cass, M. Cattaneo, C.Gaspar, F.Harris, J.Harvey, B.Jost, P.Mato, F.Ranjard, I Videau

1.Software Weeks

2.SICB

3.BRUNEL

    •  
    • Organise help to algorithm developers : event model and detector description. Setup review procedures. It was felt that close frequent contacts between the GAUDI experts and the SD groups will be needed for all aspects of the OO code. John will send a memo to SD contacts informing them of what was presented and agreed during the LHCb week and suggesting a model for organising this work. He will also discuss directly with those responsible to ensure that urgent tasks related to splitting of SICB are done by the agreed timescale ie Jan 10th.
    • What models do we need to encourage? use cases, design, test, what else? It was agreed that more formal approach to developing models for various (to be agreed) phases of the life-cycle should be taken for the framework components. This will serve as an example to SD developers and will aid the review procedures to be put in place. John is developing documentation templates to support this. The existing documentation will need to be adjusted to use these templates.

4.GAUDI

    •  
    • Collaboration with ATLAS. Discussions are in progress with ATLAS with a view to some sort of collaboration on software architecture with the goal of being able to share components.
    • Second GAUDI review. We will aim to hold this during the first week of March. Candidates for external reviewers are Quarrie, Callot, Stickland, Deacon. Exact date will depend on people's availability.

5.Computing Model Studies WG

    • Organisation of this new activity.
    • Organisation of this new activity. Frank itemised the various tasks including logical dataflow model, usecases, resource requirements, technology tracking, etc. This activity will require input from the various subsystems (DAQ, Reconstruction, etc), physicists for usecases, representatives from each country for regional centre policies, IT for technology tracking etc. Project plan will be developed to match requests from the Hoffmann review. It is aimed to have a first version of the dataflow model by mid January.

6.Controls

    •  
    • SCADA - reply on market survey papers. Concept of devices should apply at the network level. The SCADA system should work well for small systems (100 channels) as well as for large systems (1000000 channels). Error messages should have an online HELP facility.
    • SCADA in test beam : Muon and calorimeter candidates. Testbeam activity should start next May. It may be interesting to make use of SCADA to get experience with realistic prototypes. Clara will follow up.
    • Departure of Philippe Gras.  Philippe will be a doctoral student working on CMS.Clara is now an OPC expert.

7.DAQ

    •  
    • DAQ support for testbeam. Candidate proposed made by Jacques Lefrancois to be followed up to see if financial support can be found. UNIX system management support and general support to testbeam issues have been requested. CASCADE works well and no new features have been requested so far.
    • Status of recruitment for new LHCb DAQ post. Interviews will be held on Jan 13th. There are 7 candidates to be seen.

8.News from IT division

    • Reorganisation of IT. Tony presented the new structure. He becomes the new group leader of the Technical Services group but hopers to combine this with his role of LHCb/IT contact person. Manuel will request the experiments views on the role of the contact person.
    • Status of lxplus and lxbatch. We will switch to RedHat 6.0. Many new machines have been added to the lxplus service.

9.Preparation of TDRs

    •  
    • Guidelines for production of LHCb TDRs (see attached note). We must be prepared to provide some guidelines and support for the production of TDRs.

10. CHEP2000

    • Participation, speakers and preparation of papers. All 5 papers were accepted. Marco, Markus, Rado and Florence will make presentations. Beat feels there has not been enough progress on event building so will discuss with Jean-Pierre whether the paper should be withdrawn. John will find out who wishes to attend and organise that we can share the same hotel.

11. AOB

    • Next meeting planned for January 6th to be confirmed nearer the time.

Backing notes :

Guidelines for production of LHCb's TDRs

Framemaker is recommended at CERN for large documents. A TDR template has been prepared and is maintained by IT/IPT group. Mario Ruggier gives support. ATLAS used template for all their URDs and the feedback from them is given below. If LHCb is to have a policy on how to produce the TDRs need to prepare now. For Magnet TDR it is already too late. Work on the RICH TDR will start soon.

There is work for Computing Group to produce some guidelines on how to organise the production of TDRs:

  • Collect some requirements e.g. support for equations and figures, platforms,..
  • Identify roles: editors,..
  • Select documentation tools: Framemaker? Format for Figures..
  • Sort out licences and organise training and support

 

Feedback on TDR template from Rudiger Voss

"Personally, I converted from a sceptic to a strong supporter of FrameMaker (at least for this type of document) in the process of editing the Muon TDR, and I support equally strongly every move aimed at standardising such tools inside EP Division and across collaborations."

Feedback on TDR template from Torsten Akesson:

I have collected a few opinions and try to summarise them below.

I think that overall people think that it was a good move to go to Framemaker for the TDRs, and the views span from enthusiastically thinking so, to thinking so with hesitation. There is no correlation between how new people were to Framemaker at the time, and how much they support the move today.

There is a very strong support for the templates you provided. This seems fundamental. People are also very satisfied with the help we got from you.

I think that many of the people forced into Framemaker by the TDRs does still use it, also for transparencies. However, some also think that the program is too heavy for small documents.

Some problems have been reported on inclusion of EPS files produced by different systems.

One opinion expressed is that LaTeX is superior in the final typesetting, and two expressed the opinion that mathematical formulas are a bit cumbersome.

One non-technical problem we recently got is with the Los Alamos server, which wants LaTeX for submitted papers.

One note I would add is that moving to Framemaker for the TDRs gave us the tool to produce all ATLAS posters in a very convenient way.

Again I would like to stress that people were very satisfied with the support they got from you.