Presentation is loading. Please wait.

Presentation is loading. Please wait.

Runtime alignment system SOFTWARE DESIGN IDEAS Wed 4 th May 2005 P Coe.

Similar presentations


Presentation on theme: "Runtime alignment system SOFTWARE DESIGN IDEAS Wed 4 th May 2005 P Coe."— Presentation transcript:

1 Runtime alignment system SOFTWARE DESIGN IDEAS Wed 4 th May 2005 P Coe

2 OVERVIEW Why am I giving this talk? Basic purpose of FSI system DESIGN TOPICS Needs addressed by software Dividing up the design/coding job Example interfaces & internal code Recommendations Guesses

3 Why am I giving this talk? I’m often told that people don’t really know (or at least don’t have a clear picture) of what needs to be done, to get the alignment software written. It’s just a sequence of baby steps, working towards some goals. The exact goals you need to agree on as a group. This talk is a guide to that process!

4

5 … we want to make … 842 length measurements Simultaneously inside the SCT! BASIC PURPOSE OF FSI SYSTEM : Barrel SCT End-cap SCT 165 80+(3x[80+16])+(2x72)=512 B3B4,5,6 END FLANGES

6 If you want to know more about FSI Look at Oxford ATLAS documents web page 9 talks, 3 papers and 5 theses

7 Alignment assistance from FSI Provides up date to shape changes info for the SCT Can only do this, if there is some software! FSI info will only be used by the alignment group A)If the basic information provided is intelligible to them B)If they can answer other questions they have (reliability) C)After N days of alignment data, the resident FSI expert on site should be able to answer detailed questions about repeatability, problem measurement lines, fluctuations etc to the satisfaction of the ATLAS community. We need to give them the software tools to do that job.

8 Easy to use front end Maximal flexibility within the time left to write the code What needs can the software be written to address? Information on SCT shape changes Allow shape reconstruction based on different “models” GENERAL USERS ADVANCED USERS All Users Warnings for possibly suspect measurements Reassurances about reference system behaviour Allow detailed inspection of movements of particular nodes

9 Languages Code could concievably be written in : C / C++ Labview Fortran Java Demonstration system code has been written in C faster number crunching for analysis algorithms time critical DAQ Labview Provides some hardware drivers Provides DAQ & Length analysis GUI Fortran F77 copy of MINUIT ported to C for sine fitting Java SIMULGEO grid reconstruction written in Java

10 How does the job naturally divide up? Define Interfaces between code and externals Define Internal tasks software must perform Specify which language each part is to be written in Draw up clear agreement as to who will generate which code Meet regularly to discuss architectural conflicts in design

11 8 Example interfaces RUNTIME ALIGNMENT CODE

12 Document the interface specs! Advantages :- Everyone writing code can see where the goalposts are. All users of the code can see what to expect Testing the code is a lot easier Disadvantages :- People don’t like writing documentation

13 How I would get each interface defined (once list of required interfaces has been agreed) Appoint someone to specify interface They should talk to expert of the relevant external system and gauge expectations They should draft a detailed spec Put draft spec to an Oxford alignment software meeting for comment Publish working spec version 1.0 (i.e. documentation!)

14 Internal task Rough working definition : Chain of smaller jobs connecting between interfaces

15 Internal task : Example (Perform status check) ATLAS RUN CONTROL Perform Status Check Check readiness of all HW Build up status (array of flags) Ref HW Disks Lasers Readout Perform SCAN Timing & Ctrl Report status to ARC & FSI GUI FSI GUI Is system “Ready to scan?” Reset Hardware FSI Scan Interface to external Function call (from External) (from Internal) KEY Internal sub step

16 Recommendations to FSI software group 1.Agree on a list of P people, who are willing to help 2.Divide the HUGE FSI software project into N independent parts 3.Assign people from list, to fact find about each part, to start drafting a sketch definition of what the job would involve. Which interfaces it will talk to What it must do What it must not do Whether or not it is time critical / must be fast / can take 4 years Likely language(s) in which the code will be written 4.Get fact finders to report back to whole group (P) with draft idea of how their part of the software would look in terms of basic design (answers to above - and similar - points) 5.Fine tune draft idea within the whole group and document 6.Once all N parts have such a draft spec : the problem is NP complete

17 My rough guesses Independent parts would be 1.Hardware / DAQ control 2.Length measurement analyses 3.SCT grid shape reconstruction 4.Alignment mapping code Each off-line stage provides some level of validation

18 eg Hardware / DAQ control Talks to ARC, GUIs, all HW Should be safety and timing critical Should provide as much info as poss in realtime about what (on earth) is happening Need to discuss with ARC people, FSI HW experts Needs to be in place by ??? 200?

19 GeT ON WITH IT! SHORT SUMMARY

20 Main Issues NOT the lack of manpower NOT the lack of code But the absence of a clearly agreed working plan Until there is a common, clear agreement about what will be done and by whom, no amount of already compiled code can be considered progress IMHO


Download ppt "Runtime alignment system SOFTWARE DESIGN IDEAS Wed 4 th May 2005 P Coe."

Similar presentations


Ads by Google