Enhancements to the XAL Online Model for J-PARC
Topics in Software Engineering and RMS Envelope
Simulation

Christopher K. AllenLos Alamos National Laboratory
Los Alamos, New Mexico

07.3.7

J-PARC1

Abstract
The XAL accelerator application framework was originally designedwith specific architectural goals which are important to recognize inorder that future upgrades are consistent with these goals.
Consequently software engineering is a very important aspect ofXAL development. I will discuss various topics of software
engineering in general, and with specific regard to the XAL
framework. Also, I will briefly outline the specific enhancements
to the XAL online model made during my sabbatical time at JPARC. Some of this work included adding additional simulation
capabilities to the online model, correcting existing ones, andverification. However, much effort was also devoted towardrefactoring existing code into a more robust and upgradeable
software system consistent with the XAL architecture.

07.3.7

J-PARC2

Outline

07.3.71.

Motivation

2.

Managing Software Development

3.

Engineering “Rules of Thumb”

4.

Accelerators and Software
Engineering

5.

SummaryJ-PARC

3Software Engineering
DefinitionAccording to the IEEE
“The application of a systematic, disciplined, quantifiableapproach to the development, operation, and maintenance ofsoftware: that is, the application of engineering to software.”07.3.7

J-PARC

4

Software Engineering
1. MotivationComplex systems are best implemented with engineering
Would you build a house without blueprints?
 Would you build your house without blueprints?


Since software is intangible (practically invisible) it is more
susceptible to neglect in this area
This is a dangerous trap
 Many shortcomings are easily obfuscated These shortcomings almost always become crises later on

07.3.7

J-PARC5

Software Engineering
1. Motivation

Software Engineering
1. Motivation
The moral of the story is that your going to put your time in1.

Do you want to spend time at the beginning of the project
designing, documenting, and quantifying?
(not so sexy)2.

Or do you want to spend your time at the end putting out
fires?
(even less sexy)07.3.7

J-PARC7

Software Engineering
2. Managing Software Development

Software engineering can make management
nervousThis is understandable, it is relatively newFew metrics to gauge progressDesign phase
No code is being written Typically very longInnovation is hard to manage“I don’t care what it looks like on the inside”
07.3.7

Many unknowns

As long as it works “who cares”
J-PARC

8

Software Engineering
2. Managing Software Development
Let us address each of these issues
 Progress Metrics
 Design phase Innovation
 “Who cares”=>Managing Risk

07.3.7

J-PARC92. Managing Software Development
i. Metrics
Old software progress metrics are almost meaninglessImagine building a house without a design
 “I’ve used 1,000 board-ft of lumber – I’m half finished!

Imagine building a large software system without a design
 “I’ve written 100,000 lines of code – I’m half finished!”

Ironically, old progress metric waslines of code written.

A more meaningful progress metricis tasks completed
 Must identify tasks (engineering)

07.3.7

J-PARC10

2. Managing Software Development
ii. Design

Eight Phases of Development (WWISA)
1.
2.
3.
4.
5.
6.
7.
8.

07.3.7Pre-design – scope, requirements, expectation
Domain analysis – document system behavior
Schematic design – architectural level design
Design development – detailed design
Project documents – construction process detail
Staffing or contracting – personnel, costing, etc.
Construction – software implementation
Post-construction – deployment, maintenance, etc.

J-PARC11

2. Managing Software Development
ii. Design
Note that most effort is devoted toward design, documentation, costing,etc.
 Only about 15-30% of the effort is implementation.
However, it is easy and fast to
implement large blocks of code if
blueprints already exist.
07.3.7(The thinking part is hard)

J-PARC12

2. Managing Software Development
ii. Design

My contention that design has always occupied
most of the effort
 Previously the design and implementation phasewere not separate
 Coding and designing at the same time Leads to a “wandering” style of development
 No meaningful metrics for progress, operation, etc.
 Does not support team development

07.3.7

J-PARC13

2. Managing Software Developmentiii. Innovation
As developers, our jobs are complicated by the ethereal
nature of softwareCounter-example: mechanical engineers can see A bad design
 A flawed prototype
 An implementation “bug”

Electrical engineers were faced with asimilar problem
 Developed circuit diagrams
 Circuit simulators



07.3.7

Software engineers now have similartools
J-PARC14

2. Managing Software Developmentiii. Innovation
Software Engineering Tools
 UML is a formalized language forblueprinting software.
Analogous to circuit diagrams or
mechanical drawings
There are many commercial UML
tools

Design PatternsCommon architectural solutions tocommon engineering tasks
Analogous to amplifiers, DSPs,
A/D converters, etc.

Such tools help us develop an a priori
appreciation for the difficulty of asoftware task
07.3.7

J-PARC

Abstract Factory

Rational Rose15

2. Managing Software Development
IV. “Who cares… as long as it works”

Would you buy the car without having a lookunder the hood?
It works fine now, but wait
until you drive it off the lot…

Proverbial “barbeque under the hood”

07.3.7

