Prototype Impedance Database

John Jowett, ABP-RLC meeting 21/11/2006

At the last RLC meeting, I suggested that Mathematica might be a good medium for a new implementation of an impedance database.

It was clear that not everyone is familiar with the idea of implementing databases in Mathematica nor what the advantages might be.

I spent a short time looking at the existing data and looking at the basics of an implementation which I will demonstrate today.

This is NOT a finished product, just a "proof-of-principle".

Nevertheless, I do not think it would be a great deal of work to complete the job.  It could be a project for a Technical Student or even a very good Summer Student.

Of course we still need to enforce social and managerial aspects.

For an impedance database, I believe it is more important to think about the Schema than the relations or the tables.

Requirements

Provide up-to-date impedance and/or wake functions for all elements in the LHC.

Integrity of data related to LHC (layout, optics, occurrences of elements,...).

Many kinds of calculations combining impedances of elements, physical formulas for growth rates, etc.

Contain diverse sorts of data ("formats", unstructured output from various programs like ABCI, URMEL, et al).

Access to data from all platforms, across Internet, from control system, …

Maintain means for updating impedances (input files for programs, book-keeping, convenient interface).

As simple as possible, future-proof.  Minimise dependences on other software.

Use existing data from previous implementation (or change it once and for all to make life a little easier?).

Proposed Model

Impedance data is stored in a file system, readable via the Web.   Can be organized in a hierarchy

{"machine", "element group", "item", "mode"}

which could be implemented as a hierarchy of files as at present.

There can be two kinds of users

Responsible for updating calculations or inserting results provided by others.

Access direct (file system)

Interface is typically a Mathematica notebook.

Responsible for updating calculations or inserting results provided by others.

Access can be via Web.

Interface is typically a Mathematica notebook for a particular application which may contain other kinds of material (impedances may be just one ingredient of what the user is doing).

Unimportant Technicalities

This demonstration is on a laptop without network access so I am using (partial) local copies of the existing Zbase data files and the LHC optics database.

The existing implementation contains a number of compressed (.gz) files with inconsistent file extensions.  I have uncompressed and renamed some of them for this demonstration.

I will not show how to submit batch jobs for impedance calculations.   But this is straightforward from a Mathematica kernel running on, e.g., the lxplus system.

Note that this is a development notebook which contains rather more "code" (trial function definitions etc.) than an eventual application notebook would normally contain.  So there is no need to be put off by this. In Mathematica, correct code is entered with many fewer keystrokes than appear necessary anyway.
A more "graphical" user interface (with buttons, etc.) can also be created.   However full flexibility will be retained with access to the package functions.

Setup

If this is an application notebook, the user would normally just load the package with a single command.

At present the implementation of the functions is in another notebook which has already been evaluated.  As usual, every function should have a usage message (instant documentation).  So far just a few functions have been implemented.

?$Zbase*

?Zbase*

Use local copy of database

$ZbaseDirectory = 
      ToFileName[{"C:", "OfflineAFS", "zbase"}]

ZbaseDataDirectory[] // explorer

Database Contents

Options[Zbase]

ZbaseMachines[]

ZbaseItems[]

ZbaseItems[{"experiments"}]

