In Tables I and II we list the data volumes per year that we expect to record to tape for MINOS from the far and near detectors respectively assuming a high energy beam. The number of neutrino interactions from the far detector is small, on the order of 22,000 per year. The rate from the far detector is dominated by 1Hz of cosmic ray m interactions. The neutrino interaction rate from the near detector will be somewhat larger, namely 105 Hz for the high energy beam. Of this 105 Hz, a small fraction, < 1 Hz , is in the central 25cm of the target region and will be used for neutrino oscillation studies. A somewhat larger region will be used for studies of conventional neutrino physics (about 4 Hz). There will also be 11 Hz of events where a neutrino interacts upstream in the rock and produces a m in the detector. The near detector DAQ system is capable of recording the full 250 Hz of cosmic rays m seen by the near detector but it is expected that we will record only a fraction of these for full reconstruction and this is reflected in the numbers in Table II. The far detector assumes 3´ 10⁷ seconds in one year (cosmic rays are always there) and the near detector assumes an effective year of 10⁷ seconds. For simplicity, 1Kbyte º 1000 bytes. The data is expected to expand by about a factor of 5 after processing.

Table I Event rates for the far detector

Table II Event rates for the near detector

The total processed data volume per year from both near and far detectors is about 5.5 Terabytes. Assuming a tape capacity of 20 Gbytes (current STK technology) we would require about 300 tapes/year to archive the complete data from both detectors. This is about 5% of the current STK library per year. The physics data, both neutrino oscillation and conventional, will be stored permanently on disk (about 170 Gbytes/year). How much of the remaining data is stored permanently on disk is yet to be determined. As an example, given current disk capacities and prices of 50 Gbytes and $28/Gbyte we would require about 110 disks/year for the full 5.5 Terabytes at a cost of about $160,000 per year for JBOD. We expect disk capacities to continue to increase and prices to continue to drop making it feasible to store all the data on disk by the time MINOS begins data taking, should this be desirable.

Data will be recorded on disk locally at the far detector and transferred over the network to Fermilab/FCC (Feynman Computing Center) for archiving to tape. There will also be data archiving facilities at the far detector. The needs here are modest and the technology will be chosen later. The near detector data will be logged to disk locally at the experimental hall and then transferred to FCC to be archived to tape. The rates are 100 Kbyte/sec and 2.4 Kbyte/sec for the near and far detectors respectively.

ONLINE MONITORING AND CALIBRATION

The current plans are to use the ORACLE database for storing the calibration information. We will require the following resources from Fermilab

1. Four computers for use as database servers at the Soudan mine and Fermilab. There will be one server per site with the third and fourth used as hot spares. They will be either Intel machines running Linux or Sun machines running Solaris, we have not made this choice yet. The amount of disk required is not precisely known but is expected to be small. We expect to use RAID disk for increased reliability. Some type of backup procedures will be required.
2. Use of 25 of the concurrent user licenses available at Fermilab.
3. 100 hours/year of database consulting help from the Fermilab Computing Division

DATA COPYING

The data copying needs are not yet known. The samples for oscillation studies are small and can probably be transferred over the network. Collaborators at overseas institutions such as the UK and Russia may want a complete copy of all the data. In the worst case, if we assume that we need to make 5 copies of the complete sample then this will be 27.5 TB per year which is about 460 tapes assuming an export media such as Exabyte Mammoth and 60 Gbyte cartridges. This is a modest amount (about 3-4 weeks) which should be able to be satisfied by a central tape copy facility.

OFFLINE DATA PROCESSING

The offline processing for both the near and far detectors will be done at Fermilab. A summary of the processing needs is given in Table III. These numbers are based on the existing MINOS code which is in Fortran. The code is currently being re-written using Object Oriented techniques and C++. This may cause some slow down of the code. For the purposes of this document the processing time per event will be given in SpecInt seconds per event (SpecInt sec/event) and the CPU requirements will be given in SpecInt. We are using the SpecInt95 measurements that are available at http://www.spec.org. To calculate the number of CPUs we have used an Intel motherboard SE440BX2 550 MHz Pentium III rated at 22 SpecInt95. In the early stages it will be necessary to reprocess the data as the algorithms are being refined at the same time as new data is being processed. Two complete processing passes through the data are assumed.

Table III Processing needs for near and far detectors

OFFLINE ANALYSIS

We plan to perform physics analysis of the data at Fermilab as well as at other MINOS collaborating institutions.

