Page History

...

1. Wiki Markup
   From lclshome -> User Dev Displays panel. !image:lclshomeUserDev.jpg|thumbnail!

2. Wiki Markup

   Run one of the matlab scripts xalRunModel or xalGetModel !image:userDevPnl.jpg|thumbnail! *xalRunModel* simply runs the model and creates the upload files *xalGetModel* is as xalRunModel, but additionally returns ("gets") the model data to your matlab session. It also creates model plots. Either of these buttons will start the corresponding matlab script... !xalGetModel.jpg|thumbnail! ... which immediately prompt for you to *Select a beamline*: !image:selectabeamline.jpg|thumbnail! \\ The following is a run-through of running xalGetModel for the Extant machine. [Click here to see the full transcript of this example|^xalGetModelRun.jpg]. The procedure is as follows:

   1. For example, select "Cathode to Dump" (as shown in the example belowabove). (as shown in the example below). This runs the LCLS "Full Machine" model, from the LCLS Cathode to the main Dump. See Why are all models from Cathode to some location.

   2. Wiki Markup

      *Select whether to "Run extant machine or design model? (x/d) \[d\]:*". Hit x or d, and RETURN. Running the "design" model (choice "d") causes the XAL model to be run with the element setpoint values in the model input files. Those design setpoint values are, [to the extent possible, identical to the MAD design|#modeldiffs]. Running the "extant" model (choice "x") will cause the model execution to first replace the design values of beamline devices, with the actual readback values, as acquired through EPICS and AIDA, prior to running the envelope tracker. That is, "extant" is equivalent to what was called "DATABASE" in the SLC modelling system; it describes the extant machine at the time the model is run. !image:xalGetModelextant|thumbnail! *Stages of running the (extant) model are as follows:*

      • Wiki Markup

        *1) "Initial Twiss"* is displayed. Check the initial conditions which will be used for the model run. These are presently taken from the SLC marker point 80. You can check these at any time with AIDAWeb ([MARK:VX80:80//twiss MODE=5|https://seal.slac.stanford.edu/aidaweb/dispatchQuery?Query=MARK%3AVX00%3A80%2F%2Ftwiss+MODE%3D5&Query+Action=Get+Data]; the values are Energy (GeV), psix, betax (m), alphax , etax (m), etax', psiy, betay (m), alphay, etay (m), etay') !image:extantinitconditions.jpg|thumbnail! If these appear fine, then confirm to continue.

      • 2) "Run LEM 'Lite'". This will calculate and display the fudge factors and predicted energy. When it has completed, check in particular that the final energy at the undulator (see Energy comlumn, and the row of output labelled "BSY") is reasonable, e.g. 9.25 GeV.
        If energy appears fine, then confirm to continue.
      • 3) "Run XAL machine model." This can take up to a minute to execute, so please be patient. When it has completed, if you ran xalGetModel, you should get 3 plots - the dispersion, betas, and energy vs Z. The plots may overlap, and the energy plot is on the bottom, so move the others to check it.
      • 4) "Create MAD patch file". This stage is always entered, you don't need to do anything. It only takes a moment to create these.

      • Wiki Markup
        "Create and upload XML model files to Oracle? (y/n) \[n\]: " If it all looks good, and you want to upload to Oracle, say "y".

      • 5) "Run XML writer." If you said y to create the upload files, you'll now see "Run XML writer." This is where the file containing the model results to be uploaded to Oracle, is created. This also takes half a minute or so.
        When it has completed, you should see that 3 files have been created: E.g.

        Code Block
        /u1/lcls/physics/onlinemodel/xal/xalElements_20090120_115855.xml created /u1/lcls/physics/onlinemodel/xal/xalDevices_20090120_115855.xml created /u1/lcls/physics/onlinemodel/xal/xalModel_20090120_115855.mat created

   3. Upload the XAL model online on the web. See next section.

...

Note that all models require the model to be run from the Cathode to some beam destination, rather than allowing sections to be run independently. This is so that, for now, we can guarantee that physics computations carried out from a number of different devices throughout the machine, are carried out from consistent models made from the same initial conditions. With this technique all devices towards the photon end of the machine, must have been modeled by a model run that incorporated upstream devices. A simple example being Rmat A to B from a corrector in the injection line, to a BPM in the

Anchor

...

whydiffdirs

...

whydiffdirs

Why mccfs2 in upload stage, but not in writing?

Note, the directory name starts /u1 when the files are written

Which devices are not modelled.
What is not modelled as it is in MAD.

Copy the file to the following directory. It's necessary to copy it to here because it has to be in a directory that can be accessed by the web browser used in the following step. Note, this directory name starts /u1, but when we do the file upload from lcls-prod02 it will start /mccfs2_, that's because on lcls-prod02 the directory is accessed through an NFS server mount, which is named mccfs2.

Put XAL XML files here on slc:

...

Anchor
modeldiffs modeldiffs

Differences between XAL and MAD models.

To be added:
Which devices are not modelled.
What is not modelled as it is in MAD.

Update the AIDA Directory service

...