Project Initiation Documentmice · Web viewOn the MC simulation side one wants to construct the idealized geometry, track N particles, look at the amount of energy deposited in

SSI/MAUS – Project Initiation Document

Project Title SSI/MAUSDocument Title SSI/MAUS – Project Initiation DocumentAuthorship Rob Baxter;Chris Rogers;Chris Tunnell;Mike Jackson

Document Filename document.docxDocument Version 1.0Document Number

Distribution Classification PublicDistribution List Project Management Board; Project Team

Approval List Project Management Board

COPYRIGHT © 2010-2011 THE UNIVERSITY OF EDINBURGH AND OTHERS WITHIN THE SSI CONSORTIUM

Document HistoryPersonnel Date Comment VersionMJ 06/12/11 Public 1.0

SSI/MAUS PROJECT INITIATION DOCUMENT V1.0 PUBLIC

Contents

Purpose of this Document............................................................................................................ 51 Project Definition..................................................................................................................... 5

1.1 Background....................................................................................................................................... 51.2 Objectives.......................................................................................................................................... 51.3 Scope................................................................................................................................................... 6

1.3.1 Effort............................................................................................................................................ 61.3.2 Timescales................................................................................................................................. 6

1.4 Exclusions, constraints, assumptions......................................................................................61.4.1 Exclusions.................................................................................................................................. 61.4.2 Constraints................................................................................................................................ 61.4.3 Assumptions............................................................................................................................. 6

1.5 Users and stakeholders................................................................................................................ 6

2 Business Case............................................................................................................................ 82.1 Benefits to the customer...............................................................................................................82.2 Benefits to SSI................................................................................................................................... 8

3 Project approach...................................................................................................................... 93.1 SSI staff skills required................................................................................................................. 93.2 SSI computing and admin resources required......................................................................9

4 Project Team........................................................................................................................... 104.1 Project Board................................................................................................................................. 10

4.1.1 Executive................................................................................................................................. 104.1.2 Senior User............................................................................................................................. 104.1.3 Senior Supplier......................................................................................................................10

4.2 SSI project team............................................................................................................................ 104.2.1 Project Manager.................................................................................................................... 104.2.2 Technical Staff....................................................................................................................... 10

4.3 MAUS project team.......................................................................................................................10

5 Quality Management Strategy........................................................................................... 115.1 Quality responsibilities.............................................................................................................. 115.2 Customer’s quality expectations.............................................................................................115.3 Project standards......................................................................................................................... 115.4 Software testing............................................................................................................................ 11

6 Configuration Management Strategy..............................................................................126.1 Change control and issue management................................................................................12

6.1.1 Change, issue and bug tracking system.........................................................................126.2 Document configuration and storage....................................................................................126.3 Source code configuration and storage................................................................................126.4 Data configuration and storage...............................................................................................126.5 IP and source code ownership issues....................................................................................12

7 Risk Management Strategy................................................................................................. 137.1 Risk management process.........................................................................................................13

PROJECT DEFINITION 3


7.2 Risk and issues log....................................................................................................................... 137.2.1 Risk log..................................................................................................................................... 137.2.2 Issue log................................................................................................................................... 14

8 Communication Management Strategy..........................................................................158.1 Stakeholder communication.................................................................................................... 15

8.1.1 SSI management – Development Manager...................................................................158.2 Outreach and dissemination strategy...................................................................................15

8.2.1 Acknowledging SSI in publications.................................................................................15

9 Project Controls..................................................................................................................... 169.1 Project stages................................................................................................................................. 169.2 Project tolerances........................................................................................................................ 169.3 Project reporting.......................................................................................................................... 16

9.3.1 Highlight reports.................................................................................................................. 169.3.2 End project report................................................................................................................ 16

9.4 Project meetings........................................................................................................................... 169.4.1 Project meetings................................................................................................................... 16

