Runtime alignment system

SOFTWARE DESIGN IDEAS

Wed 4th May 2005 P Coe

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

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!

Frequency Scanning Interferometry

The basic principleThe basic principle

Laser

I REF

REFERENCE INTERFEROMETER

I

INTERFEROMETERTO BE MEASURED

… we want to make …

842 length measurementsSimultaneously inside the SCT!

BASIC PURPOSE OF FSI SYSTEM :

Barrel SCTEnd-cap SCT

End-cap SCT

165

165

80+(3x[80+16])+(2x72)=512

B3 B4,5,6END FLANGES

If you want to know more about FSI• Look at Oxford ATLAS documents web page

9 talks, 3 papers and 5 theses

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 themB) 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.

• 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”

GENERALUSERS

ADVANCEDUSERS

All Users

• Warnings for possibly suspect measurements

• Reassurances about reference system behaviour

• Allow detailed inspection of movements of particular nodes

LanguagesCode 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

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

AT L A SRU N C T R L

DATADIS K

GE N E R A LU S E R

A DVA N C E DU S E R

F S I T IM IN G& CT R L

R E F H W

8 Example interfaces

RUNTIMEALIGNMENT

CODE

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

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!)

Internal task

Rough working definition :

Chain of smaller jobs connecting between interfaces

Internal task : Example (Perform status check)

ATLAS RUNCONTROL

Perform Status Check

Check readiness of all HW

Build up status (array of flags)

Ref HW

Disks

Lasers

Readout

Perform SCAN

Timing & Ctrl

Report statusto ARC & FSI GUI

FSI GUI

Is system

“Ready to scan?”

ResetHardware

FSI Scan

Interface to external

Function call (from External)(from Internal)

KEY

Internal sub step

Recommendations to FSI software group

1. Agree on a list of P people, who are willing to help2. Divide the HUGE FSI software project into N independent

parts3. 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

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

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?

GeT ON WITH IT!

SHORT SUMMARY

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