2. Liverpool Experience of MDC 1 MAP (and in our belief any system which attempts to be scaleable to 1000s of nodes) broadcasts the code to all the nodes. Even using NFS mount we believe multiple servers would be needed for systems even of order a few 100 nodes. 300 Processor Farm MAP Starting with 1.1Gb of software is therefore horribly time- consuming, particularly as, when stripped down, 153 Mb turned out to be needed (atlsim.exe, root and a few other shared object libraries). This could have been done prior to distribution by the authors or, much better, distribute static executables as is done by LHCb.

3. Liverpool Experience of MDC 1 4-vectors as 5 lots of 100k events (2Gb each) have to be copied to each node to read only 5k events which proved very wasteful. In this format we were obliged to run as 5 queues of 20 jobs ie using 1/3rd of MAP but to the exclusion of everything else since each job took 60 hours, not really compatible with a multi-user system. A shared batch system needs the flexibility of much shorter jobs. If we could split the input files into 500 events each then this would have given much less redundancy and full useage of the system. As it was, we had to physically rewire the cluster.

4. Liverpool Experience of MDC 1 We really needed either code to merge output files or any code that reads the files so we can write our own merging programme. Output file sizes also led to 25% of jobs needing to be rerun and with smaller jobs we would have had much less problem and would have lost much less time due to miscalculations of space. The validation code also needs adapting to each site and we could again do with being able to run a small number of events first and check whether things are working as they should. On a completely different topic: In terms of communications: we would expect on current form to be able to ship 20 files of 1Gb to CERN over 24 hours.