text:
# Varying Alpha in a More Realistic Universe

thanks:  DFM thanks Oxford University for hospitality, C. van de Bruck and M. Murphy for discussions and Fundação para a Ciência e a Tecnologia, and Fundação Calouste Gulbênkian for funding.

## Abstract

We study the space-time evolution of the fine structure constant, $`\alpha `$, inside evolving spherical overdensities in a lambda-CDM Friedmann universe using the spherical infall model. We show that its value inside virialised regions will be significantly larger than in the low-density background universe. The consideration of the inhomogeneous evolution of the universe is therefore essential for a correct comparison of extragalactic and solar system limits on, and observations of, possible time variation in $`\alpha `$ and other constants. Time variation in $`\alpha `$ in the cosmological background can give rise to no locally observable variations inside virialised overdensities like the one in which we live, explaining the discrepancy between astrophysical and geochemical observations.

Recent observations of small variations in relativistic atomic structure in quasar absorption spectra murphy  suggest that the fine structure constant $`\alpha `$, was smaller at redshifts $`z=13`$ than the current terrestrial value $`\alpha _0=7.29735308\times 10^3`$, with $`\mathrm{\Delta }\alpha /\alpha \{\alpha (z)\alpha _0\}/\alpha _0=0.543\pm 0.116\times 10^5`$. Several theories of varying $`\alpha `$ have been proposed to investigate the implications bsbm . Time-varying $`\alpha `$ requires a scalar field that couples to electromagnetically-charged matter. Variations in $`\alpha `$, allowed by the conservation of energy and momentum will then depend on the expansion of the universe and the evolution of the electromagnetically coupled matter. The inclusion of electroweak or grand unification will create more complicated consequences and constraints lang . Variations in $`\alpha `$ due to perturbation in the matter fields were first studied in mota2 , using the linear theory of cosmological perturbations. It was shown there, that perturbations in $`\alpha `$ will grow during the matter-dominated epoch and will be constant or decay during the other eras. In otoole  the effects of $`\alpha `$ on gravity were also analysed. However, any effects on the time and spatial evolution of $`\alpha `$ due to cluster and galaxy formation has been ignored in the literature. This is a major weakness and, as a result, past attempts to confront observations on extragalactic scales with lab or solar system constraints on $`\alpha `$ variation are all questionable. This letter describes the first attempts to follow the inhomogeneous evolution of $`\alpha `$ during the development of non-linear cosmic structures. We compare the evolution of $`\alpha `$ in the background universe and in overdense regions of the universe.

We will study variations in $`\alpha `$ in the Bekenstein-Sandvik-Barrow-Magueijo (BSBM) theory bsm1 , which assumes that the total action of the Universe is given by:

$$S=d^4x\sqrt{g}\left(_g+_m+_\psi +_{em}e^{2\psi }\right)$$
(1)
In the BSBM varying-$`\alpha `$ theory, the quantities $`c`$ and $`\mathrm{}`$ are constants, while $`e`$ varies as a function of a real scalar field $`\psi ,`$ with $`e=e_0e^\psi `$. $`_\psi =\frac{\omega }{2}_\mu \psi ^\mu \psi `$, $`\omega `$ is a coupling constant, and $`_{em}=\frac{1}{4}f_{\mu \nu }f^{\mu \nu }`$. The gravitational Lagrangian is the usual $`_g=\frac{1}{16\pi G}R`$, with $`R`$ the Ricci curvature scalar. $`_m`$ is the matter fields Lagrangian. Defining an auxiliary gauge potential by $`a_\mu =ϵA_\mu `$ and a new Maxwell field tensor by $`f_{\mu \nu }=ϵF_{\mu \nu }=_\mu a_\nu _\nu a_\mu `$, the covariant derivative takes the usual form, $`D_\mu =_\mu +ie_0a_\mu `$. The fine structure constant is then $`\alpha \alpha _0e^{2\psi }`$ with $`\alpha _0`$ the present value here.

The background universe will be described by a flat, homogeneous and isotropic Friedmann metric with expansion scale factor $`a(t)`$. Varying the total Lagrangian we obtain the Friedmann equation ($`\mathrm{}=c1`$) for a universe containing dust, of density $`\rho _m`$ $`a^3`$ and a cosmological constant $`\mathrm{\Lambda }`$ with energy-density $`\rho _\mathrm{\Lambda }`$ $`\mathrm{\Lambda }/(8\pi G)`$:

$$3H^2=8\pi G\left(\rho _m\left(1+\left|\zeta \right|e^{2\psi }\right)+\rho _\psi +\rho _\mathrm{\Lambda }\right)$$
(2)
where $`H\dot{a}/a`$ is the Hubble rate, $`\rho _\psi =\frac{\omega }{2}\dot{\psi }^2,`$ and $`\zeta =_{em}/\rho _m`$ is the fraction of the matter which carries electric or magnetic charges. The value (and sign) of $`\zeta `$ will depend on the nature of dark matter: $`\zeta 10^4`$ for neutrons or protons but $`\zeta =1`$ for superconducting cosmic strings bsm1 . The scalar-field evolution equation is

$$\ddot{\psi }+3H\dot{\psi }=2e^{2\psi }\zeta \rho _m/\omega .$$
(3)
Variations in $`\alpha `$, due to the formation of overdense spherical regions, can be studied using the spherical infall model padmanaban . We model the spherical overdense inhomogeneity by a closed Friedmann metric and the background universe by a spatially flat Friedmann model. Each has their own expansion scale factor and time, which are linked by the condition of hydrostatic support at the boundary. This approach is equivalent to study the effect of perturbations to the Friedmann metric by considering spherically symmetric regions of different spatial curvature in accord with Birkhoff’s theorem. The density perturbations need not to be uniform within the sphere: any spherically symmetric perturbation will evolve within a given radius in the same way as a uniform sphere containing the same amount of mass. Clearly, this model ignores any anisotropic effects of gravitational instability or collapse. Similar results could be obtained by performing the analysis of the BSBM theory using a spherically symmetric Tolman-Bondi metric for the background universe with account taken for the existence of the pressure contributed by $`\mathrm{\Lambda }`$ and the $`\psi `$ field. In what follows, therefore, density refers to mean density inside a given sphere.

Consider a spherical perturbation with constant internal density which, at an initial time, has an amplitude $`\delta _i>0`$ and $`|\delta _i|1`$. At early times the sphere expands along with the background. For a sufficiently large $`\delta _i,`$ gravity prevents the sphere from expanding. Three characteristic phases can then be identified.  Turnaround: the sphere breaks away from the general expansion and reaches a maximum radius. Collapse: if only gravity is significant, the sphere will then collapse towards a central singularity where the densities of the matter fields would formally go to infinity. In practice, pressure and dissipative physics intervene well before this singularity is reached and convert the kinetic energy of collapse into random motions.  Virialisation: dynamical equilibrium is reached and the system becomes stationary: there are no more time variations in the radius of the system, $`R`$, or in its energy components. In the spherical collapse model, due to its symmetry, the only independent coordinates are the radius of the overdensity and time. Also, as is standard practice when using this model, we consider that there are no shell-crossing which implies mass conservation inside the overdensity and independence of the radius coordinate padmanaban . The equations can then be written ignoring the spatial dependence of the fields (but still including an equation for the evolution of the radius). Hence, the evolution of a spherical overdense patch of scale radius $`R(t)`$ is given by the Friedmann acceleration equation:

$$3\ddot{R}=4\pi GR\left(\rho _{cdm}\left(1+\left|\zeta \right|e^{2\psi _c}\right)+4\rho _{\psi _c}2\rho _\mathrm{\Lambda }\right)$$
(4)
where $`\rho _{cdm}`$ is the total density of cold dark matter and baryons in the cluster, $`\psi _c`$ is the homogeneous field inside the cluster and we have used the equations of state $`p_{\psi _c}=\rho _{\psi _c}`$, $`p_{cdm}=0`$ and $`p_\mathrm{\Lambda }=\rho _\mathrm{\Lambda }`$. In the cluster, the evolution of $`\psi _c`$ and $`\rho _{cdm}`$ is given by

$$\ddot{\psi _c}+3\left(\dot{R}/R\right)\dot{\psi _c}=2e^{2\psi _c}\zeta \rho _{cdm}/\omega $$
(5)
and $`\rho _{cdm}R^3.`$ The cluster will virialise when

$$T_{vir}=0.5U_G+U_\mathrm{\Lambda }2U_{\psi _c}$$
(6)
where $`U_G`$ $`=\frac{3}{5}GM^2R^1`$ is the potential energy associated with the uniform spherical overdensity, $`U_\mathrm{\Lambda }`$ $`=\frac{4}{5}\pi G\rho _\mathrm{\Lambda }MR^2`$ is the potential associated with $`\mathrm{\Lambda },`$ and $`U_{\psi _c}=\frac{3}{5}GMM_{\psi _c}R^4`$ is the potential associated with $`\psi _c.`$ $`T_{vir}`$ is the kinetic energy, and $`M=M_{cdm}+M_{\psi _c}`$ is the cluster mass, with $`M_{cdm}=\frac{4\pi }{3}\rho _{cdm}(1+|\zeta |e^{2\psi _c})R^3`$ and $`M_{\psi _c}=\frac{4\pi }{3}\rho _{\psi _c}R^6`$; Using the virial theorem (6) and energy conservation when the cluster virialises gives

$`0.5U_G+2U_\mathrm{\Lambda }U_{\psi _c}|_{z=z_v}=U_G+U_\mathrm{\Lambda }+U_{\psi _c}|_{z=z_{ta}}`$ (7)
where $`z_v`$ is the redshift of virialisation and $`z_{ta}`$ is the redshift at the turn-around of the over-density at its maximum radius, when $`R=R_{max}`$ and $`\dot{R}0`$.