10 Project Plan.......................................................................................................................... 1710.1 Management Products............................................................................................................1710.2 Technical Products.................................................................................................................. 1710.3 Timescales and milestones...................................................................................................1710.4 Planning prerequisites, dependencies, assumptions..................................................18

10.4.1 Prerequisites...................................................................................................................... 1810.4.2 External dependencies................................................................................................... 1810.4.3 Assumptions....................................................................................................................... 18



Purpose of this DocumentThis is the project definition for a collaborative project between SSI and MAUS. It defines the what, why, how, who and when for the project.

1 Project DefinitionThis section defines the key features of the SSI/MAUS project.

1.1 BackgroundMAUS1 (MICE Analysis User Software) is a software project used by MICE2 (Muon Ionization Cooling Experiment), a UK-based international collaboration of particle and accelerator physicists based at Rutherford-Appleton Lab. This collaboration of 100 or so researchers is building a prototype of part of a neutrino factory. The neutrino factory is currently in the design report phase and could potentially be a multi-billion GBP facility. MAUS is a modular data analysis package designed to provide a framework in which various MICE software functionality can communicate.

There are two workflows in MAUS: Monte Carlo simulation and data analysis. One wants to be able to simulate and represent the geometry and physics processes of the experiment to get an accurate physics result. The MC simulation is in essence the theoretical model: it allows many integrals to be done by tracking particles that would be impossible by hand. Ideally, one wants the MC simulation and data analysis workflow to converge as early on in a dataflow as possible.

On the MC simulation side one wants to construct the idealized geometry, track N particles, look at the amount of energy deposited in detectors (the only way we know about small particles is by how they lose energy in materials), simulate the electronics response (sometimes just multiplying by a number to convert units), then create a space-point that says an event was here at this x,y,z position and this time. Lastly, complex algorithms can be applied to try to fit the tracks and paths of these particles since their properties are fairly well understood due to 60 years of studies.

On the data analysis side, the latter steps of creating space-points and applying fit algorithms are the same. However, the earlier steps differ and include: parsing the data acquisition (DAQ) binary format, applying a calibration, and fitting a pulse-shape.

The MAUS infrastructure cannot be changed without consideration of the impact of any changes.

One complication is that particle physics software generally grows in complexity as O(log(N_channels)) since there is a lot of hierarchy. MAUS has an additional problem in that the code complexity grows as O(N) since there are about 5-8 detectors and per detector, all the code up to the calculation of space-points is different.

1.2 Objectives‘Online data quality’ is a standard requirement for particle physics experiment software as there is a need to be able to assess the quality of the data being taken in real time. This is in contrast to ‘offline data quality’ where researchers analyze the data on their home machines. Data is analysed in the form of plots and there are three use cases for looking at data plots:

Live in the control room. This can allow faults to be detected immediately and also for hardware to be tuned.

At the end of a week, to assess what runs were good for that week. Offline at home when a researcher is trying to write a paper.

1 See http://micewww.pp.rl.ac.uk/projects/maus/wiki 2 See http://mice.iit.edu/


http://mice.iit.edu/

http://micewww.pp.rl.ac.uk/projects/maus/wiki


The primary objective of this collaboration between SSI and MAUS is to complete this ‘online data quality’ or ‘online reconstruction’ component of the MAUS system. More generally, MAUS are interested in improving their awareness of general software sustainability-related issues and concepts, from both a project management and software development perspective.

1.3 ScopeThere are four subcomponents that need to developed to support these use cases.

Data flow: Code runs in two passes, a map pass and a reduce pass. The intermediate state is a Python buffer object which holds the data in-memory until it fills, upon which it is written as a temporary file to disk. This should be upgraded to store data in a database to support multiple IO requests and large data sizes.

Histogramming: Detector performance can be monitored by making histograms of certain elements in the data structure. This component must access the data structure and add certain user-defined elements into 1D or 2D histograms. There is a requirement to use PyROOT/ROOT for histogramming. Support for gnuplot and Python’s matplotlib would be useful and greatly simplify the plotting code.