J-PARC16

2. Managing Software Development
IV. “Who cares what’s under the hood”

Brittle CodeIt works now and it is quick to write But it breaks often, and a significant
part of development is spent fixing it.
 It is hard to understand It is hard to maintain It is hard to upgrade

07.3.7

It typically requires much more timeand effort in the long term

J-PARC

17

Software Engineering
3. Rules of Thumb What is good software engineering?

Good software engineering and pornography“I can’t define it but I know it when I see it.”07.3.7

J-PARC

18

Software Engineering
3. Rules of Thumb
Design your software as robust as possible

07.3.7

Your entire software life-cycle is affectedby what you do at the design stage

You cannot anticipate everything, butneglect here will certainly cost you
throughout the software lifetime

J-PARC

19

Software Engineering
3. Rules of Thumb
Is your software upgradeable?
 There will always beupgrades!
 Your foundation must be
solid and able toaccommodate the future

07.3.7

J-PARC

20

Software Engineering
3. Rules of Thumb
Recognize the “Death March”
There are ways to survive a death march see E. Yourdon “Death March”
 Planning is essential here Natural tendency is to jump
immediately into implementation


07.3.7

Worst strategy

J-PARC21Software Engineering
3. Rules of Thumb
Spend the time to write clear, concise, documented code

07.3.7

If it is only you on a project, and will only be you, forever, then dowhatever you want, because the rest of us won’t look at it.

However, if the project involves other people, requires production
quality, and expects future modifications and growth, by all means
please heed the principles of software engineering.

J-PARC

22

Software Engineering
3. Rules of ThumbFor example, do you want to deal with this?

A 2004 Winner of the International Obfuscated C Code Contest (IOCCC)(Polynomial Graphing Program)#include <stdio.h>#include <stdlib.h>#include <math.h>#define _#define void
#define case(break,default)#define switch(bool)#define do(if,else)#define true
#define false;doublex,x
break[O]:default[O]:;for(;x<bool;inIine(else)>int##if?
(--void++)(++void--)char*O=" <60>!?\\\n"_ doubIe[010]_ int0,int1 _ Iong=0 _ inIine(int eIse){int
O1O=!O _ l=!O;for(;O1O<010;++O1O)l+=(O1O[doubIe]*pow(eIse,O1O));return l;}intmain(int booI,char*eIse[]){int I=1,x=-*O;if(eIse){for(;I<010+1;I++)I[doubIe-1]=booI>I?atof(I[eIse]):!O switch(*O)x++)abs(inIine(x))>Iong&&(Iong=abs(inIine(x)));int1=Iong;main(-*O>>1,0);}else{if(booI<*O>>1){int0=int1;int1=int0-2*Iong/0[O]switch(5[O]))putchar(x-*O?(int0>=inIine(x)&&do(1,x)do(0,true)do(0,false)
case(2,1)do(1,true)do(0,false)6[O]case(-3,6)do(0,false)6[O]-3[O]:do(1,false)
case(5,4)x?booI?0:6[O]:7[O])+*O:8[O]),x++;main(++booI,0);}}}
07.3.7

J-PARC

23

Software Engineering
3. Rules of Thumb
Do not put code somewhere justbecause it is convenient07.3.7

This is faster in the beginning
but costs a lot of time later



E.G., Don’t run the sewer line
through the heating duct justbecause the hole is alreadythere.

J-PARC

24

Software Engineering
3. Rules of Thumb
Avoid “Over Engineering”
Scale your engineering efforts
to the size of the project
A dog house The White House

“Paralysis by Analysis”


07.3.7

When a clear path is notapparent, you may needinstinct“Sounds better than live?”

J-PARC

25

Software Engineering
3. Rules of Thumb
Knowing when to quitSometimes legacy code canno longer be salvaged

Move away from functional
programming

Stop using FORTRAN

07.3.7

Brittle code

Does not support
engineering

J-PARC

26

Need for Software Engineering
4. Software Engineering and Accelerators
Some of the worst software-bugs which ever occurred:

07.3.7

1985: 6 People died due to radiation overdose in the Therac-25 X-ray therapyapparatus caused by a software bug.

1996: An Ariane 5 spacecraft exploded 36 seconds after take-off. The problem wassoftware originally used in its predecessor, Ariane 4. A directional correction toolarge for the new spacecraft was applied, exceeding aerodynamic tolerances.



1999: The Mars Climate Orbiter incinerated in the Martian atmosphere because
data that was in expressed in English units was entered into software designed formetric units.

The original software in the F-16 fighter jet would have turned the plane upsidedown when it crossed the equator. Fortunately, this problem was detected early via
simulation.

J-PARC27

4. Software Engineering and Accelerators

Accelerators are (arguably?) complex systems
More complicated than cars…
 More complicated than houses…


Then why would not anaccelerator control and/or
simulation code not also becomplex?
07.3.7

It is unreasonable to think thatthe construction of such
systems would not require asignificant engineering effort

J-PARC28