The analysis in this letter (which reduces completely to the linear perturbation analysis in the small time limit when all inhomogeneities are small mota2 ) is valid for spherically symmetric perturbations right into the non-linear regime, including turnaround and collapse. Spatial gradients in pressure (and hence in the scalar field) are negligible on large scales, exceeding the Jeans length. The scalar field is indeed slightly inhomogeneous but the inclusion of a varying $`\alpha `$ at a level consistent with observation murphy , ($`\dot{\alpha }/\alpha _010^6H`$), does not affect the overall expansion of the universe or the dynamical collapse of the overdense regions. The energy density associated with $`\psi `$ is always a negligible contribution to the energy content of the universe, both in the cluster and in the background, if we are far from the initial or collapse singularities bsm1 . After the fluctuation virialises and attains gravitational equilibrium this assumption may no longer be true, but our analysis like that of all other exact studies of galaxy formation breaks down at that stage because the resulting disk will be controlled by pressure and gradients.

The behaviour of the fine structure constant during the evolution of a cluster can now be obtained by numerically evolving the background eqs.(2)-(3) and the cluster eqs.(4)-(5) until the virialisation condition (7) holds. Since the Earth is in a virialised overdense region, the initial conditions for $`\psi `$ are chosen so as to obtain our measured lab value of $`\alpha `$ at virialisation $`\alpha _c(z_v)=\alpha _0`$ and to match the latest observations murphy  for overdense regions at $`3|zz_v|1`$. Since $`z_v`$ is uncertain, we have chosen representative examples with virialisation over the range $`0<z_v<10`$. This is shown in Fig. 2, where the clusters have different initial conditions in order to satisfy the constraints described. This is just an example, since in reality, the initial condition for $`\psi `$ needs to be fixed only once, for our Galaxy. Hence, $`\alpha `$ in other clusters will have a lower or higher value (with respect to $`\alpha _0`$) depending on their $`z_v`$; see Fig.1. After virialisation occurs the cluster radius becomes constant; time and space variations in $`\alpha `$ are suppressed, and $`\alpha `$ becomes constant. If there were any variations in $`\alpha `$ after virialisation, the energy and radius of the cluster would need to vary in order to conserve energy and this is inconsistent with virialisation. This phenomenon is not included in Fig. 1, since we did follow the evolution to virialisation with a many-body simulation which would need to include the fluid equations that describe the pressure inside the cluster. In our simulation, the virial condition is a ’stop condition’ and so we just observe the typical behaviour of the cluster’s collapse as $`R0`$. Clearly, collapse will never occur in practice; dissipative physics will eventually intervene and convert the kinetic energy of collapse into random motions. In addition to the stationarity condition that occurs when the cluster virialises, it can be seen from Fig.2 that in all cases the variation in $`\alpha `$ since the beginning of the cluster formation is of order $`10^5`$, and numerical simulations give $`\dot{\alpha }/\alpha 10^{22}s^1.`$ If variations in $`\alpha `$ are so small for such a wide range of virialisation redshifts, we can assume that the difference between the value of $`\alpha _c`$ at $`z_v`$ and at $`z=0`$ will be negligible. Therefore it is a good approximation to assume that the time-evolution of both $`\alpha _c`$ and of the cluster will cease after virialisation. Although this is not necessarily true (the cluster could keep accreting mass), it is a good approximation in respect of the evolution of $`\alpha `$, especially for clusters which have virialised at lower redshifts.

If we could measure $`\alpha `$ inside virialised overdensities and the corresponding value in the background, at the time of their virialisation, then Fig 3 and 4 would give us the evolution of $`\alpha _v`$ or its time shift, $`\mathrm{\Delta }\alpha _v/\alpha _v,`$ as a function of $`z_v`$. Those figures show us that differences in between the background and the overdensities increase as $`z_v0`$. This is due to the earlier freezing of the value of $`\alpha `$ at virialisation, and to our assumption that we live in a $`\mathrm{\Lambda }CDM`$ universe. At lower redshifts, specially after $`\mathrm{\Lambda }`$ starts to dominate, variations in $`\alpha `$ in the background are turned off by the accelerated expansion. However, the value of $`\alpha `$ in the collapsing cluster will keep growing until virialisation occurs. Numerical simulations give $`\mathrm{\Delta }\alpha /\alpha (z=2)=6\times 10^6`$ for the background and $`\mathrm{\Delta }\alpha /\alpha (z_v=0.13)=1.5\times 10^7`$ in a cluster. At higher redshifts, $`z1`$, both $`\alpha _b`$ and $`\alpha _c`$ evolve in expanding environments: their increase is logarithmic in time before $`\mathrm{\Lambda }`$ starts to dominate, so the difference between them will be much smaller.

Spatial variations in $`\alpha `$ can be tracked using a ’spatial’ density contrast, defined by $`\delta \alpha /\alpha [\alpha _c\alpha _b]/\alpha _b`$. A plot of the spatial inhomogeneities in $`\alpha `$ with respect to the matter density inhomogeneity, $`\delta \rho /\rho ,`$ at virialisation is shown in Fig. 5. Note that $`\delta \alpha /\alpha `$ grows in proportional to the density contrast of the matter inhomogeneities ($`t^{2/3}`$ when both are small during dust domination mota2 ). In a $`\mathrm{\Lambda }CDM`$ model, the density contrast, $`\mathrm{\Delta }_c=\rho _{cdm}(z_v)/\rho _b(z_v)`$ increases as the redshift decreases. For high redshifts, the density contrast at virialisation becomes the asymptotically constant in standard ($`\mathrm{\Lambda }=0`$) CDM, $`\mathrm{\Delta }_c178`$ at collapse or $`\mathrm{\Delta }_c148`$ at virialisation. This is another reason why at lower redshifts the difference between $`\alpha _v`$ and $`\alpha _b`$ increases. Trends of variation in $`\alpha `$ can be then predicted from the value of the matter density contrast of the regions observed. Useful fitting formulas for the dependence of $`\alpha `$ variation on $`\delta \rho /\rho `$ and the scale factor $`a`$ $`(1+z)^1`$ are:

$`\delta \alpha /\alpha `$ $`=`$ $`(5.560.7\sigma ^{\frac{1}{2}}+0.078\sigma +0.00352\sigma ^{\frac{3}{2}})\times 10^6`$
$`\delta \alpha /\alpha `$ $`=`$ $`(5.37+0.373\theta ^{\frac{1}{6}}0.27\theta ^{\frac{1}{3}}+0.007\theta ^{\frac{1}{2}})\times 10^6`$
$`\mathrm{\Delta }\alpha /\alpha `$ $`=`$ $`(2.471.81\sigma ^{\frac{1}{2}}+0.59\sigma 0.094\sigma ^{\frac{3}{2}})\times 10^6`$
where $`\theta \frac{\delta \rho }{\rho }/\mathrm{\Delta }_{c_v}`$, $`\sigma a/a_v`$. $`\mathrm{\Delta }_{c_v}`$ and $`a_v`$ are ’input’ parameters defined when $`\alpha (z_v)=\alpha _0`$ .

The evolution of $`\alpha \alpha _b`$ in the background and inside clusters depends mainly on the dominant equation of state of the universe and the sign of the coupling constant $`\frac{\zeta }{\omega },`$ which is determined by the theory and the dark matter identity. Here, we have assumed that $`\omega =1`$, so all the dependence is in $`\zeta `$. As shown in refs. bsm1 , $`\alpha _b`$ will be nearly constant for accelerated expansion and also during radiation-domination far from the initial singularity (where the kinetic term, $`\rho _\psi `$, can dominate). Evolution of $`\alpha `$ will occur during the dust-dominated epoch, where $`\alpha `$ increases logarithmically in time for $`\zeta <0`$. When $`\zeta `$ is negative, $`\alpha `$ will be a growing function of time but will fall for $`\zeta `$ positive bsm1 . Inside clusters $`\alpha _c`$ will have the same dependence on $`\zeta `$ as it has in the background. The sign of $`\zeta `$ is determined by the physical character of the dark matter that carries electromagnetic coupling: if it is dominated by magnetic energy then $`\zeta <0`$, if not then $`\zeta >0.`$ Our numerical simulations were performed assuming $`\zeta =2\times 10^4`$. If we had chosen $`\zeta `$ to be positive we would find that $`\alpha _b`$ would decrease as steeply as $`z0`$. We choose the sign of $`\zeta `$ to be negative so $`\alpha `$ is a slowly growing function in time during dust domination. This is done in order to match the latest observations which suggest that $`\alpha `$ had a smaller value in the past murphy . However, we know that on small enough scales the dark matter will become dominated by a baryonic contribution for which $`\zeta >0.`$ This will create distinctive behaviour and will be investigated separately. Generally, past studies of spatially homogeneous cosmologies have effectively matched the value of $`\alpha _b`$ with the terrestrial value of $`\alpha `$ measured today. However, it is clear that the value of the fine structure constant on Earth, and most probably in our local cluster, will differ from that in the background universe. This feature has been ignored when comparing observations of $`\alpha `$ variations from quasar absorption spectra murphy  with local bounds derived by direct measurement prestage  or from Oklo oklo  and long-lived $`\beta `$-decayers beta . A similar unwarranted assumption is generally made when using solar system tests of general relativity to bound possible time variations in $`G`$ in Brans-Dicke theory varyg : there is no reason why $`\dot{G}/G`$ should be the same in the solar system and on cosmological scales. Since any varying-constant’s model require the existence of a scalar field coupled to the matter fields, our considerations apply to all other theories besides BSBM and to variations of other ’constants’ other . Note that this feature is much less important when using early universe constraints like the CMB or BBN cmbbbn , since small perturbations in $`\alpha `$ will decay or become constant in the radiation era mota2 .