UI: The generated histograms must be visible from within the control room and should be visible externally, perhaps through a browser-based interface. Data processing takes ~1 minute so the UI should update every 10-30 seconds. There may be a requirement to use the Django Python-based web application framework for the interface.

Distributed computing: The code that manipulates the data (e.g. pattern recognition, etc.) is potentially not efficient enough to be handled by a single core. The cheapest way to fix this problem is to use a distributed task queue and distribute map passes over several cores, making the overall code more extensible and re-usable. A fall back, though possibly undesirable, is to improve performance by cutting out some of the reconstruction code. Another is to sample a subset of the data for the live plots (the original unsampled data is retained for use in publications).

1.3.1 EffortThe initial budget for this work is 4 staff-months from an SSI analyst/developer and appropriate support from the MAUS project leads.

1.3.2 TimescalesThis project will begin 01/09/11 and run for 6 months in duration.

1.4 Exclusions, constraints, assumptions1.4.1 ExclusionsThe following items are specifically ruled out of the project scope:

E1 Work on components outwith those cited in section 1.3, except where such work is necessary for those components cited.

1.4.2 ConstraintsThe project must operate within the following constraints:

C1 The cut-off date for the project is February/March 2012 as a detector is expected to arrive then.

C2 It is planned that MAUS be stable by the end of 2011 so work in 2012 can focus on hardening and polishing MAUS and making it sustainable.

1.4.3 AssumptionsThis project makes the following assumptions:

A1 One SSI analyst/developer will work on this project 70%.



1.5 Users and stakeholdersThe project’s stakeholders are jointly SSI and MAUS.

The users of MAUS are particle physicists on the MICE project. For the duration of this project, users will be represented by the SSI/MAUS project team or other physicists identified by the MAUS team members.



2 Business Case

2.1 Benefits to the customerThe project will contribute to stabilising the MAUS codebase at a critical point in its development cycle. Successful completion will enable the MAUS team to get back on track against the overall MICE project timeline.

MAUS will also gain an increased awareness of issues relating to software sustainability and maintainable software from both project management and software development perspectives.

2.2 Benefits to SSIThis project associates SSI with a large international physics collaboration involving scientists from Europe, the US and Japan. The project links SSI into a new community based around STFC RAL, is potentially high profile, and gives SSI the opportunity to engage with a software project at an earlier, perhaps critical, stage of development than SSI has done previously.



3 Project approachThe SSI analyst/developer will liaise closely with Christopher Tunnell of MAUS.

An agile-style approach will be adopted consisting of the undertaking of well-defined tasks resulting in the delivery of software, reports, components or other concrete outputs.

The SSI analyst/developer will initially familiarise themself with the MAUS software and open source project infrastructure. As part of this, an SSI software evaluation will be undertaken to assess the ease with which a new developer can understand the MAUS software and the organisation of the project that develops it.

The SSI analyst/developer will then undertake the development tasks using rapid prototyping. These tasks will be defined to be short-duration and result in modular components, which will be extended or refactored in subsequent tasks. As MAUS is an evolving system, components developed will be insulated from changes in the system via agreed interfaces and data formats.

MAUS software development infrastructure (e.g. issue tracker, wiki, repository, test framework), and coding and testing procedures will be adopted.

3.1 SSI staff skills requiredExperience with Python is essential. Other technologies which may be used in the project include Python matplotlib, PyROOT, C++, GoogleTests, Django, CouchDB, and the asynchronous task queue, Celery.

3.2 SSI computing and admin resources requiredNo specific requirements are identified though project-specific virtual machines at EPCC will be useful.



4 Project TeamThis section defines the teams and roles involved in the project and assigns these roles to individuals.

