2013/02/27

Some numbers from Alba

Yesterday, I've placed some numbers in the post and I think there are other important numbers on this facility.

From the operation calendar, some numbers can be extracted. The synchrotron will be running 5184h (60% of the year time).

Well this is more the number of hours that can be running, because the 27% of this time (1416h, 16% of the year) are machine studies and accelerator test. This means that during this time is not necessary that we have beam in the storage.

For the users, it's plan that we will deliver 3768 beam hour. This represent the 72% of the available running time (or the 43% of the year time).

The rest of the year is dedicated to maintenance and improvements (984h, 11% of the total) and warm-up (2432h, 27.7%). There are special time slots dedicates to the Personal Safety System (64h, 0.7%) and the CSN (spanish acronym of the Nuclear Security Council).

This give a total amount of 8760h (365 days).

More numbers?

The storage ring has a perimeter of about 270m, designed to have an energy of 3GeV and the accumulated current at 400mA. In this circumference there are:
  • 32 bending magnets that generates a magnetic field up to 1.42T each and a magnetic gradient (G) of 5.5T/m.
  • 112 quadrupoles
  • 120 sextupoles with B=1.12T
    • Those sextupoles have additional coils to apply corrector dipole field.
The booster ring has a perimeter of about 250m, and is the propeller phase that accelerates the electron beam from 100MeV to the 3GeV that has to be given to the storage ring. In this circumference there are:
  • 40 bending magnets with a B=0.89 T, and G=2.2T/m
  • 60 quadrupoles
  • 16 sextupoles 
  • 72 correctors
In total we have more than 700 magnets:



More numbers? There are many more fields where numbers can be written here. This may starts a series of articles.

Update 20130228: Summary:
Off 984h 11%
Warm-up 2432h 27.3%
Beamtime 5184h 60% Machine 1416h 27% (16% of the year)



Beamlines 3768h 72% (43% of the year)
CSN 96h 1%
PSS 64h 0.7%
Total 8760h

2013/02/26

Why some of our cameras die

From the 54 cameras that we have in side the tunnel, there is one location that is registering more failures than the other positions. Years a go, to find the cameras on their places (and the power source for all of them) I did by hand a map:


You have to have on mind that, following the current information in our cabling data base, we have 18767 cables (with a total length of 168km, on average 11.33m), with 6683 equipments of 728 different types, located in 374 racks.

But back to the reason of this post, there is one ccd camera location, where the hardware dies too often. The technical service from the manufacturer, Basler, have answered to us, something like "what the hell did you did to those cameras!?". They didn't saw this level of damages before.

It is on the top of the map image, but a detail will de useful:


The circles indicates locations of cameras. In red the "sr16/di/fs-01" that to often dies, in blue other cameras. The one near is the "bt/di/fsotr-03" who is not failing (at least not by now). A picture of the place is:


On this picture, the camera is the black box (with white letters saying Scout) on top with a grey network cable on the top. 

It's a very important camera, due to the long list of uses it has, specially because when an injected beam to the storage ring is seen here means that one turn is completed (no obstacles in the path).

But why it dies? We know that we are placing this equipments in the tunnel and they can suffer mal functions due to the radiation, but why this is the only place where this cameras die? It looks that we found the reason.

The first hypothesis was: synchrotron light from the transferline. This camera is almost aligned with the second bending magnet from the booster transferline. But is not convincing us.

Basically this camera is 40cm up to the beam pipe. Like, in radians from the aperture, the blue circle at the exit of this bending, where a synchrotron radiation is placed and is not failing.

A secondary hypothesis is neutron scattering. But this is neither easy because the last camera of the booster transferline is also there. Its blue dot is near. The only difference is that the one in the transferline is down the beam pipe and perhaps those particles could have more obstacles in the middle. Maybe yes, maybe not.

Lest look on the storage injection in more detail. Remember the drawing with the coloured circles, there where two boxes besides the red dot, after a bigger box and followed by two more boxes from the first size. The four with the same size are kicker magnets, and the bigger one represents the septum magnet.

Those are pulsed magnets that when there is no injection they don't act, but when there is a beam injection the kickers divert the beam trajectory in four squares and the septum is placing the incoming (blue) and the stored (red) beams very very close:


A very schematic view of what is happening in the septum can be (yes, it can be draw by a kid):

The green line in between both beams is a metallic shielding to isolate the magnetic field of the septum for the booster incoming beam (blue), that the stored beam (red) should not see this field.

The current hypothesis now is that we maybe heating this shielding, scattering back "something" (probably neutrons) and they find the camera in the path. The last camera of the booster transferline is not in the same plane than this shielding.

2013/02/14

fpFCT: bugfixing

After the development of this study of the filling pattern using the fast current transformer it was time to search for bugs. From a result like:


This calculation doesn't have good sense and looks like there is a bug. This only 2 groups doesn't look nice. Even worst when we execute the code under an scripting way, the result was different. And we found the error: the number of giga samples used in the calculation. We've seen a 10th factor and we found that using the scripting mode, it reads the attribute from the scope, but from the device server it uses a default initial value of 4e10.

We've been lucky that the default value wasn't the same than what was expected, or we would get crazy if some day it changes. For example if the scope samples at 20GS/s instead of 40.

After last bug search we can see results like:


There are things to review, we didn't finish completely this development. But what is true is that the scientist already have usable data for their studies.