In summary, using the BSBM theory we have shown that spatial variations in $`\alpha `$ will inevitably occur because of the development of large density inhomogeneities in the universe. This was first shown in the linear regime, when perturbations are small mota2 , and then $`\frac{\delta \alpha }{\alpha }`$ tracks $`\frac{\delta \rho _m}{\rho _m}`$ during the dust-dominated era on scales smaller than the Hubble radius. We have used the spherical collapse model to study the space-time variations in $`\alpha `$ in the non-linear regime. Strong differences arise between the value of $`\alpha `$ inside a cluster and its value in the background and also between clusters. Variations in $`\alpha `$ depend on the matter density contrast of the cluster region and the redshift at which it virialised. If the overdense regions are still contracting and have not yet virialised, then the value of $`\alpha `$ within them will continue to change. Variations in $`\alpha `$ will cease when the cluster virialises so long as it does so at moderate redshift. This leads to larger values of $`\alpha `$ in the overdense regions than in the cosmological background and means that time variations in $`\alpha `$ will turn off in virialised overdensities even though they continue in the background universe. The fact that local $`\alpha `$ values ’freeze in’ at virialisation, means we would observe no time or spatial variations in $`\alpha `$ on Earth, or elsewhere in our Galaxy, even though time-variations in $`\alpha `$ might still be occurring on extragalactic scales. For a cluster, the value of $`\alpha `$ today will be the value of $`\alpha `$ at the virialisation time of the cluster. We should observe significant differences in $`\alpha `$ only when comparing clusters which virialised at quite different redshifts. Differences will arise within the same bound system only if it has not reached viral equilibrium. Hence, variations in $`\alpha `$ using geochemical methods could easily give a value that is $`100`$ times smaller than is inferred from quasar spectra. We conclude that the consideration of the evolution of inhomogeneities, notably the one inside which we live, is essential if we are to make meaningful comparisons of different pieces of astronomical and terrestrial evidence for the constancy of $`\alpha `$.


format: text

text:
# Phase transition in the Ising model on a small-world network with distance-dependent interactions

## Abstract

We study the collective behavior of an Ising system on a small-world network with the interaction $`J(r)r^\alpha `$, where $`r`$ represents the Euclidean distance between two nodes. In the case of $`\alpha =0`$ corresponding to the uniform interaction, the system is known to possess a phase transition of the mean-field nature, while the system with the short-range interaction $`(\alpha \mathrm{})`$ does not exhibit long-range order at any finite temperature. Monte Carlo simulations are performed at various values of $`\alpha `$, and the critical value $`\alpha _c`$ beyond which the long-range order does not emerge is estimated to be zero. Thus concluded is the absence of a phase transition in the system with the algebraically decaying interaction $`r^\alpha `$ for any nonzero positive value of $`\alpha `$.

Small-world networks, which are intermediate between the local regular networks and the random networks, have two interesting features: high clustering, characteristic of regular networks, and short path length, typically observed in random networks ref:network ; ref:WS . The characteristic path length $`l`$ is defined to be the average of the shortest path lengths between any two nodes: In many complex networks, the behavior $`l`$ log$`N`$ with the network size $`N`$ is observed, while regular lattices display $`lO(N)`$. When a dynamical system of many elements is put on a small-world network, information exchange between two elements involves only relatively short distance of the order of $`\mathrm{log}N`$. It has been observed in recent studies that the presence of shortcuts induces long-range order below the critical temperature ref:Ising ; ref:XY . Furthermore, nature of the phase transition has been unambiguously demonstrated to belong to the mean-field universality class. In those studies of the spin models on small-world networks, spin interactions have been assumed to be uniform, which is rather unrealistic in view of usual systems in nature. It is thus desirable to examine the general case of distance-dependent interactions, which has not been addressed.

In this paper we study the Ising model on a small-world network, constructed from a one-dimensional lattice, with the interaction $`J`$ decaying algebraically with distance $`r`$, i.e., $`J(r)r^\alpha `$. In such a case of the algebraically decreasing interaction, the critical behavior is expected to change with the exponent $`\alpha `$: The limit $`\alpha 0`$ corresponds to the uniform interaction, which yields a mean-field transition at the finite critical temperature ref:Ising . In the opposite limit of $`\alpha \mathrm{}`$, the spins interact with only their nearest neighbors, resulting in the absence of long-range order at finite temperatures. This consideration suggests the existence of nontrivial critical value $`\alpha _c`$ beyond which the finite-temperature phase transition disappears.

Here we construct a small-world network in the following way: First a one-dimensional lattice of $`N`$ nodes is constructed with each node connected to its $`2k`$ nearest neighbors, where $`k`$ is the local interaction range. Then each local edge is visited once and a random long-range connection (shortcut) is added with the probability $`P`$ without removing local edges. Note the difference from the original Watts and Strogatz (WS) construction ref:WS , where local edges are removed and reconnected to a randomly chosen node.

The Hamiltonian for an Ising model on such a small-world network is given by

$$H=\frac{1}{2}\underset{ij}{}J_{ij}\sigma _i\sigma _j,$$
(1)
where $`\sigma _i(=\pm 1)`$ is the Ising spin on node $`i`$ of the network. The distance-dependent interaction $`J_{ij}`$ reads