4.1 Project BoardThe Project Board provides overall direction and management of the project. The Project Board approves all major plans and authorises any major deviation from agreed Stage Plans. The Board signs off the completion of each project stage and authorises the start of the next stage. The Board ensures that the required resources are committed and arbitrates on any conflicts within the project, or negotiates a solution to any problems between the project and external bodies.

The SSI/MAUS Project Board has an Executive, a Senior User and a Senior Supplier.

4.1.1 ExecutiveThe Executive represents the interests of the Customer (the MICE Experiment). The Executive is ultimately responsible for the project, supported by the Senior User and Senior Supplier.

The Executive is Chris Rogers ([email protected]).

4.1.2 Senior UserThe Senior User is responsible for the specification of the needs of those who will use the final products and for user liaison with the project team.

The Senior User is Christopher Tunnell ([email protected]).

4.1.3 Senior SupplierThe Senior Supplier represents the interests of SSI as ultimate suppliers of the project’s products. The Senior Supplier has the authority to commit or acquire supplier resources and to handle any issues escalated by the Project Manager.

The Senior Supplier is SSI Development Manager, Dr Rob Baxter ([email protected]).

4.2 SSI project team4.2.1 Project ManagerThe Project Manager has the authority to run the project on a day-to-day basis on behalf of the Project Board and within the constraints laid down by the Board. The Project Manager reports to, and takes direction from, the Project Board.

The Project Manager is Dr Mike Jackson ([email protected]).

4.2.2 Technical StaffThe prime responsibility of the Technical Staff is to ensure production of those products defined by the Project Manager to an appropriate quality, in a timescale and cost acceptable to the Project Board. The Technical Staff report to, and take direction from, the Project Manager.

The Technical Staff is Dr Mike Jackson ([email protected]).

4.3 MAUS project teamLinda Coney ([email protected]) is a non-programmer responsible for most of the people who'll be using MAUS tools and is essentially in charge of running the experiment.

There are various users of the software who will want to write their own plotting macros to be run automatically. Contact can be arranged if required.


mailto:[email protected]







5 Quality Management StrategyThis section defines the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during the project.

5.1 Quality responsibilitiesThe Project Manager has specific quality responsibilities for all project technical deliverables.

The Senior Supplier has overall quality responsibility for all work carried out by SSI technical staff on the project.

The Senior User will assess whether the work satisfies the quality expectations listed below.

5.2 Customer’s quality expectationsMAUS expect that any code developed by SSI will be structured, commented and with sufficient supporting documentation that they will be able to understand it and how to modify or extend it with minimal consultation with the SSI analyst/developers after the end of the project.

Code developed by SSI must not break any existing MAUS tests

MAUS would like SSI’s code to be reviewed and for SSI to review code from others. This would be maximum and conservatively for a few hours a week.

5.3 Project standardsCode must follow MAUS standards at http://micewww.pp.rl.ac.uk/projects/maus/wiki/CodingStandards and http://micewww.pp.rl.ac.uk/projects/maus/wiki/Coding_style.

A test exists that checks for conformance to project standards and styles.

Code must be commented using Doxygen notation.

5.4 Software testingMAUS has an existing suite of tests.