Software Engineering and Accelerators
There is a Need
The newest machines are the most sophisticated ever builtWe need sophisticated software that can analyze and control these machines

07.3.7Highest power
Tightest tolerances
Largest scalesMultiple applications

Software simulations
Not just a bunch of calculations

Put together the model in a logical manner

Feedback control
Modern control

Bottom Line – Need to implement control and simulation software that is Reliability!
 Maintainability!
 Upgradeability!

J-PARC

29

Example: Accelerators and Software Engineering

XAL

A Framework for Portable High-Level
Control of Charged Particle Accelerators

Conceptual (Pre-Design)

30

J-PARC07.3.7

XAL Architecture
Subsystem Diagrams
High-Level Control System forSNS Accelerator«system»
gov::sns«import»«framework»
xal«import»«suite»apps«suite»tools«import»«subsystem»
xal::model«subsystem»
xal::smf

tools::ca«framework»
tools::agent«framework»
tools:: application«facade»Third Party::JCA«uses»«system»Third Party:: EPICS

31J-PARC

07.3.7

XAL Architecture
Class Diagrams

32

J-PARC07.3.7

XAL Architecture
Deployment Diagram«executable»
apps:: High-Level Application«executable»
SNS Start MapControl
ComputerPhysics
ServerConsoleConsoleConsoleXML...
...........
...........
...........

«library»
xal:: xal.jar

Local NetworkIOC

33

IOCIOC

J-PARCIOC

07.3.7

XAL Architecture
Communication Diagrams
Database

Accelerator
sequences + devices

Lattice
Generator

gov.sns.xal.smf

gov.sns.xal.slg

Machine data

External
lattice
generation

Scenario
gov.sns.xal.model.scenario

User tuning

Online Model

Probe:-34

initial conditions
type (single particle,envelope, multiparticle)

J-PARC

gov.sns.xal.model
Trajectory- Twiss
output07.3.7

5. Summary
Accelerators are very complex systems. The operation andsimulation of these complicated and expensive machines rely
upon software, complex software. It is only natural to allocate
a significant part of the software development effort toguarantee that this software is reliable, maintainable, and easily
upgraded. In other words, in the long term, to provide the mostefficient, cost effective, and reliable operating environment for
our accelerator complex, we should ensure that this software isengineered to the best available standards.

07.3.7

J-PARC35

どうもありがとうございます
皆様
この二年間皆さんと一緒に仕事が出来てうれしかったです。日本では貴重な体験をたくさんさせていただきました。このようなすばらしい機会を与えて下さり本当にありがとうございました。

07.3.7

J-PARC36

XAL Architecture
Points to Remember
 XAL Framework Be careful here!
 Do not make modifications just because it makes yourlife more convenient Consequences affect everyone

 Applications
 Architecture and engineering are less important However, if you build a general, well-designed

application, then everyone can use it

07.3.7

J-PARC37

XAL Architecture
Points to Remember The lattice file represents the hardware
 It is not a data file
 Design values only
 Not for machine parameters setting

 Online Model Three independent components
 Element/Algorithm/Probe Architecture Only the Algorithm object knows about Elements

and Probes

07.3.7

J-PARC38

Software Engineering
Rules of Thumb Document your code (Javadoc!) (not sexy)

It is certainly faster for you now to skip documentation
 But much slower for your coworkers later Much slower for you later when you forget what you weredoing

It is also dangerous to skip documentation
 I usually read the instructions before firing up thebulldozer

07.3.7

J-PARC39

Software Engineering
Rules of Thumb New software technology
Don’t use Version 1 products
 “Microsoft: Where quality is number 1.1”

There is always a lot of new software Try to maintain awareness of new technologies and what

they do so that you may learn them and use them whenneeded Before writing new software – Check the Internet
 For Java this is especially true – and easy

07.3.7

J-PARC40

Software Engineering
3. Rules of Thumb Software conventions are typically good –use them!
 Saves much time for the person behind you Why is there always a light switch, inside thedoor, opposite side, at hand level?

07.3.7

J-PARC41

Software Engineering
Rules of Thumb For proof of principle, quick prototyping, etc.,

Matlab, Mathematica, Scripting, etc., are all fine.
 However, when it comes time to build a solid
software system, a high-level language is moreappropriateSupports necessary engineering and architectural
constructs
 Classes, interfaces, components, etc.

Supports maintenance and testing Clarity and documentation


07.3.7

J-PARC42 Management styles


Maintenance Anticipate problems and prepare for them

Crisis intervention
 Respond to crises as the occur and fix them

 Good software engineering favors the former
Design!
 Reliability
 Maintainability
 Upgradeability

07.3.7

J-PARC43

Need for Software Engineering
4. Software Engineering and Accelerators

Some situations are obvious
Many applications require robust, large, and/or complex softwaresystems and, consequently, must be engineeredMedical applications
 AED (automated external defibrillator)
 X-ray equipment

Aerospace Navigation
 Automation



07.3.7

Accelerator control?

J-PARC

44