$$J_{ij}=J_{ji}=\{\begin{array}{cc}Jr_{ij}^\alpha \hfill & \text{if i and j are connected}\hfill \\ 0\hfill & \text{otherwise,}\hfill \end{array}$$
(2)
where $`r_{ij}`$ is the geometrical distance (rather than the shortest path length) between the two nodes $`i`$ and $`j`$ on the underlying one-dimensional lattice.

From the comparison of the two limits $`\alpha 0`$ and $`\alpha \mathrm{}`$, a total of three distinct regimes may be expected ref:Fisher ; ref:Luijten : (i) mean-field-type critical behavior for $`\alpha <\alpha _1`$; (ii) continuously varying critical exponents for $`\alpha _1<\alpha <\alpha _2`$; (iii) the short-range interaction regime with no phase transition for $`\alpha >\alpha _2`$. In Ref. ref:Fisher, , two boundary values $`\alpha _1`$ and $`\alpha _2`$ were obtained via renormalization-group calculations for the $`O(n)`$ model on a $`d`$-dimensional globally-coupled system. In particular, it is well known that $`\alpha _1=3/2`$ and $`\alpha _2=2`$ for the one-dimensional globally-coupled Ising model. Note here that the total number of connections in this one-dimensional globally-coupled system, given by $`N(N1)/2`$ with $`N`$ being the number of spins, is far larger than that in a small-world network, which is of the order of $`N`$. Accordingly, smaller boundary values of $`\alpha `$ are anticipated for the small-world network.

We have performed extensive Monte Carlo (MC) simulations with the heat bath algorithm at various values of $`P`$ and $`\alpha `$. The range $`k=2`$ was taken for convenience; other values of $`k(>1)`$ are not expected to give qualitatively different results. Measured in the simulations are Binder’s cumulant ref:Binder , the susceptibility, and the specific heat:

$$U_N=1\frac{[m^4]}{3[m^2]^2}$$
(3)
$$\chi =\frac{1}{N}\underset{ij}{}[\sigma _i\sigma _j]$$
(4)
$$C_v=\frac{[H^2H^2]}{T^2N}$$
(5)
with $`m|(1/N)_i\sigma _i|`$. Here $`\mathrm{}`$ and $`[\mathrm{}]`$ denote the thermal average, taken over $`5\times 10^4`$ MC steps after discarding $`5\times 10^4`$ MC steps for equilibration at each temperature, and the average over different network realizations, taken over 50 to 100 configurations, respectively. When $`P=0`$, the network reduces to a simple one-dimensional lattice, displaying no long-range order at any finite temperature. For $`P0`$, on the other hand, the presence of long-range shortcuts deprives the system of the locally connected one-dimensional character. In particular, when the interaction is uniform ($`\alpha =0`$), the system at $`P0`$ undergoes a finite-temperature transition of the mean-field nature ref:Ising .

To find $`\alpha _1`$ and $`\alpha _2`$, beyond which mean-field behavior and long-range order do not emerge, respectively, we have examined the behavior of the system with $`\alpha `$ varied at fixed $`P`$. At any nonzero value of $`\alpha `$, the algebraically decaying interaction is cut off by the finite network size and consequently, the ground-state energy in general decreases as $`N`$ grows. For given values of $`k`$, $`P`$, and $`\alpha `$, we thus normalize the coupling strength $`J`$ so that the system has the size-independent ground-state energy per spin. As $`\alpha `$ is reduced, the interaction does not yet decay substantially at the boundary; this makes it inevitable to study systems of very large sizes for obtaining correct scaling behavior.

Figure 1 presents the MC results for the network with $`P=0.5`$ and $`\alpha =0.1`$. Binder’s cumulant $`U_N`$, the susceptibility $`\chi `$, and the specific heat $`C_V`$ as functions of the temperature are shown in (a), (b), and (c), respectively. The absence of a unique crossing point of Binder’s cumulant shown in Fig. 1(a) and the shift of the susceptibility peak in Fig. 1(b) as well as the peak position of the specific heat in Fig. 1(c) unanimously suggest the absence of a phase transition at finite temperatures. At the temperatures where $`\chi `$ and $`C_v`$ display peaks, fluctuations are large and the correlation volume becomes comparable with the system size. This gives some information about the temperature at which critical phenomena are observed. Figure 1(b) shows that as the system size is increased, the peak temperature of $`\chi `$ increases first ($`N800`$), in accord with the observation in Ref. ref:Ising, , and begins to decrease eventually beyond $`N=1600`$. In particular the peak temperature does not saturate to a certain value but decreases continuously, supporting the absence of a finite-temperature transition. The specific heat exhibits similar behavior in Fig. 1(c), although the system size at which the peak position starts to shift toward lower temperatures does not coincide with that for the susceptibility.

To clarify the drift of the peak temperature, we show in Fig. 2 the peak temperatures $`T_p`$ of the susceptibility versus the inverse system size $`1/N`$, together with the fitted lines described by the logarithmic form: $`T_p=ab\mathrm{log}N`$. The peak position thus approaches zero logarithmically as the system size grows. Here the values of the fitting parameters are given by $`a=1.62`$ and $`b=0.016`$ for $`\alpha =0.1`$; $`a=1.67`$ and $`b=0.042`$ for $`\alpha =0.2`$; $`a=1.69`$ and $`b=0.064`$ for $`\alpha =0.3`$. This indicates that the peak temperature decreases faster as the exponent $`\alpha `$ is raised.

As mentioned above, simulations here have been performed in the crossover region, giving rise to logarithmic behavior of the peak position with the system size. When the exponent $`\alpha `$ is small, the interaction reduces very slowly with the distance. Nevertheless it gets weakened substantially in a system of very large size. For example, when $`\alpha =0.1`$, the interaction between the two connected nodes of the maximum distance (i.e., half the system size) is only about 40% of the nearest-neighbor interaction in the system of size $`N=51200`$. Consequently, long-range connections do not contribute significantly to the system to be ordered in the thermodynamic limit, and the absence of a finite-temperature transition is not very surprising. We have also investigated the case of $`\alpha =0.05`$, which requires simulations of even larger system size, to obtain similar results. These observations strongly suggest that the system does not undergo a phase transition at a finite temperature for any nonzero value of $`\alpha `$, thus leading to $`\alpha _1=\alpha _2=0`$. Figure 3 shows that the conclusion $`\alpha _1=\alpha _2=0`$ is apparently valid even for $`P=1.0`$, which corresponds to the network with the largest number of long-range connections. Accordingly, the common belief that small-world networks are similar to globally-coupled networks in the transition nature ref:Ising ; ref:XY  is valid only for the (ideal) uniform interaction. In the more realistic case of the interaction decaying with distance, the two systems display striking difference.

In summary, we have studied the Ising model on small-world networks with the interaction decaying algebraically with exponent $`\alpha `$. For this, we have performed extensive Monte Carlo simulations on the networks with the probability for adding shortcuts given by $`P=0.5`$ and $`1`$. In both cases, absence of a finite-temperature transition has been observed at any nonzero value of $`\alpha `$. In particular, the absence in the latter, which is the extreme case of the small-world network with the largest number of long-range shortcuts, implies the validity for any values of $`P(<1)`$. This conclusion should also hold for the original WS network, where shortcuts are introduced by rewiring of the local edges, since it has less interactions than the network investigated in the present work.

###### Acknowledgements.

B.J.K. was supported by the Korea Science and Engineering Foundation through Grant No. R14-2002-062-01000-0. M.Y.C. acknowledges the partial support from the Ministry of Education through the BK21 Program. Numerical works have been performed on the computer cluster Iceberg at Ajou University.


text:
# GANGA: a user-Grid interface for Atlas and LHCb

## I INTRODUCTION

The Atlas ref:Atlas94  and LHCb ref:LHCb98  collaborations will perform physics studies at the high-energy, high-luminosity, Large Hadron Collider (LHC) ref:LHC95 , scheduled to start operation at CERN in 2007. The data volumes produced by each experiment are in the petabyte range, and will be processed with computing resources that are distributed over national centers, regional centers, and individual institutes. To fully exploit these distributed facilities, and to allow the participating physicists to share resources in a coordinated manner, use will be made of grid services.

The gaudi/athena ref:gaudi ; ref:athena  software framework111From here on referred to as the “gaudi framework” or simply “gaudi.” used by LHCb and Atlas, is designed to support all event-processing applications, including simulation, reconstruction, and physics analysis. A joint project has been set up to develop a front-end that will aid in the handling of framework-based jobs, and performs the tasks necessary to run these jobs either locally or on the grid. This front-end is the Gaudi/Athena and Grid Alliance, or ganga ref:ganga .

Ganga covers all phases of a job’s life cycle: creation, configuration, splitting and recollection, script generation, file transfer to and from worker nodes, submission, run-time setup, monitoring, and reporting. In the specific case of gaudi jobs, the job configuration also includes selection of the algorithms to be run, definition of algorithm properties, and specification of inputs and outputs. Ganga relies on middleware from other projects, such as Globus ref:globus  and EDG ref:edg , to perform Grid-based operations, but makes use of the middleware functionality transparent to the ganga user.

In this paper, we present the ganga design and the choices made for its implementation. We report on the work done in developing the software bus that is a key feature of the design, and we describe the functionality of the current ganga release.

## II GANGA DESIGN

### II.1 Overview

Ganga is being implemented in python ref:python , an interpreted scripting language, using an object-oriented approach, and following a component architecture. The python programming language is simple to use, supports object-oriented programming, and is portable. By virtue of the possibilities it allows for extending and embedding features, python is also effective as a software “glue.” A standard python installation comes with an interactive interpreter, an Integrated Development Environment (IDE), and a large set of ready-to-use modules. The implementation of the component architecture underlying the ganga design benefits greatly from python’s support for modular software development. The components of ganga interact with one another through, and are managed by, a so-called “software bus” ref:mato03a , of which a prototype implementation is described in Section III. This interplay is displayed graphically in Fig. 1.

As considered here, a component is a unit of software that can be connected to, or detached from, the overall system, and brings with it a discrete, well-defined, and circumscribed functionality. In practical terms, it is a python module (either written in python or embedded) that follows a few non-intrusive conventions. The component-based approach has the advantages that it allows two or more developers to work in parallel on well-separated tasks, and that it allows reuse of components from other systems that have a similar architecture. The initial functionality of the software bus is provided by the python interpreter itself. In particular, the interpreter allows for the dynamic loading of modules, after which the bus can use introspection to bind method calls dynamically, and to manage components throughout their life cycle. The functionality of the ganga components can be accessed through a Command-Line Interface (CLI), and through a Graphical User Interface (GUI), built on a common Application-Programmer Interface (API). All actions performed by the user through the GUI can be invoked through the CLI, allowing capture of a GUI session in an editable CLI script.

The components can be divided among three categories: general, application specific, and external. Further developments will add components as needed. With reference to Fig. 1, they are discussed below.

### II.2 Generally applicable components

Although the first priority is to deal with gaudi jobs, ganga has a set of core components suitable for job-handling tasks in a wide range of application areas. These core components provide implementations for the job definition, the editing of job options, the splitting of jobs based on user provided configuration and job templates, and the output collection. In Fig. 1, these components are shown on the right side of the software bus.

The job definition characterizes a ganga job in terms of the following:

* The name chosen as the job’s identifier.
* The workflow (see below) indicating the operations to be performed when the job is run.
* The computing resources required for the job to run to completion.
* The job status (in preparation, submitted, running, completed).

A job workflow is represented as a sequence of elements (executables, parameters, input/output files, and so on), with the action to be performed by, and on, each element implicitly defined. Resources required to run a job, for example minimum CPU time or minimum memory size, are specified as a list of attribute-value pairs, using a syntax not tied to any particular computing system. The job-definition component implements a job class, and classes corresponding to various workflow elements.

Other ganga components of general applicability performing operations on, for, or using job objects:

* A job-registry component allows for the storage and recovery of information for job objects, and allows for job objects to be serialized.
* A script-generation component translates a job’s workflow into the set of (python) instructions to be executed when the job is run.
* A job-submission component takes care of submitting the workflow script to a destination indicated by the user, creating Job Description Language (JDL) files where necessary, and translating the resource requests into the format expected by the target system (European DataGrid (EDG), GridPP grid, US-ATLAS testbed, local PBS queue, and so on).
* A file-transfer component handles transfers between sites of job input and output files, this usually involving the addition of appropriate commands to the workflow script at the time of job submission.
* A job monitoring component keeps track of job status, and allows for user-initiated and scheduled status queries.

### II.3 User group specific components

Ganga can be optimized for a given user group, through the addition of application-specific components. For the current user groups, Atlas and LHCb, specialized components exist that incorporate knowledge of the gaudi framework:

* A component for gaudi job definition adds classes for workflow elements not dealt with by the general-purpose job definition component. For example, applications based on gaudi are packaged using a configuration management tool (cmtref:cmt , which requires its own workflow elements. Also, this component provides workflow templates covering a variety of common tasks, such as simulating events and running an analysis on some dataset.
* A component for gaudi job-options editing allows selection of the algorithms to be run and modification of algorithm properties.
* A component for gaudi job splitting allows for large jobs to be broken down into smaller sub-jobs, for example by examining the list of input data files and creating jobs for subsets of these files.
* A component for gaudi output collection merges outputs from sub-jobs where this is possible, for example when the output files contain data sets like histograms and/or ntuples.

Specialized components for other application areas are readily added. The subdivision into general and specialized components, and the grouping together of specialized components dedicated to a particular problem domain, allows new user groups to identify quickly the components that match their needs, and will improve ganga stability.

### II.4 External components

The functionality of the components developed specifically for ganga is supplemented by the functionality of external components. These include all modules of the python standard library, and also non-python components for which an appropriate interface has been written. Two components of note in the latter category, both interfaced using boost ref:boost , allow access to the services of the gaudi framework itself, and to the full functionality of the root analysis framework ref:root .

## III PYTHON SOFTWARE BUS

### III.1 Functionality

To first order, the software bus functionality required by ganga is provided by the python interpreter itself. The main features not offered by the interpreter, but nevertheless desirable are:

* Symbolic component names
Python modules are loaded on the basis of their names, which are mapped one-to-one onto names in the file system, sometimes including (part of) the directory structure. Components should, instead, be loaded on the basis of the functionality that they promise.
* Replacing a connected component
This is different from the standard reload functionality, which loads a new version of a current module and doesn’t rebind any outstanding references. A component, however, may need to be completely replaced by another component, meaning that the latter must be reloaded deep, and references into the old component must be replaced by equivalent references into the new component, wherever possible.
* Disconnecting components
A standard python module does not get unloaded until all outstanding references disappear. This is common behavior in many off-the-shelf component architectures. However, it should be possible to propagate the unloading of a component through the whole system, allowing for more natural interactive use.
* Configuration and dependencies
Since python modules simply execute python code, their configuration and dependencies are usually resolved locally. Components should be able to advertise their configurable parameters and their dependencies, such that it is also possible to manage the configuration externally and/or globally.

The software bus should also support a User Interface Presentation Layer (UIPL), through which the configuration, input and output parameters, and functionality of components can be connected to user interface elements. The bus inspects the component for presentable elements, including (if applicable) their type, range, name, and documentation. It subsequently requests the user interface to supply elements that are capable of providing a display of and/or interaction with each of the parameters, based on their type, range, etc. Both the interface element and the component should then be hooked through the UIPL.

For example, assume that a configuration parameter of a component is of a boolean type. This parameter can then map onto e.g. a checkbox in a GUI. The bus requests the GUI to provide a display of the boolean value, gets a checkbox in return, and it subscribes the checkbox to a value holder in the UIPL. It also subscribes itself to the value holder. Changes by the checkbox, changes the value in the value holder, which in turn causes a notification to the bus, which sets the value in the component.

Mapping through an UIPL has the advantages that simple user interfaces can be created automatically, and more sophisticated user interfaces can be relatively easily peeled off and replaced, since they never access the actual underlying component directly.

### III.2 The PyBus prototype

A prototype of a software bus (pybus) has been written to explore the possibilities for implementing the above features in a user-level python module, rather than in a framework. That is, pybus is a client of the python interpreter and does not have any privileges over other modules. This means that components written for pybus will act as components when used in conjunction with the bus, or as python modules when used without. Conversely, python modules that were not written as pybus components can still be loaded and managed by the software bus, assuming that they adhere to standard python conventions concerning privacy and dependencies.

When a user connects a component to pybus in order to make it available to the system, he or she can load it using the logical, functional, or actual name. Components that are available to pybus must be registered under logical names, optionally advertising under functional names the public contracts that they fulfill (their “interfaces,” but note that python does not explicitly support interfaces in the sense of Java or C++). If a component is not registered, it can only be connected using its actual name, which is the name that would be used in the standard way of identifying a python module. Unlike the actual name, which has to be unique, the logical name and functional names may be claimed by more than one component. Pybus will choose among the available components on the basis of its own configuration, a priority scheme, or a direct action from the user.

In the process of connecting a module, pybus will look for any conventional parameters (starting with “PyBus\_”) in the dictionary of the module that contains the component. These parameters may describe dependencies, new components to be registered, post-connect or pre-disconnect configuration, and so on. It is purely optional for a module to provide any of these parameters and pybus will use some heuristics if they are absent. For example, all public identifiers are considered part of the interface, so that any module can be connected as if it were a component. The user can decide the name under which the module should be connected, which can be any alias that stands in for the name to be used in the user code, following the ‘as’ option for standard python imports. If no alias is provided, the logical name is used. Pybus keeps track of these aliases.

Pybus allows components to be replaced. In order to do this, it uses the garbage collection and reference-counting information of the python interpreter to track down any outstanding references, and acts accordingly. Some references, for example those to variables or instances, are rebound, whereas others, for example object instances, are destroyed. Disconnecting a component is rather similar to replacing it, with the only exception that no references are rebound: all are destroyed.

Python allows user modules to intercept the importing of other modules, by replacing the import hook. This mechanism allows the pybus implementation to bookmark those modules that are imported during the process of connecting a component, and thus manage component dependencies. When disconnecting a component, the modules that it loaded are not automatically removed, since the interpreter itself holds on to a reference to them, even after all user-level modules are unloaded. There is no real reason to force the unloading of standard modules, but if the modules are components that are connected to pybus, their unloading is mandatory. When a new component is loaded, which in turn loads other components, then pybus needs to resolve the lookup of those components anew: these dependent components may have changed, or different components may be chosen this time around, for a variety of reasons.

The implementation of the prototype of a software bus has been mostly successful. The are a few issues left for embedded components, but for pure python components it has been shown that it is possible to implement the component architecture features missing in the python interpreter with a user-level python module.

## IV THE FIRST RELEASE

### IV.1 Overview of functionality

The ganga design, including possibilities for creating, saving, modifying, submitting and monitoring jobs, has been partly implemented and released. The tools implemented should be suitable for a wide range of tasks, but we have initially focused on running one type of job for Atlas and one type of job for LHCb, focusing on the atlfast ref:atlfast  fast simulation in the case of the former, and the davinci ref:davinci  analysis in the case of the latter. Optimization for other types of applications essentially means creating more templates, which is a straightforward procedure. The current release allows jobs to be submitted to the European DataGrid, and to local PBS and LSF queues. Communication between components in the prototype is via the python interpreter, with the sophistication of pybus to be added later.

The first release does not yet fulfill all requirements, but it already helps the user to perform a number of tasks that otherwise would have to be done manually. For example, the creation of JDL files necessary for job submission to the EDG Testbed, and the generation of scripts to submit jobs to other batch systems, has been automated.

Most parameters relevant for gaudi-based jobs have reasonable default values, so that a user only has to supply minimal information to create and configure a new job. Existing jobs can easily be copied, renamed, and deleted. When a job is created, it is presented as a template that can be edited by the user. After making the proper modifications, the user can submit the job for execution with a single command. If the generated scripts and job-options files need to be verified before submission, the user can perform the job set up with the configure command. Job splitting is achieved through loading and executing a splitter script, with support for both default and user scripts.

When a job is submitted, ganga starts to monitor the job state by periodically querying the appropriate computing system. This process can be stopped or started manually at any time.

When a job is running, it can be killed, if so desired. On job completion, the output is automatically transferred to a dedicated output directory or to any other location described in the job output files.

Below, we give details of the ganga’s current job-handling capabilities and the main graphics features: the GUI and the job-options editor.

### IV.2 Core, application and job handlers

The job registry (described in II.2) keeps records, in the form of metadata, about all user jobs. It also allows operations on jobs, such as job creation, configuration, submission, termination, and provides the job monitoring service. For job serialization, the registry uses a job catalogue, which in turn maintains the information about all saved jobs etc.

Each user job is represented by an instance, which contains information about the job state, and references to the requirements, application and handler objects. The specific steps required for job configuration, submission, and monitoring, which differ for each computing system, are delegated to a job handler.

In order to complete a step, the handler uses the requirements, which are common by design, and it adds its own attributes that are relevant for the particular computing system. Examples of common requirements are minimal size of physical memory or minimal size of available disk space, examples of specific attributes are queue time limits and bookkeeping accounts. For job monitoring, the handler provides information about the job state that is system dependent. ganga currently has components containing job handlers to work with the local computer, a local PBS or LSF batch system, or the EDG.

In the ganga design, a distinction is made between “jobs” and “applications,” in order to have the possibility to run the same application on different computing systems. An application in ganga terminology represents a computer program that the user wants to execute (the executable), together with any necessary configuration parameters, required input, and expected output files. The executable is specified by image location, name, and version. Application parameters, which may be files, include a type description with the actual value. The input and output files are described by their name and (desired) locations. Methods are available to get them from their storage location, and to transfer files to and from worker nodes, tailored to each of the supported computing systems. In ganga there is currently support for the local system copy command, the gridftp transfer protocol, and the EDG sandboxes mechanism. The transfer method is set up automatically by the job handler during the configuration of a job. An interface to the EDG Replica Catalogue to translate logical file names is also implemented, and future ganga releases will contain more advanced data management tools to work with the grid.

Like jobs, applications plug into the appropriate application handlers based on the type of application. Currently, ganga offers a generic application handler, which can be used with types of application, but with the disadvantage that it provides little help with configuration; a gaudi handler, for use with general applications written for the gaudi framework; and two handlers specific to davinci and atlfast.

### IV.3 Graphical user interface

The GUI, like the rest of Ganga, is implemented in python, and makes use of wxPython, the extension module that embeds the wxWindows platform independent application framework. wxWindows is implemented in C++, and is a layer on top of the native operating and windowing system. The design of the GUI is based on a mapping of major ganga core classes – jobs, applications, files, and so on – onto the corresponding GUI classes. These classes (GUI handlers) add the hooks necessary to provide interaction with the graphical elements of the interface, on the top of the functionality of the underlying core classes. The GUI component also includes some ganga specific extensions of standard wxWindows widgets (dialogues, panels, list and tree controls).

The basic display of the ganga GUI is shown in Fig. 2. The layout of the window consists of three main parts: there is a tree control on the left that displays job folders, which themselves may be folders, in their respective states. There is a multi-purpose panel on the right, which facilitates many displays (see also Fig. 3), and which in Fig. 2 consists of a list control. Finally, there is an embedded python shell (pycrust, itself designed for use with wxPython).

With the advanced (expert) view option on, the job folders, in the tree of job states, display a hierarchy of all job-related values and parameters. The most important values are brought to the top of the tree, less important ones are hidden in the branches. The normal (user) view stops at the level of jobs and gives access to the most important parameters only. The user can also choose to hide the tree control completely. The list control displays the content of the selected folder in the job tree. With a double mouse click it is possible to edit most of the values shown in this control list. The lower part of the frame is reserved for the python shell, which doubles as a log window. The shell does not only allow the execution of any python command, but it also permits access to, and modification of, any GUI widget. The shell, too, can be hidden if desired.

Actions on jobs can be performed through a menu, using a toolbar, or via pop-up menus called by a right click in various locations.

When the monitoring service is switched on, jobs move automatically from one folder to another as their states evolve. To avoid delays in the program response to the user input, the monitoring service runs on its own thread. It posts customized events whenever the state of a job changes and the display is to be updated. For GUI updates not related to job monitoring, ganga handles the standard update events posted by the wxWindows framework.

### IV.4 Job-options editor

The job-options editor (joe) has been developed in the context of the work on atlfast, and allows the user to customize atlfast jobs from within the ganga environment.

The main features of joe are summarized as follows:

* Joe, through its GUI (Fig. 3), assists the user in customizing atlfast job options from within ganga. This helps to eliminate human errors arising from incorrectly spelt options/values and incorrect syntax.

The user can define sequences/lists (e.g. TopSequence, Generator.Members, ApplicationMgr.DLLs, etc.) by enabling/disabling entries and arranging them in any desired sequence. Currently, there are no restrictions placed on these user-defined sequences for them to be meaningful.

Joe incorporates an option-type aware user interface presentation selector that essentially chooses the correct presentation format at run-time (e.g. drop-down menus for discrete choice options, arbitrary value entry for simple choice options, value appending for list-type options, etc.) for individual job options based on their attributes/characteristics.
* Job option settings for commonly performed jobs may be saved and reused. This saves the user the work of re-entering option values for subsequent jobs, especially if only minor modifications are needed. With default values for options built-in, the user is able to revert to the default settings when required.
* Once all the options have been set, the preview function allows the user to check that the created script is as required.
* In accordance with the basic ganga requirements, all functionality of the editor is available on the python command line without the GUI (not without a certain degree of visual inconvenience of course). Users and developers alike can make use of this API.

Since the current version of joe is very basic, improvements are in the pipeline:

* The editor is to be decoupled from the atlfast application handler and made available to be used in a generic gaudi environment. A generic editor can be used to perform job-option customization of full simulation, reconstruction and analysis jobs. To make this possible, the editor’s dependence on hard-coded python data structures must be removed and replaced with a database that can be queried.
* Option attributes that enable joe to dynamically choose appropriate presentation formats for individual job options are currently hard-coded into the data structure referred to above. Future versions will attempt to make deductions about job option attributes at run-time.
* With the foreseen decline in the use of text-based options files, the editor will support the creation of python scripts instead.
* Editable previews of options files, to allow the user to make last minute changes.
* The move from atlfast to full simulation and reconstruction will see at least a tenfold increase in the number of configurable job options. It will not be useful to display all options indiscriminately; some form of information hiding is required.

The “Favorite-options first” feature will further speed up the user’s task of job-options modifications by placing frequently used options at the top of the list and perhaps hide the not so frequently used ones.
* Although rudimentary option-value checks are performed, the more important range checking is not yet available. This feature requires permitted ranges (i.e. sensible values) of individual options to be attributes of individual options.

Joe showcases the extensibility of the ganga user interface. Future extensions can be developed and incorporated in the same way.

## V OUTLOOK

The first release of the ganga package has been made available, and user feedback is being collected from both Atlas and LHCb collaborators. The development schedule laid out for the remainder of calendar year 2003 is targeted at providing a product to satisfy requirements for the Atlas and LHCb data challenges. Cooperation and integration with existing projects (ask ref:ask , atcom ref:atcom , dirac ref:dirac , dial ref:dial ) is foreseen in order to meet in time these requirements. The ganga project will then continue to keep pace with and adapt to the ever-evolving grid middleware services.

###### Acknowledgements.

This work was partly supported by the Office of Science. High Energy Physics, U.S. Department of Energy under Contract No. DE-AC03-76SF00098.


text:
# Exploring QCD: from LEAR to GSI

## 1 Introduction

The title suggested for this invited talk included the phrase “Testing QCD”. To me this implies a rather better theoretical understanding of low-energy QCD spectroscopy than we have at present. As this largely historical overview will show, experimental discoveries in this field have repeatedly surprised theorists, and the resonances found often bear only a passing resemblance to our predictions. In light hadron spectroscopy, we are still exploring unknown territory.

The fact that we have so much to learn from experiment is one of the great attractions of this field. Although the starting point of the QCD lagrangian is universally accepted, even our best theoretical methods (specifically lattice gauge theory) currently involve uncontrolled approximations, and the resulting predictions need not closely resemble what is found experimentally in the real hadron spectrum. Progress in lattice gauge theory and in the development of models of hadrons continues to benefit from close comparisons to experiment.

Much of the recent experimental progress in hadron spectroscopy has come from nucleon-antiproton collisions, especially at LEAR. The parallel experimental efforts using meson beams, $`e^+e^{}`$ and other initial states have as always been valuable as independent confirmations of discoveries, or for suggestions regarding interesting final states for detailed studies. In this review I will sketch the history of our ideas regarding hadron spectroscopy, first as it was understood at the beginning of the LEAR program, then how it developed and was modified by results from LEAR and elsewhere, and finally where we stand today. I will conclude with a few suggestions for interesting topics that might be addressed at the future GSI antiproton facility.

## 2 Classification of hadrons

Our general classification of hadrons as color-singlet states of quarks and gluons has not changed since the early days of QCD. The simplest such states are the conventional quark model $`qqq`$ baryons and $`q\overline{q}`$ mesons, and we have ca. 102 examples of experimental resonances that appear to be well-described as such states.

In addition to these simplest possible color singlets, other combinations of quarks, antiquarks and gluons also span color singlets, and might in principle be expected to appear as resonances in the experimental light hadron spectrum. These include the $`q^2\overline{q}^2`$ multiquark states known as “baryonia”, pure glue basis states such as $`gg`$ and $`ggg`$ “glueballs”, and mixed quark-and-gluon states known as “hybrids”, which include $`q\overline{q}g`$ hybrid mesons and $`qqqg`$ hybrid baryons. Of course these simple basis states will mix when the quantum numbers allow, so that we expect the physical resonances to be strongly mixed linear combinations of such basis states. The level of configuration mixing and the types of basis state that best describe the physical resonances are at present open and poorly understood issues.

## 3 LEAR hadron physics goals

### 3.1 Baryonia: LEAR ab initio

The principal initial motivation for LEAR was to search for the novel “baryonium” $`q^2\overline{q}^2`$ mesons. These states had been studied in many models, such as the MIT bag model, quark potential models, color chemistry models, and so forth, and a very rich spectrum of discrete levels was predicted.

The purported connection of $`q^2\overline{q}^2`$ baryonium states to $`p\overline{p}`$ annihilation is quite interesting, because it introduces a crucial and still poorly understood topic, which is the nature of the short-ranged nuclear force. Progress in understanding this force should be a major goal of future studies in antiproton physics, for example at GSI. The argument leading to a strong coupling between $`p\overline{p}`$ annihilation and $`q^2\overline{q}^2`$ resonances was the belief that the short-ranged nucleon-nucleon repulsive core was due primarily to vector meson $`(\omega )`$ exchange. This was discussed for example by Richard  at the 1982 Erice LEAR meeting. If this description is accurate, one can presumably similarly describe the corresponding $`p\overline{p}`$ $`\omega `$-exchange force after a G-parity transformation, and an attractive core is found which supports deeply bound $`p\overline{p}`$ states. (Hence the name “baryonia”.) The connection to $`q^2\overline{q}^2`$ requires a bit more imagination. If one takes a quark line diagram for $`p\overline{p}p\overline{p}`$ with $`q\overline{q}`$ meson exchange in t-channel, and deforms the exchange so the $`q`$ and $`\overline{q}`$ lines are widely separated, one sees intermediate $`q^2\overline{q}^2`$ states in s-channel. Thus one can argue that if the short-ranged nuclear force is indeed due to t-channel vector meson exchange, there should be deeply bound $`p\overline{p}`$ states with a strong coupling to $`q^2\overline{q}^2`$. Since there were many models that suggested a rich spectrum of discrete $`q^2\overline{q}^2`$ levels in the 1970s, a rather undermotivated identification of bound $`p\overline{p}`$ states with $`q^2\overline{q}^2`$ was suggested.

Even more remarkably, it was widely suggested (with little support from theory) that these light $`q^2\overline{q}^2`$ resonances might be very narrow ($`\mathrm{\Gamma }_{tot}`$ = few MeV), and that these narrow states might be evident for example in the total $`p\overline{p}`$ cross sections. Ambiguous evidence for narrow baryonium candidates such as the “S(1936)” was frequently cited in the literature of the early 1980s . One of the clear experimental conclusions of the subsequent LEAR program was the absence of such narrow states .

Unfortunately the confining interaction required to give this discrete $`q^2\overline{q}^2`$ spectrum was a model artifact; $`q^2\overline{q}^2`$ states can in practice simply “fall apart” into two separate $`q\overline{q}`$ mesons when energetically allowed, and hence need not exist as resonances. This erroneous prediction of a rich spectrum of light multiquark resonances was referred to by Isgur as the “multiquark fiasco” .

We note in passing that for sufficiently large quark mass “heavy-light” $`Q^2\overline{q}^2`$ bound states do lie below these fall-apart thresholds, and hence should exist as resonances . However it is unclear whether $`c`$ quarks are sufficiently heavy to form such bound states; one might instead require a much more difficult study of the $`b^2\overline{q}^2`$ system.

The fact that predictions of light $`q^2\overline{q}^2`$ states relied on a meson-exchange model of short-ranged nuclear forces highlights the importance of understanding the physical mechanisms underlying these forces. An alternative description at the quark-gluon level, which has been confirmed by many independent theoretical calculations, finds instead that the nucleon-nucleon repulsive core is well described by the one-gluon exchange spin-spin contact interaction. If this picture is correct, there is no simple relation between the $`pp`$ and $`p\overline{p}`$ interactions, and there need not be deeply-bound $`p\overline{p}`$ bound states. Evidently these different models of interhadron forces lead to very different predictions of the bound state spectrum. It is clearly of great importance to determine which mechanism, if either, is dominant at short distances. Studies of the reaction $`p\overline{p}\mathrm{\Lambda }\overline{\mathrm{\Lambda }}`$ at LEAR have attempted to clarify this issue, and the most recent results were presented at this meeting. Unfortunately the conclusions are rather ambiguous at present; neither meson exchange nor quark-gluon models in their present incarnations give a good description of the data . This may not be surprising, since one would expect meson-exchange (e.g. kaon-exchange) to correctly describe the long-distance part of the interaction, but this picture should fail at sufficiently short distances where the baryon and antibaryon three-quark and three-antiquark wavefunctions experience considerable overlap.

### 3.2 Glueballs

Not long after the beginning of planning for the LEAR program, much interest arose in the possibility of observing gluonic excitations in the meson spectrum , in addition to the multiquark states that were the original motivation for LEAR. Theorists noted that color-singlet states could be formed in the pure glue sector from $`|gg,|ggg\mathrm{}`$ states, and in addition mixed quark-and-gluon color-singlet basis states such as $`|q\overline{q}g`$ were allowed. The associated resonances are now known as glueballs and hybrids respectively. Detailed predictions for the spectra of these states were published, most notably using the MIT bag model  and lattice gauge theory (LGT) .

Interest in glueballs at LEAR also arose from the experimental $`J/\psi `$ radiative decay program, which had identified the glueball candidates “$`\iota `$” (now the $`\eta (1440)`$, and excluded as a glueball due to its low mass) and the “$`\theta `$”, initially thought to be $`2^{++}`$ but now known as the $`f_0(1710)`$, and widely considered a scalar glueball candidate. It is amusing that LGT calculations at that time claimed $`0^+`$ and $`2^{++}`$ glueballs at masses of ca. 1420 and 1620 MeV respectively, consistent with these newly discovered states.

One might expect to find the most striking evidence of new states in the glueball sector, since these are the farthest removed physically from conventional $`q\overline{q}`$ states. In practice this does not appear to be the case. The theoretical “pure glue” glueball spectrum is now quite well understood from LGT studies , and is rather sparse at the energies of relevance to LEAR; the only glueball predicted to have a mass below 2 GeV is a scalar, at a mass of about 1.7 GeV. The next glueballs predicted with increasing mass are $`0^+`$ and $`2^{++}`$ states near 2.5 GeV; the first exotic encountered in the LGT glueball spectrum is a $`2^+`$ state, at a very high mass (near 4 GeV). As experimental studies of the light meson spectrum are almost exclusively concerned with the region below 2.5 GeV, the subject of glueballs specializes to the search for a single I=0 scalar state. Unfortunately, this sector is one of the most obscure in the light meson spectrum.

There are currently two candidates for the scalar glueball, the $`f_0(1500)`$ from LEAR and the $`f_0(1710)`$, originally reported in $`J/\psi `$ radiative decays.

The $`f_0(1500)`$ is clearly visible in the beautiful high-statistics $`p\overline{p}3\pi ^o`$ Dalitz plot shown in Fig.1, made famous by the Crystal Barrel Collaboration . This state may be the single most interesting discovery of the LEAR hadron physics program. As an “extra” I=0 scalar state near 1.7 GeV it is a natural glueball candidate, and the width of $`100`$ MeV appears anomalously small for a light 3P0 $`q\overline{q}`$ quark model state.

There are problems however with identifying either the $`f_0(1500)`$ or the $`J/\psi `$-radiative state $`f_0(1710)`$ with the scalar glueball. Naively one would expect approximate SU(3) flavor symmetry in the decay couplings of a glueball, which should lead to relative PsPs couplings of $`\pi \pi :KK:\eta \eta :\eta \eta ^{}:\eta ^{}\eta ^{}=3:4:1:0:1`$. (These are branching fractions divided by phase space.) Since the observed branching fraction ratios are $`B_{KK/\pi \pi }(f_0(1500))=0.19\pm 0.07`$ and $`B_{\pi \pi /KK}(f_0(1710))=0.39\pm 0.14`$, neither state decays with the nearly equal $`\pi \pi `$ and $`KK`$ branching fractions expected for a glueball. This problem may be due to mixing between $`q\overline{q}`$ and $`G`$ basis states , or it may imply that there is strong momentum dependence in these decay couplings.

### 3.3 Hybrids

Shortly after interest arose in the glueball spectrum it was realized that a rather richer spectrum of $`q\overline{q}g`$ “hybrid meson” states should also exist. There are many more experimental opportunities to search for hybrids than glueballs because (light) hybrids span flavor nonets, and it was also found that the lightest hybrid multiplet includes very characteristic $`J^{PC}=1^+`$ exotic quantum numbers . The bag model estimates for the mass of this light hybrid exotic were typically about 1.5 GeV. This work was followed by studies using the flux-tube model  and LGT , which find a rather higher mass of about 1.9-2.1 GeV for this $`1^+`$ exotic.

The flux-tube model has also been applied to strong decays of hybrids , which leads to the well-known flux-tube selection rule that light hybrids typically decay preferentially into S+P final states, in which one final $`q\overline{q}`$ meson has an orbital excitation. (Note however that the present exotic hybrid candidates do not support this rule.)

Experimentally there has been great interest in searching for the very characteristic $`J^{PC}=1^+`$ exotics, especially with I=1 flavor. Two such states have been reported, a $`\pi _1(1400)`$ and a $`\pi _1(1600)`$. Note that both candidates are rather lower in mass than the LGT and flux-tube expectations of $`M1.9`$-$`2.1`$ GeV. The $`\pi _1(1400)`$ (first reported by VES and BNL in $`\eta \pi `$  after a long history of studies of this channel) is the more controversial, since this is a rather weak, broad signal in a channel that is dominated by the $`a_2(1320)`$. This state has apparently been confirmed in $`p\overline{p}`$ annihilation at LEAR by the Crystal Barrel Collaboration ; it is notable that the coupling of $`p\overline{p}`$ to this candidate exotic is quite large, which argues in favor of $`p\overline{p}`$ facilities as an approach for the study of exotic mesons. The second $`J^{PC}=1^+`$ exotic candidate is the $`\pi _1(1600)`$, also reported by VES and E852 , in the channels $`b_1\pi `$, $`\eta \pi `$ and $`\eta ^{}\pi `$. The $`\pi _1(1600)`$ appears remarkably clearly in the recent analysis of the $`\eta ^{}\pi ^{}`$ channel by E852 , due largely to the weak coupling of $`\eta ^{}\pi `$ to other resonances in this mass region. (Fig.2 of this reference is our Fig.3; the $`\pi _1(1600)`$ is in panel $`c`$.) This very clear evidence for a $`J^{PC}`$-exotic is strong motivation for future searches for the flavor partners of this state, as well as the other $`J^{PC}`$ states expected near mass if this is indeed a light hybrid. The flux-tube model anticipates 72 approximately degenerate states in the lightest hybrid multiplet, and many of these should be narrow enough to be observable. If the partner states are not observed, the $`\pi _1(1600)`$ would appear doubtful as a hybrid candidate.

### 3.4 Quarkonia

Although the study of conventional $`q\overline{q}`$ mesons does not carry the same excitement as the discovery of new types of states, the identification of higher-mass $`q\overline{q}`$ mesons ($`q=u,d,s`$) has nonetheless been one of the most important experimental activities at LEAR and other hadron machines over the previous two decades. The identification of any anomalous states will be much easier if we have a reasonably complete description of the background of “ordinary” $`q\overline{q}`$ mesons. Since non-$`q\overline{q}`$ mesons are expected to first appear in the mass range 1.5-2.0 GeV, identification of the conventional quark model states over this mass range is a correspondingly important exercise.

Many of these $`q\overline{q}`$ states were unknown or poorly established until the last decade, and much progress has been made recently. For example, of the 44 $`n\overline{n}`$ mesons ($`n=u,d`$) predicted to lie below 2.1 GeV (spanning the 1S, 2S, 3S, 1P, 2P, 1D and 1F $`n\overline{n}`$ multiplets), about 35 have now been reported. Recent discoveries include candidates for the 2P and 1F multiplets that lie in the crucial 1.5-2.0 GeV mass range. These multiplets are now experimentally about 80% complete, which is comparable to how well we know the excited kaon spectrum in this mass range (ca. 16 of 22 states known). In comparison the $`s\overline{s}`$ spectrum is a terra incognita, with only about 6 of these 22 states well established.

We do note that there is evidence of disagreement between theory and experiment in the light quarkonium spectrum, notably in radial excitations. One important discrepancy is in the prediction of the energy scale of radial excitations of $`q\overline{q}`$ states. For example, Godfrey and Isgur  predicted that the 2P excitation of the light $`h_1(1170)`$ should lie at 1.78 GeV, whereas the candidate reported recently by E852 is at 1.59 GeV . The reports of possible hybrids near 1.4 and 1.6 GeV suggest that we may find a rich overpopulation of the meson spectrum relative to the predictions of the $`q\overline{q}`$ quark model beginning at about this mass. High-statistics partial wave analyses will be important for the identification of conventional $`q\overline{q}`$ mesons as well as the non-exotic hybrids, glueballs, multiquark systems, and mixing effects between these states that may be evident in this mass range.

## 4 From LEAR to GSI

To the extent that the intended purpose of LEAR was to identify new types of hadrons, it has been successful. We now have two glueball candidates, the $`f_0(1500)`$ (from LEAR) and the $`f_0(1710)`$, and two exotics, the $`\pi _1(1400)`$ (confirmed by LEAR) and the $`\pi _1(1600)`$. There is no clear evidence for multiquarks as originally proposed. We note in passing however that the $`f_0(980)`$ and $`a_0(980)`$ states were clearly observed at LEAR, for example in $`p\overline{p}\eta \pi \pi `$, and are widely believed to have large multiquark components. The closely related and crucially important subject of the nature of short-ranged nuclear forces remains under investigation, for example using LEAR data on $`p\overline{p}\mathrm{\Lambda }\overline{\mathrm{\Lambda }}`$.

Regarding glueballs and hybrids, the existing experimental candidates represent a rather thin and ambiguous beginning to what should eventually become a rich field of spectroscopy. Neither glueball candidate decays according to expectations for a flavor singlet, which suggests that mixing between glueball and $`q\overline{q}`$ basis states may be very important. Of the 72 resonances expected in the lightest hybrid multiplet near 1.9 GeV, we have just two candidates for 1 exotic hybrid (the $`\pi _1`$ level), and in neither case do the reported decay modes agree with theoretical expectations for hybrids.

In conclusion, what we have from LEAR is “proof of principle”. An overpopulation of light scalars exists, giving us glueball and multiquark/molecule candidates, and $`J^{PC}`$-exotic mesons exist, giving us exotic hybrid candidates. However there is thus far little evidence for the partner states that should also be present if these are indeed glueball and hybrid states. A primary task for GSI will be to confirm or refute the existing gluonic candidates, establish their strong branching fractions and other characteristic properties, and search for multiplet partner states with other flavors (u,d,s,c)  and $`J^{PC}`$ quantum numbers that must also exist if LEAR’s discoveries are indeed gluonic hadrons.


text:
# LCIO - A persistency framework for linear collider simulation studies

## I INTRODUCTION

### I.1 Motivation

Most groups involved in the international linear collider detector studies have their own simulation software applications. These applications are written in a variety of languages and support their own file formats for making data persistent in between the different stages of the simulation (generator, simulation, reconstruction and analysis). The most common languages are Java and C++, but also Fortran is still being used. In order to facilitate the sharing of results as well as comparing different reconstruction algorithms, a common persistency format would be desirable. Such a common scheme could also serve as the basis for a common software framework to be used throughout the international simulation studies. The advantages of such a framework are obvious, primarily to avoid duplication of effort.

LCIO is a complete persistency framework that addresses these issues. To that end LCIO defines a data model, a user interface (API) and a file format for the simulation and reconstruction stages (fig. 1).

### I.2 Requirements

In order to allow the integration of LCIO into currently existing software frameworks a JAVA, a C++ and a Fortran version of the user interface are needed. The data model defined by LCIO has to fulfill the needs of the ongoing simulation studies and at the same time be flexible for extensions in order to cope with future requirements. It has become good practice to design persistency systems in a way that hides the actual implementation of the data storage mechanism from the user code. This allows to change the underlying data format without making nontrivial changes to existing code. In particular when writing software for an experiment that still is in the R&D phase one has to anticipate possible future changes in the persistency implementation.

There are three major use cases for LCIO: writing data (simulation), reading and extending data (reconstruction) and read only access (analysis). These have to be reflected by the design of the user interface (API).

One of the most important requirements is that an implementation is needed as soon as possible. The more software which has been written using incompatible persistency schemes, the more difficult it will be to incorporate a common approach. By choosing a simple and lightweight design for LCIO we will be able to keep the development time to a minimum.

## II DATA MODEL

Before going into the details of the software design and realization of LCIO we need to briefly describe the data model. One of the main goals of LCIO is the unification of software that is used in the international linear collider community. Thus the data model has to fulfill the current needs of the different groups working in the field as well as being expandable for future requirements.

Figure 2 shows the data entities that are defined by LCIO. The attributes currently stored for each entity basically form a superset of the attributes used in two simulation software frameworks, namely the Java based hep.lcd ref\_heplcd  framework, used by some U.S. groups and the European framework - consisting of the Mokka ref\_mokka  simulation and Brahms ref\_brahms  reconstruction program. These two frameworks are also the first implementors of LCIO. As other groups join in using LCIO, their additional requirements can be taken into account by extending the data model as needed. A detailed description of the attributes can be found at ref\_lcio .

Various header records hold generic descriptions of the stored data. The Event entity holds collections of simulation and reconstruction output quantities. MCParticle is the list of generated particles, possibly extended by particles created during detector response simulation (e.g. $`K_s\pi ^+\pi ^{}`$). The simulation program adds hits from tracking detectors and calorimeters to the two generic hit entities TrackerHit and CalorimeterHit, thereby referencing the particles that contributed to the hit at hand. Pattern recognition and cluster algorithms in the reconstruction program create tracks and clusters - stored in Track and Cluster respectively - in turn referencing the contributing hit objects. These references are optional as we foresee that hits may be dropped at some point in time. So called ’particle flow’ algorithms create the list of ReconstructedParticles from tracks and clusters. This is generally done by taking the tracker measurement alone for charged particles and deriving the kinematics for neutral particles from clusters not assigned to tracks. By combining particles from the original list of reconstructed particles additional lists of the same type might be added to the event, (e.g. heavy mesons, jets, vertices). Objects in these lists will point back to the constituent particles (self reference).

## III IMPLEMENTATION

As mentioned in the previous section, LCIO will have a Java, C++ and a Fortran implementation. As it is good practice nowadays we choose an object oriented design for LCIO (III.1). The visible user interfaces (API) for Java and C++ are kept as close as this is feasible with the two languages (III.2.1). For Fortran we try to map as much as possible of the OO-design onto the actual implementation (III.2.2).

### III.1 Design

Here we give an overview of the basic class design in LCIO and how this reflects the requirements described in section I.2. One of the main use cases is to write data from a simulation program and to read it back into a reconstruction program using LCIO. In order to facilitate the incorporation of LCIO for writing data into existing simulation applications we decided to have a minimal interface for the data objects. This minimal interface has as small a number of methods as possible, making it easy to implement within already existing classes. Figure 3 shows

a UML class diagram of this minimal interface. The LCIO implementation uses just this interface to write data from a simulation program. The LCEvent holds untyped collections of the data entities described in section II. In order to achieve this for C++ we introduced a tagging interface LCObject, that does not introduce any additional functionality. LCFloatVec and LCIntVec enable the user to store arbitrary numbers of floating point or integer numbers per collection (e.g by storing a vector of size three in a collection that runs parallel to a hit collection one could add a position to every hit from a particular subdetector, if this was needed for a particular study).

The same interface can be used for read only access to the data. For the case of reading and modifying data, e.g. in a reconstruction program, we provide default implementations for every object in the minimal interface. These implementation classes also have set methods and can be instantiated by the user for writing LCIO data files.

Figure 4 shows the implementation LCEventImpl of the LCEvent interface together with the interface and implementation of the IO-classes. The LCWriter uses just the abstract interface of the data objects, thus not relying on the default implementation. The LCReader on the other hand uses the default implementations provided by LCIO. These are instantiated when reading events and accessed by the user either via the abstract interface, i.e. read only, or their concrete type for modification of the data.

The concrete implementations SIOWriter and SIOReader (III.3) are hidden from the user by exploiting a factory pattern. Therefore user code does not depend on the concrete data format. The interface of LCWriter is rather simple - it allows to open and close files (data streams) and to store event and run data. The LCReader interface allows to access data in several ways:

* read run by run in the file
\- provides no access to event information
* read event by event in the file
\- standard way of analyzing events in a simple analysis program
* quasi direct access to a given event
\- currently implemented using a fast skip mechanism (III.3)
* call-back mechanism to read run and event data
\- users can register modules that implement a listener interface (observer pattern) with the LCReader
\- these modules will be called in the order they have been registered
\- this can be used e.g. in a reconstruction program where one typically has separate modules for different algorithms that have to be called in a given order

When reading data, the minimal interface described above just provides access to the data in the form it had been made persistent. Sometimes it might be convenient to have different parameterizations of the data. Convenience methods providing the needed transformations (e.g. $`cos(\theta )`$ and $`\varphi `$ instead of $`p_x,p_y,p_z`$) could be added to the existing interface by applying decorator classes to the minimal interface.

### III.2 Technical Realization

#### III.2.1 Java and C++

The user interface for Java and C++ is defined with the AID ref\_aid  (Abstract Interface Definition) tool from freehep.org. It allows to define the interface in a Java like syntax with C++ extensions and automatically creates files with Java interfaces and headers with pure abstract base classes for C++. AID keeps the comments from the original files, thus allowing to use standard tools for documenting the source code and the user interface. We use javadoc ref\_javadoc  and doxygen ref\_doxygen 111doxygen allows to use the javadoc syntax for the Java and C++ implementation respectively. The current API documentation can be found on the LCIO homepage ref\_lcio .

Starting from a common definition of the interface for the two languages, one could think of having a common implementation underneath in either Java or C++. Frameworks exist that allow calling of either language from within the other, e.g. JNI to call objects coded in C++ from Java. The advantage for the developers clearly is the need to develop and maintain only one implementation. But this comes at the price of having to install (and maintain) additional libraries for the user community of the other language. In particular one of the great advantages of Java is the machine independence of pure Java which would be lost when using JNI. This is why we decided to have two completely separate implementations in either language - commonality of the API is guaranteed by the use of AID and compatibility of the resulting files has to be assured by (extensive) testing.

#### III.2.2 Fortran

In order to support legacy software, e.g. the Brahms ref\_brahms  reconstruction program, a Fortran interface for LCIO is a requirement. Another reason for having a Fortran interface is the fact that a lot of physicists have not yet made the paradigm switch towards OO-languages. So to benefit from their knowledge one has to provide access to simulated data via Fortran. Almost all platforms that are used in High Energy Physics have a C++ development environment installed. Thus by providing suitable wrapper functions it is possible to call the C++ implementation from a Fortran program without the need of having to install additional libraries.

Fortran is inherently a non-OO-like language, whereas the the API of LCIO is. In order to mimic the OO-calling sequences in Fortran we introduce one wrapper function for each objects’ member function. These wrapper functions have an additional integer argument that is converted to the C++ pointer to the corresponding object. By using INTEGER\*8 for these integers we avoid possible problems on 64 bit architectures (as by specification there is no guarantee that C++ pointers and Fortran INTEGERs are the same size). Two additional functions are needed for every object: one for creating and one for deleting the object. The wrapper functions are implemented using the well known cfortran.h ref\_cfortran  tool for interfacing C++ and Fortran. By applying this scheme Fortran users have to write code that basically has a one to one correspondence to the equivalent C++ code. This will facilitate the switching to Java or C++ in the future.

### III.3 Data format

As a first concrete data format for LCIO we chose to use SIO (Serial Input Output). SIO has been developed at SLAC and has been used successfully in the hep.lcd framework. It is a serial data format that is based on XDR and thus machine independent. While being a sequential format it still offers some OO-features, in particular it allows to store and retrieve references and pointers within one record. In addition SIO includes on the fly data compression using zlib. SIO does not provide any direct access mechanism in itself. If at some point direct access becomes a requirement for LCIO it has to be either incorporated into SIO or the underlying persistency format has to be changed to a more elaborated IO-system.

## IV Summary and Outlook

We presented LCIO, a persistency framework for linear collider simulation studies. LCIO defines an extensible data model for ongoing simulation studies, provides the users with a Java, C++ and Fortran interface and uses SIO as a first implementation format. The hep.lcd framework in the US and the European framework - based on Mokka and Brahms \- incorporate LCIO as their persistency scheme. The lightweight and open design of LCIO will allow to quickly adapt to future requirements as they arise. Agreeing on a common persistency format could be the first step towards a common software framework for a future linear collider. We invite all groups working in this field to join us in using LCIO in order to avoid unnecessary duplication of effort wherever possible.