Any code must be supported by unit tests (http://micewww.pp.rl.ac.uk/projects/maus/wiki/Unit_tests) and support >90% test coverage. Tests must also validate outputs.

For Python, tests are written using Python’s “unittest” unit testing framework package.

For C++, tests are written using GoogleTest, Google’s open source C++ testing framework.

For GUI elements, there must be associated scripts to allow for manual testing of these elements to be done in a comprehensive and repeatable way.

For each run, output plots must be bundled with the main data structure. These are then put onto the grid automatically.


http://micewww.pp.rl.ac.uk/projects/maus/wiki/Unit_tests

http://micewww.pp.rl.ac.uk/projects/maus/wiki/Coding_style

http://micewww.pp.rl.ac.uk/projects/maus/wiki/CodingStandards


6 Configuration Management StrategyThis section describes the approach to managing configuration changes, and storing and tracking project products, including documents, software source code, critical data etc.

6.1 Change control and issue managementAll possible project changes are handled using the same change control procedure based on the concept of a Project Issue. A Project Issue is the formal way into a project of any inquiry, complaint or request.

Project Issues may be raised inside or outside the Project Team through a written request to the Project Manager. We classify Project Issues as: requests for change (RFC); off-specifications (off-specs), typically software defects or bugs; problem/concern – any other queries, suggestions etc.

The Project Manager will review open Issues weekly or as they arise. Issues that are likely to push the current project stage outside its tolerances, or RFCs or off-specs against already signed-off project products must be flagged with the Project Board.

6.1.1 Change, issue and bug tracking systemThe project will use the existing MAUS issue tracker at http://micewww.pp.rl.ac.uk/projects/maus/issues.

6.2 Document configuration and storageProject documents (including this one) will be managed on the existing MAUS repository at http://micewww.pp.rl.ac.uk/projects/maus/repository/show/doc.

Evolving documents (e.g. the project work plan, risks and issues logs) will be managed on the existing MAUS wiki at http://micewww.pp.rl.ac.uk/projects/maus/wiki.

6.3 Source code configuration and storageProject source code will be developed as part of the overall MAUS project and stored in the existing MAUS repository at http://micewww.pp.rl.ac.uk/projects/maus/repository.

6.4 Data configuration and storageStoring example outputs under version control would be useful.

6.5 IP and source code ownership issuesMAUS is not a legal entity so copyright of code produced by SSI will be copyright The University of Edinburgh. In accordance with MAUS project code contribution requirements, this code will be licenced under GPL.


http://micewww.pp.rl.ac.uk/projects/maus/repository

http://micewww.pp.rl.ac.uk/projects/maus/wiki

http://micewww.pp.rl.ac.uk/projects/maus/repository/show/doc

http://micewww.pp.rl.ac.uk/projects/maus/issues


7 Risk Management StrategyRisk assessment will follow the standard procedures used within SSI development projects. Identification, documentation of and planning for significant project risks is the responsibility of the Project Manager.

7.1 Risk management processAll risks are assessed in terms of likelihood and potential impact. The product of these factors produces a risk exposure factor which should be used to prioritise risks for management control.

Likelihood is a probability measure, and we adopt the following qualitative terms for readability:

low: probability of 10% or less;

medium: probability of 11-30%;

high: probability of 31-60%;

very high: probability of 61-95%;

certain: probability of 96%+.

Impact should be quantified wherever possible in terms of a cost in effort, money or other key metric. Where this is difficult, the following qualitative descriptions can be used:

low: less than 10% project cost;

moderate: up to 20% project cost;

severe: up to 50% project cost;

critical: greater than 50% project cost.

For assessing risk exposure for risks with quantified Impact, E = L I.

For assessing risk exposure for qualitative risks (and for qualifying the numbers from quantified risks), we use the diagram below. Note that a risk with a high probability of becoming an issue still only has a medium exposure if the impact is low – a high chance of a hiccup is less important than a low chance of a disaster.

A summary of all current risks is recorded in tabular form ordered by risk exposure, highest first, and a “top ten” approach to active management will be adopted to ensure the right focus of management attention. Risk descriptions must include plans to control each risk (so they have less chance of

happening, or have less impact if they do), and a note of what contingency has been agreed should the risk become an issue. A risk’s owner is the person expected to track the risk and implement the control and contingency plans as required.

7.2 Risk and issues logThe initial project risks and issues are as follows.

7.2.1 Risk logID Description (including control and contingency plans) Owner L I ER1 SSI personnel need extra time to learn unfamiliar software tools or

environment.

Control: accept.

Contingency: will require additional support from existing MAUS team

MJJ M M L



members.

R2 Project is more complex than first estimated.

Control: accept. Ensure components are as modular as far as possible; address functionality incrementally.

Contingency: apply triage to later, less critical functions.

MJJ M H H

R3 Dependency on technology still under development.

Control: accept. Insulate development of the project’s components as far as possible through agreement on interfaces and data formats.

Contingency: Pause development and review impact of changes across system rather than make piecemeal adjustments.

MJJ H M M

R4 Changes in MICE requirements affect MAUS.

Control: accept. Combine modular design and an agile approach to requirements.

Contingency: Pause development and review impact of changes across system rather than make piecemeal adjustments.

MJJ M M L

R5 SSI analyst/developer becomes unavailable through illness.

Control: accept. Ensure that current progress and current outputs (software, documents) are regularly committed to the repository and current status of work is regularly updated on the wiki.

Contingency: SSI development manager to identify another SSI Analyst/Developer.

MJJ L M L

R6 SSI analyst/developer has increased commitments from other projects.

Control: reduce. Keep aware of project commitments and ensure that any increased commitments from other projects are temporary. Raise concerns with EPCC management.

Contingency: Negotiate with other projects’ leaders for time. Worst-case – SSI development manager to identify another SSI Analyst/Developer.

MJJ L M L

7.2.2 Issue logNo issues have been identified at the outset.

ID

Description (including proposed action) Owner Status(Open or Closed)



8 Communication Management StrategyThis section lists all stakeholders in the project and notes what levels, means and frequency of communication each of them expect or require. It also covers any particular requirements for dissemination or travel during the project. It does not address communication within the project itself – this is dealt with in Section 9, Project Controls.

8.1 Stakeholder communicationThe following organisations, groups or individuals have an interest in the SSI/MAUS project:

1. SSI management – Development Manager.

For each of these we define a communication plan below.

8.1.1 SSI management – Development ManagerFrom: Project Manager.

To: Development Manager.

Frequency: Weekly, via SSI Development meeting.

Form: Verbal report; written checkpoint summary.

Content: An update on project status, highlighting any significant escalated issues.

8.2 Outreach and dissemination strategySSI will publicise this project on their website, blog, Twitter, as appropriate.

It may also be promoted via EPCC in an EPCC News article.

SSI would like to publish any reviews of MAUS infrastructure or software on its web site as this allows SSI to demonstrate to others the services it can deliver. This would only be done with the agreement of the Executive.

8.2.1 Acknowledging SSI in publicationsSSI understands that MAUS/MICE have a formal process for introducing new names as co-authors on papers, and that in normal circumstances adding SSI co-authors for publications deriving from this project will not be possible. Instead, in publications where the outcomes of this project might be considered to have had a significant impact, assistance from SSI should be noted in an Acknowledgments section as follows:

“We would like to acknowledge the assistance of the Software Sustainability Institute. The work carried out by the SSI is supported by EPSRC through grant EP/H043160/1.”



9 Project Controls

9.1 Project stagesThe SSI/MAUS project runs as a single stage of 6 months duration.

9.2 Project tolerancesEach stage of the SSI/MAUS project will have a tolerance of 10% on its assigned budget and timescale. Projected deviations outside these tolerances must be raised as an issue with the Project Board.

9.3 Project reporting9.3.1 Highlight reportsFrom: Project Manager

To: Christopher Tunnell, Chris Rogers

Frequency: Weeklyand fortnightly.

Form: Weekly MAUS ticket update. Fortnightly as part of MAUS project telcon.

Content: Short highlight report noting significant project progress, new or recurring issues, major risk changes.

9.3.2 End project reportFrom: Project Manager.

To: Project Board

Frequency: End of project.

Form: Report.

Content: A report on project status, recent achievements and future plans.

9.4 Project meetings9.4.1 Project meetingsWho: Project Manager, Project Team.

Where: As necessary; telcon/Skype is acceptable.

When: As necessary.

Purpose: Review of project progress, status, issues, technical details.



10 Project PlanThis section describes the high-level work plan for the SSI/MAUS project. Product-based planning is used.

10.1 Management ProductsProduct Description Who Quality measure EstimatePID This document. Defines the why, what,

who, when and how for the project.MJ Project Management

Board approval3d

Post-project review

Summarise progress, achievements and experiences of the project.

MJ Project Management Board approval

3d

10.2 Technical ProductsProduct Description Who Quality measure EstimateSoftware evaluation report

Criteria-based assessment and tutorial-based evaluation of the MAUS software and infrastructure done using the SSI software evaluation service process. Purpose: provide information on the sustainability of their software and how easy it is for a new developer to get started with MAUS.

MJ Senior User approval 10d

Matplotlib histogram reducer

Reduce worker that uses matplotlib to create histograms, with associated tests

MJ Senior User approval (via code review)

5d

Web-based histogram presenter

Simple web server-based component to display histograms for demo purposes. Can be just a PHP script to list image files in a directory.

MJ Senior User approval 3d

Distributed task queue

Component to take inputs and spawn threads, or new processes, to execute chains of map workers. Based on Celery – Python distributed task queue.


20d

Data cache Component to cache results output by chains of map workers until they’re ready for consumption by reducers. Based on CouchDB.


20d

Web interface Web interface for live presentation of histograms and status information on worker execution.


10d

PyROOT histogram reducer

Reduce worker that uses PyROOT to create histograms.


5d

Sustainable components

Refactored versions of all components, bug fixed, polished, and made sustainable.


Time remaining

All the components can be developed stand-alone and none blocks the others, with the exception of the final task.



10.3 Timescales and milestones

Key project dates at present are:

24/10/11 MAUS project meeting, FermiLab, to review current status. 15/11/11 MAUS is run in MICE control room to identify and resolve issues running live. 08-11/02/12 MICE project meeting, RAL. 28/02/12 Delivery of stable, sustainable version of MAUS. 21-25/05/12 CHEP 2012 conference, New York.

Proposed deliverable dates for components, based on MJ’s current availabilities, and above estimates, are:

WB Products Delivery Dates19/09 Software evaluation report

Matplotlib histogram reducer23/09

26/09 Matplotlib histogram reducer 30/0903/10 Web-based histogram presenter 07/1010/10 Distributed task queue17/10 Distributed task queue24/10 Unavailable31/10 Unavailable07/11 Distributed task queue14/11 Distributed task queue 18/1121/11 Data cache28/11 Data cache05/12 Data cache12/12 Data cache 16/1219/12 Web interface26/12 Unavailable02/01 Web interface 06/0109/01 PyROOT histogram reducer 13/0116/01 Sustainable components23/01 Sustainable components30/01 Sustainable components02/02 Sustainable components09/02 Sustainable components16/02 Sustainable components23/02 Sustainable components 28/02

10.4 Planning prerequisites, dependencies, assumptions 10.4.1 PrerequisitesWe note the following prerequisites for this plan. Without the following the work described here cannot begin:



Access to the MAUS repository, code, documentation and wiki.

10.4.2 External dependenciesThis plan is dependent on the delivery or availability of the following items over which the Project Team has no control or influence. Failure of one or more of these external dependencies may jeopardise the project.

The cut-off date for the project depends on detectors and magnets being delivered to RAL.

As MAUS is a service project for MICE, problems affecting the MICE project as a whole (e.g. cancellation) would directly affect MAUS.

Input from Linda is required to refine the presentation of the histograms on the web interface.

10.4.3 AssumptionsIn addition to the items noted above, we make the following assumptions:

Mike Jackson will work 70% on the project. The end date of this project is scheduled to be 28/02/2012.


Documents

Project Initiation Documentmice · Web viewOn the MC simulation side one wants to construct the idealized geometry, track N particles, look at the amount of energy deposited in