We expect Fermilab to provide a central machine(s) in FCC with access to a central mass storage system for data that does not fit on permanently on disk. This machine(s) will act as a data server with the data being available via AFS or similar distributed means so that it is accessible to the collaborators offsite and to desktops at Fermilab. This machine(s) will also act as a central location for the MINOS software. We expect that people will make extensive use of desktop computing given the modest size of most of the data samples and the continued growth of disk capacity.

MONTE CARLO GENERATION AND STORAGE

There are two types of Monte Carlo required for MINOS, simulation of neutrino interactions in the detector for oscillation measurements/conventional neutrino physics and simulation of the neutrino beam to understand features of the beam such as beam profiles, flux etc. In both cases the requirements are not precisely known so the numbers here are based on present knowledge. We assume here that we will generate the samples at Fermilab but the possibility may also exist to generate them at collaborating institutions and ship them to Fermilab for storage.

For studies of oscillations we expect to need about 10 times more Monte Carlo events than data for the far detector, this is a negligible amount (220,000 events/year). For the near detector we require that the statistical accuracy should be negligible compared to the statistical accuracy of the far detector data. Hence a sample equal to the near detector data sample will be sufficient (the relevant rate is 0.26 Hz in the central 25 cm radius of the target region). For studies of conventional neutrino physics the Monte Carlo sample needs to be about twice the data sample size as the measurements will be dominated by systematic uncertainties. The current execution time for the simulation is 103 SpecInt sec/event. If we include the reconstruction then it becomes 110 SpecInt sec/event to simulate and reconstruct a physics event. The needs per year are summarized in Table IV. To calculate the number of CPUs we have used an Intel motherboard SE440BX2 550 MHz Pentium III rated at 22 SpecInt95.

Table IV Physics Monte Carlo needs per year

This data will also need to be stored in the central mass storage system at Fermilab and be accessible on the MINOS central analysis machine. The samples for the oscillations studies will be kept permanently on disk (about 500 Gbytes/year).

Currently a single run takes about two CPU weeks on an SGI O200 180 MHz CPU rated at 8 SpecInt95 to obtain sufficient statistics. The data volume produced per run is about 240 Mbytes. It is expected that a factor of 10 times longer runs will be needed for the physics analysis and that a few hundred of these runs will be required. To calculate the number of CPUs we have used an Intel motherboard SE440BX2 550 MHz Pentium III rated at 22 SpecInt95. The needs are summarized in Table V.

Table V Beam Monte Carlo needs per year

About 17 CPUs per year would be required to simulate the approximately 10⁸ events that these 200 runs would produce using the detector simulation.

The overall data volumes and processing needs for MINOS for 5 years of data taking are summarized in Table VI.

Table VI Summary of data volumes and processing needs for 5 years of data taking

SOFTWARE and PERSONNEL RESOURCES

The MINOS experiment has a working Fortran simulation and reconstruction package that is currently being used for detector optimization and physics studies. The decision was made in summer 1999 to replace this system with a new Object Oriented system based on C++. It was felt that, although there is a working Fortran system, the tools it is based on such as ZEBRA and ADAMO would not be supported over the life of the experiment and it would therefore be sensible to make the transition to an OO system.

The software group in MINOS is in the process of specifying what this new system will look like. This means it is hard to make definitive and complete requests for personnel and support. However, we can say some things about this area.

1. The current proposal is to use ROOT as the batch/interactive framework. This is a somewhat more widespread use than intended by the Run II experiments. We will need support from the Fermilab ROOT team to cover this mode of using ROOT.
2. During the requirements phase we would greatly benefit from the expertise of the C++ experts (Jim Kowalkowski and Marc Paterno) in giving us advice. We have already had some informal meetings with them and would like to continue these as their schedule permits.
3. Once we have a clearer picture of what the pieces of the system should look like we will be able to produce a schedule with milestones. This will allow us to specify projects where we would like design/programming help from Computing Division (CD) personnel. It may be appropriate to hire consultants for some tasks.
4. We have not yet decided on a configuration management system. However, SRT/UPS/UPD is a strong contender. Should we choose this we would expect support from CD including responding to bug fixes and requests for additional features.
5. Help on database issues has already been covered in a previous section of this Appendix.
6. We will want to make use of products such as leak checkers (PURIFY) and CASE tools in which case we will require licenses for MINOS on various platforms.
7. MINOS currently has NO plans to use the KAI complier. The intention is to use egcs and native vendor compilers where appropriate. We would therefore require versions of products such as ROOT which were built with these compilers.