\(\(\(ZbaseFiles[{"bellows-us", "collimator"}, "long"]\)\(//\)\(TableForm\)\(\ \)\)\)

Contents of the .zbase file

Importing the file as a Table deals with the E-format numbers.

zbase = 
        Import[ToFileName[{ZbaseDataDirectory[], "lhc", "cavities", "\
scavity", "long"}, ".zbase"], "Table"];

zbaseRules = {"COMMENT" -> 
          StringJoin @@ 
            ToString[zbase[[1]]], 
        NumberOfItems -> 
          zbase[[2]], 
        betxav -> zbase[[3]], 
        betyav -> zbase[[4]], 
        Zovern -> zbase[[5]], 
        HOMs -> Drop[zbase, 10]}

Take[HOMs /. zbaseRules, 5]

SpectralListPlot[Drop[HOMs /. zbaseRules, 
            1] /. {f_, rq_, _} -> {f/(10^9), rq},PlotRange -> {{0, Automatic}, {0, 6}},PlotStyle -> Red,AxesLabel->{"f/GHz","R/Q /Ω"}]

SpectralListPlot[Drop[HOMs /. zbaseRules, 
            1] /. {f_, rq_, q_} -> {f, q},PlotRange -> {{0, Automatic}, {0, Automatic}},PlotStyle -> Blue,AxesLabel->{"f/Hz","Q"}]

These operations could be wrapped up as standard functions.

Contents of the .beam file

\(beam = 
      Import[ToFileName[{ZbaseDataDirectory[], "lhc"}, ".beam"], "Table"]\)

We can identify the first 13 of these parameters by comparison with

In Mathematica, we could store the information as a list of rules.  This has the advantage of being self-describing.

Rule @@@ 
      Transpose@{{Machine, Particle, Kbunch, Nbunch, sigzInjection, 
            sigzCollision, gammaInjection, gammaCollision, sige, slipFactor, 
            frev, QsInjection, QsCollision, xx1, xx2}, 
          Flatten[beam]}

ABCI, URMEL, etc. files

I haven't yet implemented anything.

Probably store files used for a given impedance calculation as a list of rules corresponding to the element name.

Try to achieve one-to-many mapping of impedance element types to elements in machine layout (MAD description?).

Plugging in of specific stored parameters in template input files and launching of jobs.  Can facilitate process and keep track of things.

A typical wake

lwak1 = 
      Import["C:\\OfflineAFS\\zbase\\data\\lhc\\cavities\\scavity\\long\\\
wakepot.abci.longx.7.5e-2.dat"]

rawPlot = 
      ListPlot[Drop[lwak1, 5], PlotStyle -> Red, 
        PlotJoined -> True]

A moving average only takes us so far ...

DisplayTogether[rawPlot, 
      ListPlot[MovingAverage[Drop[lwak1, 5], 100], 
        PlotJoined -> True]
]

A moving median with repated smoothing is a bit better perhaps

DisplayTogether[rawPlot, 
      ListPlot[MovingMedian[Drop[lwak1, 5], 91, 
          RepeatedSmoothing -> True], 
        PlotJoined -> True]
]

Analytical models

Natural implementation as Mathematica expressions.

Rules to plug in particular parameter values in generic expressions.

Elements and how they occur in the LHC rings

The previous implementation contained information about the occurrences of the impedances in the ring.  In principle, each element with an impedance should appear in the MAD description of the LHC.    Therefore we should be able to use this as the basic source of information about the occurrences and not duplicate the information in the impedance database.   The Madtomma interface to the LHC has already been loaded so we have direct access to the information via its functions.

This is somewhat LHC-specific of course but similar things could be done for other machines.

Example of the LHC RF cavities

Get the optics at the RF cavities:

RFcavityOptics = 
        mfsMember[
          LHCtwiss["LHCB1"], "KEYWORD", {"RFCAVITY"}];

A simple table of interesting quantities

With[{cols = {"NAME", "S", "L", "BETX", "BETY"}}, 
      TableForm[Transpose[mfsColumn[RFcavityOptics, cols]], 
        TableHeadings -> {{}, cols}]]

These cavities belong to classes, the members of which should have the same impedances.   Madtomma has a function that can tell us what they are.

?LHCElementParent

So we can get the list of parent classes of each RF cavity.   The first call of this function builds a database and caches it so future calls will be much faster.

LHCElementParent /@ mfsColumn[RFcavityOptics, "NAME"]

The list of different RF cavity types

Union[
      LHCElementParent /@ mfsColumn[RFcavityOptics, "NAME"]]

Now we can count the number of occurrences of each type

?Frequencies

Frequencies[LHCElementParent /@ mfsColumn[RFcavityOptics, "NAME"]] // 
      TableForm

If we knew the impedance or wake for each type of cavity, it would now be easy to sum up the contributions using these occurrence counts as weights.

Logically now, one would expect the list of impedance element classe to be a superset of  the bottom level of ZbaseItems[].  This should be arranged, I think.

Optics information for impedance calculations

We can also easily do things like calculate the average beta at each element class.  Get a table of cavity names, lengths and (Subscript[β, y]) values, then select just the cavities belonging to a particular class.

\(With[{elclass = "ACSCA"}, 
      eldata = Select[
          Transpose[
            mfsColumn[RFcavityOptics, {"NAME", "L", "BETY"}]], 
          LHCElementParent[First[#]] == 
              elclass &]; 
Total[eldata /. {_, l_, b_} -> l\ b]\/Total[eldata /. {_, l_, b_} -> l]
]\)

It's easy to generalise that

\(\(LHCElementClassAverage::usage = "LHCElementClassAverage[seq,elclass,func] returns the length-weighted average of the optical function func (e.g. "BETX") over the elements of an LHC sequence belonging to the element class elclass.";\)\)

\(LHCElementClassAverage[seq_?LHCsequenceQ, elclass_String, func_String] := 
      Module[{eldata}, 
eldata = 
          Select[Transpose[
              mfsColumn[LHCtwiss[seq], {"NAME", "L", func}]], 
            LHCElementParent[First[#]] == 
                elclass &]; 
Total[eldata /. {_, l_, b_} -> l\ b]\/Total[eldata /. {_, l_, b_} -> l]
]\)

It would not be hard to implement expressions like ("BETX"-"BETY")/"DX" instead of simple strings for func using mfsToRules.

Check the previous result

LHCElementClassAverage["LHCB1", "ACSCA", "BETY"]

And get some more

LHCElementClassAverage["LHCB1", "MQM", "BETX"]

The caching of the element hierarchy in Mathematica makes these calculations quite fast enough.

LHCElementClassAverage["LHCB1", "MB", "BETX"]

LHCElementClassAverage["LHCB2", "MB", "BETX"]

Actually these are only the averages of the values at the exits of the elements.   Probably good enough for instability estimates.  But we could improve ...

Conclusions

I have sketched how one might go about implementing an impedance database in Mathematica.  In my opinion, the advantages would be:

Natural implementation of impedances which are mathematical functions (sometimes analytical, sometimes numerical, ...).

Reduced total amount of code-writing and dependences.   Functionality closer to physics.

Based on high quality supported product with no risk of obsolescence.  Nothing to compile.

Familiar environment for many people (but counter-examples exist).

Mathematica's Interpolation function allows wakes or impedances given as numerical tables (at discrete points) to be treated as functions defined continuously.  So all analytical operations (combination with other expressions, differentiation, etc.) become possible with them.

Possibility to use existing data structures as-is or to implement new flexible ones (replace fixed format text files with self-describing expressions, rules)  and liberate oneself from consideration of data formats.

Quite straightforward to store input and output files for numerical impedance programs (ABCI, URMEL etc.).   Template inputs can have values spliced into them for automatic job submission and tracking on appropriate operating system.

No need to store optics information in the impedance database as direct access to official LHC optics is provided via Madtomma and can be combined with impedance information in any way desired.

Direct access via JDBC to all standard databases (or anything that can be found on the Web) for any further information that is needed.

Direct linking to any Java application (control system, etc.)

Easy to provide read access to the impedance database via the Web.