abstract: Several recent studies have considered modifications to the standard weakly-interacting massive particle (WIMP) scenario in which the cross section (times relative velocity $v$) for pair annihilation is enhanced by a factor $1/v$. Since $v\sim10^{-3}$ in the Galactic halo, this may boost the annihilation rate into photons and/or electron-positron pairs enough to explain several puzzling Galactic radiation signals. Here we show that if the annihilation cross section scales as $1/v$, then there is a burst of WIMP annihilation in the first dark-matter halos that form at redshifts $z\sim100-200$. If the annihilation is to gamma rays in the energy range $100\,\mathrm{keV}-300\,\mathrm{GeV}$, or to electron-positron pairs in the energy range $\mathrm{GeV}-2\, \mathrm{TeV}$, then there remains a contribution to the diffuse extragalactic gamma-ray background today. Upper limits to this background provide constraints to the annihilation cross section. If the photon or electron-positron energies fall outside these energy ranges, then the radiation is absorbed by the intergalactic medium (IGM) and thus ionizes and heats the IGM. In this case, cosmic microwave background constraints to the ionization history also put limits on the annihilation cross section.
author: Marc Kamionkowski$^1$ and Stefano Profumo$^2$
date: 2024-10-03
title: Early Annihilation and Diffuse Backgrounds in $1/v$ WIMP models

In the standard weakly-interacting massive particle (WIMP) scenario , dark matter is composed of particles that have electroweak interactions with ordinary matter. Such particles cease to annihilate to standard-model particles in the primordial plasma to produce a cosmological relic density that is generically in the ballpark of that required to account for the dark matter. The most widely studied WIMPs are the neutralino, the lightest supersymmetric particle in several supersymmetric extensions to the standard model , and, more recently, the lightest Kaluza-Klein particle in models with universal extra dimensions .

Typical values for the WIMP mass are $m_\chi \sim 10\,\mathrm{GeV}-
{\mathrm{few}}~\mathrm{TeV}$, and freezeout of annihilations (chemical decoupling) occurs at temperatures $T_f\sim m_\chi/20$. After freezeout, the WIMP temperature remains fixed to the temperature of the primordial plasma via frequent elastic scattering from standard-model particles. When the temperature drops below the kinetic-decoupling temperature $T_{\mathrm{kd}}$, which generally falls in WIMP models in the range $T_{\mathrm{kd}}\sim10~\mathrm{MeV}-\mathrm{few}\, \mathrm{GeV}$ , WIMPs kinetically decouple from the plasma, and their temperature subsequently decays with the scale factor $R$ as $R^{-2}$, rather than $R^{-1}$. Afterwards, WIMPs are effectively collisionless; they behave in the subsequent Universe like the cold dark matter required to account for detailed measurements of the cosmic microwave background (CMB) and large-scale structure.

There still remains the possibility, though, that once galactic halos form later in the Universe, a tiny fraction of WIMPs could annihilate to produce cosmic gamma rays or cosmic-ray antiprotons or positrons that might be observed . In the standard WIMP scenario, the annihilation cross section (times relative velocity $v$) can be cast as $$\label{eq:std}
     (\sigma v)_{\mathrm{ann}}\simeq a + b (v/c)^2 +\cdots.$$ Roughly speaking, this cross section must evaluate at $v\sim
c/2$ to $(\sigma v)_{\mathrm{ann}} \simeq
3\times10^{-26}\,{\mathrm{cm}}^3~{\mathrm{s}}^{-1}$ to obtain the correct relic density, while annihilation in the Galactic halo occurs at $v\sim10^{-3}$, where $(\sigma v)_{\mathrm{ann}} \simeq a
\lesssim 3\times10^{-26}\,{\mathrm{cm}}^3~{\mathrm{s}}^{-1}$. The fluxes of cosmic rays from WIMP annihilation are thus generically expected to be very small; detection would require some mechanism to boost the annihilation rate typically by a few orders of magnitude .

In recent years, there have been several unidentified Galactic radiation backgrounds. These include a diffuse synchrotron haze around the Galactic center in the WMAP data ; a 511-MeV gamma-ray excess from the Galactic center ; an excess high-energy gamma-ray background from the Galactic center ; and most recently, a reported detection of an upturn in the cosmic-ray positron fraction at high energies . Efforts have been made to explain each one (or sometimes several) of these Galactic radiation backgrounds in terms of WIMP annihilation. In each case, though, some mechanism to boost the annihilation rate, relative to the natural expectation, has been introduced.

One way to boost the annihilation rate is to alter the underlying particle theory so that the WIMP annihilation cross section (times relative velocity) goes as $1/v$ (rather than to a constant, as in the standard scenario) as $v\rightarrow0$. Such a cross section is consistent with $s$-wave unitarity as long as $(\sigma v)_{\mathrm{ann}} \leq
4\pi/(m_\chi^2 v)$ as $v\rightarrow0$. Even larger annihilation cross sections are conceivable if higher partial waves contribute. Specific mechanisms for providing a low-velocity enhancement include the Sommerfeld enhancement and/or the formation of bound particle-antiparticle states in which the particles then annihilate although the functional dependence is not always precisely $1/v$, an issue we elaborate on further below.

Here we parametrize the $1/v$ enhancement by writing $(\sigma v)_{\mathrm{ann}} = 3\times10^{-26}\,
\sigma_{26}(c/v)\,{\mathrm{cm}}^3~{\mathrm{s}}^{-1}$, and we refer to these models as "$1/v$ WIMP models," or just "$1/v$ models." Since the cross section at freezeout required to obtain the relic abundance is roughly $3\times10^{-26}\,{\mathrm{cm}}^3~{\mathrm{s}}^{-1}$, we infer that the parameter $\sigma_{26}$ must be $\sigma_{26}
\lesssim 1$ or else the WIMP abundance will be too small. The equality is obtained if there are no other contributions to the annihilation cross section; $\sigma_{26}$ could be smaller if there are other contributions, such as those in Eq. (), to the annihilation cross section.

We can make the relic-abundance constraint to $\sigma_{26}$ more precise by including the $1/v$ dependence of $(\sigma
v)_{\mathrm{ann}}$ in the solution to the Boltzmann equation . Doing so, we estimate the relic abundance of $1/v$ models as $$\frac{\Omega_\chi h^2}{0.1} \simeq \frac{1}{2} \sqrt{\frac{\pi}{x_f}}
\frac{1}{\sigma_{26}}$$ with $x_f=m_\chi/T_f \sim 20$. This implies $\sigma_{26}\lesssim0.2$ to explain the observed dark-matter density, the inequality occurring, again, if there are other contributions to the annihilation cross section.

We now describe the bounds to this scenario that arise from upper limits to the diffuse extragalactic gamma-ray background and from CMB constraints to the ionization history. After the Universe becomes matter dominated, perturbations in the cold-dark-matter density are amplified via gravitational infall. The smallest structures undergo gravitational collapse first, and then more massive structures collapse later. The kinetic coupling of WIMPs at temperatures $T_f
\gtrsim T \gtrsim T_{\mathrm{kd}}$ erases primordial structure on mass scales smaller than $$M_c \simeq 33 \, (T_{\mathrm{kd}}/10\,\mathrm{MeV})^{-3} \, M_\oplus.$$ The first gravitationally-bound structures in the hierarchy therefore have masses $M_c$. The first objects collapse at a redshift that can be approximated over the range $10^{-6}\,
M_\oplus \lesssim M_c \lesssim 100\,M_\oplus$ relevant for WIMPs by $z_c = 140 -\log_{10}
(M_c/M_\oplus)$.[^1] These protohalos collapse to a virial density $\rho$ that is $\approx178$ times the mean cosmological density at the collapse redshift $z_c$. The velocity dispersion in the protohalos can be approximated by $v\sim R/t$, where $t\sim(G\rho)^{-1/2}$ is the dynamical time and $R \sim (M/\rho)^{1/3}$ is the size of the halos. Thus, $v\sim M^{1/3} G^{1/2} \rho^{1/6}$. Numerically, the first halos of mass $M_c$ that collapse at redshift $z_c$ will have velocity dispersions $$(v/c) \sim 6.0\times 10^{-9} \, (M_c/M_\oplus)^{1/3}
     (z_c/200)^{1/2}.
\label{eqn:velocity}$$

The rate at which WIMPs annihilate in this first generation of halos is $\Gamma = n_\chi (\sigma v)_{\mathrm{ann}}$, which evaluates to $$\Gamma = 2.2\times10^{-17} \left(\frac{M_c}{M_\oplus} \right)^{-1/3}
     \sigma_{26} B_{2.6} \left(\frac{z_c}{200} \right)^{5/2}
     \left(\frac{m_\chi}{\mathrm{TeV}} \right)^{-1}\, {\mathrm{s}}^{-1}.
\label{eqn:rate}$$ Here we have included a boost factor , $$B\equiv \frac{\int \rho^2 dV}{V \rho_v^2} = \frac{ c_v^3
     g(c_v)}{3[f(c_v)]^2},$$ for a Navarro-Frenk-White density profile , where $c_v$ is the concentration parameter, $g(c_v)=(1/3)[1-(1+c_v)^{-3}]$, and $f(c_v)= \ln c_v -
c_v/(1+c_v)$. This boost factor takes into account the increase in the annihilation rate due to the fact that the dark matter is distributed in these first halos with an NFW density profile $\rho(r)$, rather than uniformly distributed with density $\rho$. The boost factor varies from $B=2.6$ for $c_v=1$ to $B=50$ for $c_v=10$. To be conservative, we adopt $B=2.6$, but include the $B$ dependence through the parameter $B_{2.6}\equiv
B/2.6$ in all subsequent expressions. Strictly speaking, one should also integrate $(\sigma v)_{\mathrm{ann}}$, which now depends on $v$, over the velocity distribution in the halo. Doing so might give an order-unity correction to the annihilation rate, Eq. (); we fold this theoretical uncertainty into the parameter $B_{2.6}$.

The first generation of halos survive roughly a Hubble time before they merge into slightly higher-mass (and lower-density) halos. The age of the Universe at redshifts $z\gg 1$ is $t
\simeq 2\times10^{14}\, (z_c/200)^{-3/2}\, {\mathrm{s}}$. We thus infer that the fraction of dark-matter particles that annihilate in the first generation of halos is $$f \simeq \Gamma t \simeq 4.4\times10^{-3} \, \left(\frac{M_c}{M_\oplus} \right)^{-1/3} \sigma_{26} B_{2.6}
     \left(\frac{z_c}{200} \right)
     \left(\frac{m_\chi}{\mathrm{TeV}} \right)^{-1}.
\label{eqn:fraction}$$

Before considering bounds from diffuse radiation backgrounds, we note that a relatively weak bound to the parameter space can be obtained by noting that measurements of the CMB power spectrum constrain the matter density at recombination to be within 10% of its value today. We thus infer that $f\lesssim0.1$, independent of any knowledge of the annihilation products.

However, if $1/v$ models are introduced to explain Galactic radiation backgrounds, they require annihilation into $e^+e^-$ pairs and/or gamma rays. As shown in Fig. 2 of Ref. , photons injected with energies $E_i$ at redshifts $z_c \sim
100-200$ in the range $100\,\mathrm{keV}\lesssim E_i \lesssim300$ GeV propagate freely through the Universe, with energies that decrease with redshift as they propagate. They thus appear to us as a diffuse extragalactic background of gamma rays with energy $E_\gamma=E_i/z_c$. Photons injected at $z\sim100$ with energies $E_i\lesssim 100$ keV propagate at first through the Universe but then get absorbed at lower redshift by the intergalactic medium (IGM). Photons injected with energies $\gtrsim300$ GeV get absorbed immediately by the IGM.

Electron-positron pairs injected into the Universe at redshifts $z\sim100-200$ with energy $E_e$ very rapidly inverse-Compton scatter CMB photons resulting in a gamma ray of energy $E_i
\sim (E_e/m_e)^2 T_{\mathrm{CMB}}$, where $T_{\mathrm{CMB}}\sim10^{-2}$ eV is the characteristic CMB-photon energy at these redshifts. Thus, electron-positron pairs injected with energies in the range $\mathrm{GeV}\lesssim E_e
\lesssim 2\, \mathrm{TeV}$ produce photons in the energy range $100\,
\mathrm{keV}\lesssim E_i \lesssim 300\, \mathrm{GeV}$ of the transparency window; these gamma rays then appear to us as a diffuse background. Electrons injected at $z\sim100-200$ with energies $E_e\lesssim$GeV get absorbed by the IGM at low redshifts, and those at $E_e \gtrsim 2$ TeV are absorbed by the IGM immediately at high redshift.

If the photons (or electron-induced photons) are not absorbed by the IGM, then the energy density in photons today from WIMP annihilation in the first halos is simply $\rho_\gamma =
f\rho_\chi^0/z_c$; i.e. the fraction of the WIMP energy density that gets converted to radiation through annihilation, scaled by the redshift of the photons. This evaluates numerically to[^2] $$\rho_\gamma = 2.64 \times10^{-11} \,
     \left(\frac{M_c}{M_\oplus} \right)^{-1/3}
     \sigma_{26} B_{2.6} \left(\frac{m_\chi}{\mathrm{TeV}} \right)^{-1} \,
     \mathrm{GeV}~{\mathrm{cm}}^{-3}.$$ We now compare this with the upper limit $\rho_\gamma \lesssim
5.7 \times10^{-16} \, (E_\gamma/\mathrm{GeV})^{-0.1}\, \mathrm{GeV}~{\mathrm{cm}}^{-3}$ to obtain the constraint, $$\sigma_{26} \lesssim 2.2 \times 10^{-5} \, B_{2.6}^{-1}
     \left(\frac{M_c}{M_\oplus}
     \right)^{1/3} \left(
     \frac{E_\gamma}{\mathrm{GeV}} \right)^{-0.1}
     \left(\frac{m_\chi}{\mathrm{TeV}} \right).
\label{eqn:limit}$$ The EGRET upper bound used here is derived for $30\, \mathrm{MeV}
\lesssim E_\gamma \lesssim 100\,\mathrm{GeV}$. It is a fit to the extragalactic gamma-ray background, much of which comes from unresolved astrophysical sources, and so it should be viewed as a conservative upper limit. Moreover, the recently launched Fermi-GLAST telescope should soon significantly improve the upper limit to this gamma-ray background. Eq. () is valid as a conservative upper limit all the way down to energies $\sim$keV. The true upper limits from x-ray- and gamma-ray-background measurements in the energy range $10\,\mathrm{keV}\lesssim E_\gamma
\lesssim 30\,\mathrm{MeV}$ are more stringent. Notice that the limit in Eq. () does not depend on the collapse redshift $z_c$.

There will continue to be WIMP annihilation during later, more massive, stages in the structure-formation hierarchy. These will produce higher-energy photons (since they get redshifted less), but the energy density in these higher-energy photons will be far smaller. This can be seen from Eq. () by noting that the factor $M_c$ that appears therein will be replaced by $M_*(z)$, the characteristic halo mass at redshift $z$ (interestingly enough, all other redshift dependence in that equation cancels). The mass scale $M_*(z)$ evolves very rapidly with $z$; e.g., it goes from $10^{-12}\,M_\odot$ to $10^{-4}\, M_\odot$ from $z\simeq200$ to $z\simeq100$, and then all the way to $\sim10^{14}\,M_\odot$ at $z=0$. The constraint to the model from the diffuse-background flux is thus strongest from the earliest halos.

Let's now consider what happens if the photon (or electron-induced photon) falls outside the transparency window; i.e., if it is injected with energy $E_i \lesssim 100$ keV or $E_i\gtrsim300$ GeV. In both cases, the photons are absorbed by the IGM before they can reach us, and so there is no constraint from diffuse backgrounds. In both cases, though, very stringent constraints arise from measurements of CMB temperature and polarization . The energy deposited in the IGM by the photons ionizes and heats the IGM. The reionized electrons scatter CMB photons thus altering the observed CMB temperature/polarization power spectra. Ref.  carried out detailed fits to WMAP3 and large-scale-structure data to constrain the heating/ionization of the IGM. We infer from Fig. 2 in Ref.  that no more than a fraction $f\lesssim 10^{-9}$ of the rest-mass energy of the dark matter could have been injected into the IGM at a time $\sim10^{15}$ sec after the big bang. Although the analysis is detailed, the magnitude of the upper limit can be understood relatively simply: Dark matter outweighs baryons by a factor of 6, and it requires a fraction $(10\, {\mathrm{eV}}/\mathrm{GeV}) \sim
10^{-8}$ of the rest-mass energy of each atom to ionize it.

Thus, if dark matter annihilates to photons with energies $E_i\gtrsim 300$ GeV or to electron-positron pairs with energies $E_e \gtrsim2$ TeV, then we require $$\sigma_{26} \lesssim  2.3\times 10^{-7}\,
     \left(\frac{M_c}{M_\oplus} \right)^{1/3} B_{2.6}^{-1}
     \left(\frac{z_c}{200} \right)^{-1}
     \left(\frac{m_\chi}{\mathrm{TeV}} \right).
\label{eqn:CMBbound}$$ The result for photons injected with energies $E_\gamma\lesssim
100$ keV (or electron-positron pairs with $E_e\lesssim$GeV) is similar, but weakened possibly by the redshift of the photon energy that occurs between the time it was injected and the time it was absorbed. The detailed suppression depends on the injected energy and redshift. However, in no case is the suppression stronger than a factor $z_c^{-1}$. We thus conclude that the bound will be no more than two orders of magnitude weaker than that quoted in Eq. ().

To summarize: There will be a burst in $1/v$ WIMP models of annihilation in the first gravitationally bound dark-matter halos when they first form at redshifts $z\sim100-200$. There is a weak, albeit final-state–independent, CMB bound that amounts to demanding that no more than $\sim10\%$ of the dark matter annihilates after recombination. If the WIMP annihilates to photons in the energy range $100\, \mathrm{keV}\lesssim E_i \lesssim 300$ GeV or to electrons in the energy range GeV$\lesssim E_e \lesssim 2$ TeV, then there are constraints, summarized in Eq. (), to the cross section for annihilation to $e^+e^-$ pairs and photons. If the photons or electrons are injected outside the transparency window, then there is a bound, quoted in Eq. (), that comes from CMB constraints to ionization of the IGM.

To clarify, the bounds to $\sigma_{26}$ in Eqs. () and () are to the cross section for annihilation to photons and $e^+e^-$ pairs, not to the total annihilation cross section. A large hadronic final state branching ratio is however greatly constrained by antiproton data . Note also that (i) $B_{2.6}$ is likely larger than unity, that (ii) $z_c$ is generally larger than 100 for typical WIMP models; and that (iii) $M_c$ is generally smaller than $M_\oplus$. The numerical values in Eqs. () and () will, for typical WIMP setups, generally be smaller. On the other hand, the numerical value in Eq. () may be larger for smaller $E_i$.

For the nominal WIMP values that we have chosen, the bounds are violated by 5-6 orders of magnitude, and the constraints are still $\sigma_{26} \ll 1$ for almost any combination of the parameters $E_\gamma$, $M_c$, and $z_c$ consistent with typical WIMP values. It is thus clear that something else must be invoked in a $1/v$ model to account for the suppression of the gamma-ray and/or ionization-history constraints.

First consider the Sommerfeld enhancement . The $1/v$ scaling is valid only for $(v/c) \gtrsim
(m_\phi/m_\chi)$, where $m_\phi$ is the mass of a light exchanged particle. At smaller velocities, the $1/v$ enhancement saturates at $m_\chi/m_\phi$. Our bounds can therefore be written for this model, roughly speaking, by including a factor $\mathrm{max}[1,(c/v)(m_\phi/m_\chi)]$, with $v/c$ evaluated from Eq. (), on the right-hand sides of our upper limits, Eq. () and (). Thus, for example, for our canonical values \[$m_\chi=$ TeV, $M_c=M_\oplus$, $z_c=200$, $B_{2.6}=1$\], our limits are unaltered for $m_\phi \lesssim
6$ keV. For larger $m_\phi$, they are reduced accordingly. For example, the CMB bound \[Eq. ()\] is weakened to $\sigma_{26}\lesssim 1$ (for our canonical values) for $m_\phi\gtrsim 26$ GeV.

We mention two ways to evade the bound, even if the $1/v$ scaling extends to $v=0$, one astrophysical, and one of particle-physics origin: The first possibility would be to speculate that the first microhalos that form at redshift $z\sim100-200$ remain largely intact through subsequent stages in the merger hierarchy. The Galactic halo would then consist of a huge number of distinct $\lesssim M_\oplus$ microhalos, each of which has a density $\sim 10^6$ times the mean halo density and velocity dispersion $\sim 10^6$ times the Milky Way velocity dispersion. In this way, a far larger ($\sim10^{12}$) boost factor could be obtained for annihilation in the Milky Way halo than the value $v^{-1}\sim10^3$ obtained by assuming a smooth halo. This would then allow a far smaller value $\sigma_{26}$ to produce the annihilation required to explain some of the unidentified Galactic radiation backgrounds. Smaller values of $\sigma_{26}$ would however require the $1/v$- *in*dependent terms in the annihilation cross section to obtain the correct relic abundance. This solution would require the survival of a significant fraction of early microhalos; the precise survival probability remains debated in the literature.

A second possibility is to design a model in which the cross section for a WIMP to elastically scatter from photons and neutrinos is also enhanced. This would allow the WIMP to remain in kinetic equilibrium until lower temperatures, resulting in a larger $M_c$ and a later stage in the structure-formation hierarchy. In turn, this would imply a suppression of the limits from the diffuse gamma-ray background (or the ionization of the IGM) accordingly. In the extreme scenario, dark-matter halos would not form until $z_v\sim10$, when the first halos and the stars they house would have had to form to reionize the Universe. We leave the construction of such models for future work.

We acknowledge useful comments from N. Arkani-Hamed, J. Feng, D. Finkbeiner, R. Gilmore, M. Pospelov, M. Ritz, and N. Weiner. This work was supported at Caltech by DoE DE-FG03-92-ER40701 and the Gordon and Betty Moore Foundation.

[^1]: This approximation is obtained with a scalar spectral index $n_s=1$. It will change slightly for $n_s\simeq0.95$. We include the $z_c$ and $M_c$ dependences separately in subsequent expressions so that a different $z_c$-$M_c$ relation can be used.

[^2]: Ref.  also considered the gamma-ray background from WIMP annihilation in the first objects, although they did not consider the $1/v$ enhancement.


author: P. de Laverny; A. Recio-Blanco
bibliography: Fluor_M22.bib
date: Received 2013; accepted
title: Revisited fluorine abundances in the globular cluster M 22 (NGC 6656)

Fluorine is a fairly good tracer of formation histories of multiple stellar populations in globular clusters as already revealed by several studies. Large variations in fluorine abundance in red giant stars of the globular cluster M 22 have been recently reported by two different groups. Futhermore, one of these studies claims that the abundance of fluorine is anti-correlated with sodium abundances in this cluster, leading to strong conclusions on the chemical history of M 22. To validate this important finding, we re-examine the F abundance determinations of some of the previously studied stars. We have reanalysed some high-resolution VLT/CRIRES spectra of RGB stars found in M 22 in order to re-estimate their fluorine abundance from the spectral synthesis of the HF line at 2.336$\mu$m. Unlike what has been previously estimated, we show that only upper limits or doubtful fluorine abundances with large uncertainties in M 22 RGB stars can be derived. This is caused by an incorrect identification of continuum fluctuations as the HF signature combined with a wrong correction of the stellar radial velocity. Such continuum fluctuations could be the consequences of telluric residuals that are still present in the analysed spectra. Therefore, no definitive conclusions on the chemical pollution caused by the M 22 first stellar generation can presently be drawn from the fluorine content of this cluster.

# Introduction

Fluorine is a chemical species of special interest in studies devoted to the evolution history of stellar populations for several reasons. For instance, (i) the nucleosynthetic origin of fluorine in the Universe is still debated with two main ranges of stellar masses proposed for its production site, and (ii) fluorine abundances may help disentangle the complex formation history of the globular clusters (GCs) by looking for the chemical pollution signatures of their first stellar population. Indeed, over the last decade, several studies devoted to the abundance of fluorine in different types of galactic and extragalactic stellar populations have shed new light on their chemical history .

In particular, the abundances of fluorine on the surface of some red giant branch stars (RGBs) of a few globular clusters have already been estimated. Most of these targeted GCs are metal-rich or have an intermediate metallicity (typically, \[Fe/H\]$<$ -1.2). For more metal-poor clusters, only upper limits of the fluorine content of NGC 6397 (\[Fe/H\] = -1.99) and M 30 (\[Fe/H\] = -2.33) have been reported up to now . Unfortunately, these too high upper limits avoid any derivation of any conclusive information on the chemical history of these clusters. It has also been shown that these F abundance upper limits in such metal-poor GCs are probably caused by inherent limitations of high-resolution $K$-band spectra collected with current telescopes and spectrographs.

In that figure, the only exception of fluorine abundance measurements (and not only upper limits) in metal-poor GCs is M 22 (NGC 6656) with a mean metallicity \[Fe/H\]$\sim$-1.7 dex. Recently, have indeed reported \[F/Fe\] ratio estimates in five RGB stars and upper limits in two other stars of M 22. Then, partly revised these abundances: their sample of six M 22 RGBs contains four stars already studied by . DLL13 show that the telluric substraction may partly explain their different estimates of F-abundances with respect to the previous study. These new abundance estimations allowed them to derive constraints on the masses of the first-generation stars that could have chemically polluted M 22.

However, our previous analysis of the fluorine content in metal-poor GCs has shown that F-abundances cannot be derived well in such clusters. In this research note and in to validate the F-abundances previously estimated in M 22, we thus re-examine some of the spectra collected by DLL13. We show that the fluorine content of M 22 RGB members cannot be safely estimated (see Sect. ). This leads us to conclude in Sect.  that the properties of the M 22 first-generation stars (as the range of masses of the main polluters) cannot currently be drawn from the fluorine content of this cluster.

# Analysis of M 22 RGB CRIRES spectra around the fluorine signature

We selected three RGB stars of the sample of DLL13 and re-analysed their spectra. We recall that these spectra were collected with the VLT/CRIRES instrument (see DLL13, for a description of the observations, their reduction and telluric features substraction). We point out that we re-analysed exactly the same spectra as DLL13 who performed the cleaning from the telluric contamination. In this note, we indeed only focus on the re-estimation of the fluorine abundances from these already reduced and cleaned spectra.

The selected targets are the stars *\#III-15, \#C*, and *\#III-52*. The first one has been estimated by DLL13 to be the most fluorine-poor (\[F/Fe\]=-1.0 dex) of their sample of six M 22 RGBs, whereas the other two are proposed as quite enriched in F (with \[F/Fe\]=-0.8 and -0.6 dex, respectively). Actually, it is claimed that the star *\#III-52* would be the most enriched in fluorine found so far in M 22.

The new fluorine abundances were estimated by adopting exactly the same methodology as in , which is actually identical to all our previous works devoted to F abundance determinations . We only recall that these abundance determinations are based on the synthetic modelling of the unblended HF(1-0) R9 line at 2.3358 $\mu {\rm m}$. We also adopted the same atmospheric parameters $T_{\rm eff}$, log($g$), \[Fe/H\], and $V_{\rm micro}$ as DLL13. The synthetic spectra were then broadened by convolution with a Gaussian profile of FWHM = 9 km/s to match the observed line widths.

We show in Fig. 1 the synthetic fits of the three selected spectra around the HF transition, assuming three different fluorine abundances spanning at least 1.3 dex. The largest of these abundances could actually be considered as an upper limit of A(F). From this Fig. 1, it can be clearly seen that no reliable fluorine abundances can be derived from these spectra. Indeed, if the stellar radial velocity is corrected well to match all the strong CO-lines (left panels of Fig. 1), no line feature can easily be identified at the right-hand HF-line position (see the plots in the right-hand panels of Fig. 1, showing a zoom around the HF-line). It can indeed be seen that large flux fluctuations are present around the HF line, whereas no features are predicted by the synthetic spectra in these almost perfectly line-free (continuum) regions of very metal-poor stars. Furthermore, these fluctuations have the same amplitude (a few percent) as the expected HF line in these stars. They could thus mimic the presence of the HF transition if examined over too narrow a spectral domain (see, for instance, Fig. 2 of DLL13) but, then, losing the right position for the CO lines. Therefore, for two of the stars shown in Fig. 1 (*\#III-15* and *\#III-52*), only an upper limit of their fluorine content could be estimated safely (A(F) $\le$ 2.3 and 2.65 dex, respectively). For the RGB star *\#C*, if the feature seen close to the HF-line position were real (although not exactly at the right wavelength), it could only be estimated that its F-content were found in a wide range \[2.0 - 2.6\]. However, we again point out that we cannot exclude that no HF-line signature at all is present in these three spectra characterized by continuum flux fluctuations at almost all wavelengths and with similar amplitudes as the supposed HF feature.

On the other hand, we think that these flux variations could be caused by the telluric contamination that cannot be perfectly cleaned in such spectra. Even with an optimized procedure to remove the telluric absorption lines, unfortunately for a cluster like M 22, the main telluric feature that contaminates the spectra in that spectral range has a wing that can still be strong around the HF position. Owing to possible limitations on the stability of CRIRES and/or the earth atmosphere, subtracting the two spectra (the RGB target and the telluric standard, i.e. a hot star) could artificially produce residuals with almost the same amplitude (1% to 2%) and position as the HF-transition. Then, this could lead to possible incorrect identifications of the faintest stellar features. Actually, this possible explanation is reinforced by examining Fig. 2 where we compare the spectra of the star *\#III-52* with and without telluric correction. We recall that this star is the F-richest of the DDL sample. It can be seen that the telluric absorption lines are large in this spectral domain and that all the continuum fluctuations seen in the cleaned *\#III-52* spectrum are located at the telluric absorptions. In particular, because of its radial velocity, the studied HF transition is located at a telluric line that absorbs $\sim$`<!-- -->`{=html}7% of the continuum flux. After telluric cleaning, several continuum fluctuations are still present. In particular, a continuum fluctuation can be seen with an amplitude as large as the expected HF line ($\sim$`<!-- -->`{=html}1%) but shifted by two to three pixels with respect to the right HF-line wavelength. This artefact could thus mimic an HF-line if the stellar radial velocity is not perfectly estimated with the neighbouring CO lines (see Fig. 1), and then corrected. Furthermore, this Fig. 2 can be compared to the Fig. 7 of DLL13 for the star *\#III-15* that has been proposed to be the most fluorine-poor of M 22 by these authors. It can be seen in their figure (lower panel) that the telluric contribution is almost null at the HF-line position, because of the *\#III-15* radial velocity. In this optimal case, one can note that DLL derive their lowest fluorine abundance, unlike their F-rich star *\#III-52* in which the telluric contribution is much greater and, as a consequence, much more difficult to clean.

# Conclusion

We have re-examined the spectra of three M 22 RGB stars already studied by DLL13. We showed that the presence of any HF-line signature is doubtful in these spectra and that, if any of these signatures were real, only high upper limits or a wide range of possible fluorine contents in M 22 RGB stars could be estimated. We also proposed that previous estimates of the fluorine content in this cluster are probably based on incorrect identification of the HF-transition, owing to (i) the presence of continuum fluctuations (probably caused by telluric residuals) that are as large as the sought HF line, and (ii) not enough accurate radial velocity corrections. Indeed, if the radial velocity is determined well using the neighbouring CO lines, no HF signatures are seen in these spectra, leading to a totally unknown fluorine content in this cluster.

Therefore, since the three selected targets reanalysed in this note span the whole range of fluorine abundances derived by DLL13, it can be concluded that no reliable information on the fluorine content in these M 22 RGB stars can be derived from the available spectra. It is thus impossible to claim that there is any fluorine-oxygen correlation and fluorine-sodium anti-correlation detected in M 22. This avoids any conclusion on any properties of the M 22 first-generation stars, such as the range of stellar masses of the probable main polluters.


author: Petr Kubánek
title: RTS2 – the Remote Telescope System

*RTS2* is an open source observatory manager. It was written from scratch in the C++ language, with portability and modularity in mind. Its driving requirements originated from quick follow-ups of *Gamma Ray Bursts*. After some years of development it is now used to carry tasks it was originally not intended to carry. This article presents the current development status of the *RTS2* code. It focuses on describing strategies which worked as well as things which failed to deliver expected results.

*Copyright 2010 Petr Kubánek. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.*

# Introduction

*RTS2* originates from *RTS*, *the Remote Telescope System*. *RTS* was written during years 1999 and 2000 as a team project for Computer Science courses by students of Mathematics and Physics faculty of Charles University in Prague.

*RTS2* is primarily developed on the *Ubuntu Linux* distribution. It is known to run on a wide variety of Linux distributions, the *Solaris* operating system and partially on *Microsoft Windows* and *Mac OS X*.

Project source code can be obtained from the Web site `http://rts2.org`. The project Wiki pages on `http://rts2.org/wiki` list group experiences with various fully autonomous observatory projects.

The outline of this paper is as follows: The first section is this introduction. The next section describes goals and history of the project development. The third section focus is a description of how various tasks inside *RTS2* are divided. The fourth summarises communication protocol. The next section describes approaches used during development. The sixth section forms the core of the article – it lists currently added features. The seventh section informs readers about currently running *RTS2* systems. The eighth is a reminder about our experiences with restarting failed devices. The contribution concludes with a section about expected developments.

# Project goals and its development

The original goal of the *RTS2* development was to produce software for a small robotic telescope, devoted to study Gamma Ray Burst (*GRB*) transients. The requirements of the project were:

-   must be fully autonomous

-   must react as fast as possible to incoming GRB alerts

-   must perform regular observations during periods with no GRB observation to verify system readiness

-   must be modular to enable easy switching of the instruments

Those requirements were laid in early 2000. They share similarities with other projects, notably *AudeLA* and the *Liverpool Telescope System*. At the time, open–source projects of similar scale did not exist. Available commercial, closed–source solutions were either associated with a single instrument, with questionable portability to others telescopes, or did not fulfill the requirement for fast switching between targets. It is worth noting that even today it is not easy to implement this requirement. It forms a strong entry barrier for those who would like to become *GRB* observers.

As the project advanced, additional requirements were added. They reflected experiences gained during development, and particularly pains and problems associated with early porting of the system to the other observatories:

-   system must be robust enough to continue operations even when non–critical part(s) fail

-   observer must have possibility to remotely interact with observations

-   system must be fully configurable using configuration files

-   system must provide clear description of what its components are performing

-   observer must be presented with a list of devices which failed

-   the code should include dummy device drivers for testing the software without hardware

Creation of dummy environments brings great benefits during system development. They enable developers to debug the system before it is deployed. There are still cases when errors and bugs are detected only during night runs. But as the project matures, the number of those cases significantly decreases – and there are recorded cases when new software, with significant new features, was deployed and it just worked, without any debugging.

As the number of observatories running *RTS2* grows, their management, fixing various small glitches, as well as their scheduling and data processing started to saturate staff time. We are aware of this, and we are in progress of creating tools which will allow us to manage network operations using a smaller amount of operators' time.

# RTS2 quick overview

*RTS2* is based on the *"plug and play"* philosophy. The parts which constitute the system can be started, restarted or stopped anytime, without affecting system performance. Special care is taken of resolving all possible blocking states, so the system will always respond to requests in reasonable time.

The whole system is user–space based and except for drivers provided either by hardware manufacturers or by our group, it does not require any kernel–space based components.

Code is designed around a central *select* system call, which picks any incoming messages. If there is no incoming message, class *idle* method is called. The code uses extensive hierarchy of its own C++ classes.

The *RTS2* system consists of the processes summarised in table . Figure shows processes and connections used on an example observatory, which includes three CCDs, two domes and a single weather station serving both domes. For a detailed description please see .

| **Process** | **Description** |
|:---|:---|
| centrald | Central component of the *RTS2* system. It provides three main services – a list of devices and services present in the system, system state changes and synchronisation among devices |
| devices | Corresponds to hardware attached to the observatory system. Different classes of devices are provided. They represents hardware coming from different manufacturers. |
| services | Represents execution logic of the system. They provides functions for the end user - carry observations, receive GCN and other alerts, enables XML-RPC[^1] based access to the system. |
| clients | Provides information to end–user. They are usually run in interactive mode, with end–user interacting with the programm. They include an interactive monitor and simple tools to execute observation scripts. |

RTS2 processes

# Communication protocol

*RTS2* employs its own communication protocol. A detailed protocol description can be found in . The protocol is based on sending ASCII strings over TCP/IP sockets. It is fast, simple and robust. Among its important features are:

-   sending of *"I am alive traffic"*, disconnecting connection if reply is not received - this removes connections to dead components

-   ability to switch to binary mode for data transfer, to transfer images and other large data items

-   traffic speed–up – values which were not changed are not transported

The protocol supporting libraries provides developers with a flexible and simple way to use common parts of the system. This results in a robust, transparent code, which can be easily extended. This greatly enhances software reuse. There are reasonable hopes and claims that the interfaces are simple enough to be understand by developers unfamiliar with the project.

# Coding style & philosophy

It is widely rumoured that there are as many approaches to coding as there are software developers. This section aims to list rules and customs used during *RTS2* development. Although most of them are widely known we hope they are worth mentioning.

The best documentation for the code is the code itself. Readers of this article are encouraged to check out the system and study it. Code with complexity of the *RTS2* project cannot be made completely transparent. It is not expected that the developer will understood code on the first encounter. It is important that he/she find interfaces being used. Later he/she can continue progressing towards system core classes.

### Track software changes in Version Control System

The project is tracked in Subversion[^2] tracking system. Previously version tracking relied on Concurrent Version System (CVS)[^3]. We have to admit that switch of the version control system to Subversion provides significant improvements, and we were really surprised with Subversion capabilities. Subversion really provides simply resolution for situations which were difficult or impossible to handle with CVS.

### Code releases

As the project is still under active development, a release formalism is yet not well established. There are usually two big releases during a year. All observatories are running Subversion code – code is regularly updated from Subversion and put to use. This way version management is also used for software distribution. We expect to calm this pace and establish a formal release mechanism.

### Development cycle – release early

Changes are usually committed to Subversion as soon as they compile without any errors. Before each commit, difference between new code and code in repository is reviewed. Sense and purpose of committed lines is examined once again.

This approach tracks vast majority of bugs right before they make it to the version control repository. After all changes are committed, and at least some documentation which explains new features is provided, behaviour of the code is tested once again. It is up to developer, where tests will be performed. Usually the system is tested on dummy devices, before moving to a real observatory. But small changes, which should introduce predictable results, are tested directly on observatories.

### Follow common practices

The common practices can be summarized by a few sentences, such as: Think twice, code once. Discuss with others, inform users about changes. Try to design a generic solution instead of a simple additions for new problems. Add new features slowly and test them before implementing another. Divide a complex problem to simpler subproblems, implement and test the solution for them first, and then integrate the code to solve the complex problem. Keep in mind that the best developers are able to design, code, test, and release no more then 100 lines per working day – try to keep number of lines small by reusing what is already available either in your code or in C++ libraries.

# Current developments

This section deals with features which were recently added to *RTS2*. The list provided bellow is not complete – please see project change–logs for a more in–depth description.

## State machines

*RTS2* uses state machines. The states represents various states of the hardware – for example camera can have idle, exposing and readout state.

The states were originally used for coding purposes, to distinguish various states of the code. They were displayed in monitoring applications, so the user was informed what the device should do.

Later state use was expanded toward synchronisations. States prevent the camera from taking exposures during telescope movement, and unwanted telescope movements during camera exposures. They are displayed on users displays, allowing observes to identify which device is blocking the next exposure or the next telescope movement. The use of states for synchronisation is depicted in figure .

## Default configuration

Originally *RTS2* did not change configuration of devices prior to observations. That leaves the user responsible for device configuration. He/She can do that using either a monitor application or a script for observation.

This handling was later extended by *RTS2* remembering default values. The command *script_ends* was added to the protocol. It loads back all changed values.

This code was successfully used for focusing. The system was able to change back to the last known good focuser position even when a focusing run was interrupted. But it starts to show its bottlenecks, notably:

-   unpredictable behaviour for the end user – he/she changes something, and suddenly another value appears in acquired images

-   unknown default values – system unfortunately does not show which values were changed

-   the system was quite hard to code, and as a consequence, quite hard to maintain

Various solutions were considered to resolve those bottlenecks. The following was selected as the best one:

-   when appropriate, the system offers default value and various offsets. The default value can be changed only on user request, and is never changed by the system. Offsets can be changed by user and/or system. Offsets are zeroed before beginning of the next observation.

-   or default values are provided only for values written in devices default configuration file.

Both cases can be best understood from an example. The first case can be best demonstrated on the new focuser interface and the second on handling mode settings on CCD.

### Offsets, default and target values

The interface provides end user with the following values:

-   **current value**, which is read from focuser

-   **target value**, equal to sum of values listed below

-   **default value**, set by the user

-   **focusing offset value**, settable by the user

-   **temporary focusing offset value**, settable by the user, zeroed at the end of the observing script

Changes of the last three values are used for user focuser interaction. The default value is changed when the user would like to significantly change focuser position. For example the offset can be set for different optical thickness of the filters. And temporal focusing offset is used in the focusing script to change the focuser position during focusing runs.

If a focusing run is interrupted, the focusing script finished, or the focusing program is disconnected, the temporal focusing offset is set by focuser driver to zero. Then a focuser new target value is calculated and used.

Similar control is used for the telescope. There offsets are used to command dithering from the target position.

### Camera acquisition modes

New modern cameras provide various settings. Some of the combinations of settings are very good for astronomy, while some are pretty bad. A desired behaviour of the system is to allow the user to set only good settings, avoiding the bad ones, while still leaving an option to set all variables manually.

A desired behaviour of the system will also switch the camera at the end of the script to a default mode so that the next script will be able to use camera, without changing any variable.

This functionality is provided by setting the camera mode back to default at the end of the script. A camera mode file provides various modes. The first is the default one, which is used to set camera. An example configuration file is included in the software distribution.

## Observatory scheduling

It is widely known that observatory scheduling is not a trivial problem. Scheduling is known to belong to NP–hard class of problems, which does not make the problem easier. On top of that, it is not always clear what exactly should be observed in order to maximise the scientific output of the observatory.

*RTS2* currently provides users with three scheduling modes: dispatch scheduling, queue scheduling and preprogrammed night plan. The advanced, genetic algorithm scheduling, which should be able to schedule full night runs, is in the late integration phase. The scheduling modes are described in the following sections.

### Dispatch scheduling

Dispatch scheduling is the kind of scheduling used on most, if not all fully autonomous observatories. Each observable target is assigned a merit function – its expected benefits. Dispatch scheduling then calculates merits for all targets, picks the one with the best merit, and observes it. After this target is finished, the scheduler recalculates merit functions, and picks a new target. This approach is discussed by multiple authors, notably and . *RTS2* provides this mode in the *selector* component.

### Queue scheduling

Queue scheduling schedules targets with the human – night observer in the loop. The night observer is presented with a list of possible targets, which are worth observing. Based on the current conditions, instrument setup and astronomer preferences, he/she picks a queue and executes its observation. After the target is finished, a new target is picked from the queue, or the queue is changed by the observer.

This scheduling is used by current big observatories – for example by ESO VLT, CAHA and IAC telescopes.

The observer can fill a queue of targets in the *RTS2 executor* component. There are plans to provide automatic selection from those targets – so the observer enters them in the evening, and the system will observe them during the night at optimal weather and time.

### Night plan

Another option is to provide a detailed night plan, which will list sequence of observations, their time and how images should be handled. Although *RTS2* does provide support for night plan, it does not provide any interfaces for plan creation and its management. The observer must fill a text file and load it into a database. Because of the complexity of this operation and lack of support tools this option is not widely used.

### Genetic Algorithm based scheduling

None of the scheduling modes discussed above is optimal. Dispatch scheduling lacks predictability and is short–sighted – it produces schedules which search for a local maxima, instead of focusing on long–term gains. Queue scheduling and night planning requires non–trivial involvement of the observer.

We proposed and implemented scheduling based on genetics algorithms (GA). The problem is described in full depth in . Here is outline of this approach.

Observation targets can list various constraints and merits. The algorithm then searches for the Pareto optimal front – a set of schedules which does not violate any constrains and their respective merit functions are at least comparable to the other best schedules. The search for this front is performed with NSGA-II.

Experimental implementation of GA scheduling is part of the current *RTS2* developer branch. The main benefits of GA scheduling are a simple addition of new constraints and merits. Ease of its reuse is demonstrated in .

The plan is either to provide the observer with Pareto front schedules and let him/her pick the one he/she likes, or to have system select autonomously during night the path which will be followed.

## Weather blocking

It is very important to close the observatory roof when conditions are hostile for its normal operations and keeping it closed as long as those conditions prevail. Our records clearly indicate that having the roof open with bad weather over it produces significant problems as soon as the wrong roof state is detected.

The following sections deal with this problem. First the original approach is described. This is followed by a detailed description of current hardware and software setup, which is protecting equipment against the elements.

### Original weather reporting

Keeping track of observatory conditions was originally a job of the dome module. It was regarded as a single point of failure. Dome code was handled with extreme care, and dome software was carefully tested after each software upgrade. Each device which might indicate bad weather sends information about weather state directly to the dome module. The dome module puts them together, decides if weather is favourable for the observation, and reacts accordingly - if all conditions were satisfied, it switched the system to "on" mode. If a single condition was not met, the dome control module tried to close the roof and switch the system to "standby" mode.

This solutions has the following problems:

-   dome software testing is time consuming

-   in case of a serious computer hardware problem the dome can be left open

-   every new weather sensor requires modifications to dome control software and extensive testing before being put in operation

### Design of the state based weather handling

As different new sensors were added to the observatory setup, it becomes clear that weather reporting deserves special attention. The following requirements were put for the new algorithm:

-   it must be easy to add new sensors for weather reporting

-   it must be possible to configure the system to include various sensors

-   the system must report bad weather in the event of a sensor failure

Apart from those software requirements, additional requirements were put on the hardware responsible for roof operations:

-   it must run independently from controlling computer

-   it shall be as reliable as possible

-   it shall be as simple as possible

-   it must close the roof on its own when it loses connection to its controlling computer

-   it must report to the computer the states of all sensors connected to it

The software and hardware implementation which fulfills all those requiremens is described in the next section.

### Current weather blocking

*RTS2* centrald and all devices have a state. When changed, the state is propagated to all connections.

One of the bits in the state represents bad weather. If that bit is set, it means that the component (in case of device) or whole system (in case of centrald) reports violation of observing conditions, and therefore asks for controlled system shutdown.

Centrald also holds a list of devices which are mandatory for observation. If any of the mandatory devices is not present, or do not reply to centrald requests, the system is switched to bad weather state. This presents developers with a very simple way to add a new weather sensor to the system. They can use methods for weather state manipulation provided in *SensorWeather* class.

The ultimate weather protection element is on most systems a programmable logic controller (PLC). The inputs of this hardware are connected to the various sensors carring information about the roof state. The outputs of the relay are connected to the motors responsible for roof operations. The PLC is conservatively programmed. It is actually harder to open the roof then to close it.

PLC can be controlled manually with switches. For an image of actual roof control panel please see figure .

If the computer would like to open the roof it must send signals every few seconds to the PLC, to check that it is alive. The PLC is programed to close the roof if this *"I am alive"* signal is not received.

The critical failure points of this setup are: motor failure, failure of power wire to motors and signals to PLC, PLC failure or power failure.

We do not have capability to make motors redundant. PLCs are designed for harsh industrial conditions. The PLC program is relatively simple and is very carefully tested. As its installation requires the presence of the person installing it on site, it is not sensitive to usual bugs introduced by system upgrades. Power backup is provided by UPS capable of closing the roof. The UPS state is monitored by *RTS2* and the roof is commanded to close if the remaining UPS uptime or battery level drops below a predefined values.

PLCs are also commodity value. In the unlikely event that the PLC is damaged or destroyed, a new can be purchased without significant problems on almost any place of the planet and installed within a few days from time the failure was detected.

Source code of the PLC program is available from *RTS2* subversion repository. As was shown by installing it on multiple sites, this setup is fully replicable and quite modular.

# RTS2 installations

Table provides list of the current *RTS2* installations together with the year they started using *RTS2* and current diameter of the primary optic. The full listing of *RTS2* installations is provided on project web pages.

| **Name**         | **Location**                  | **Year** | **D** |
|:-----------------|:------------------------------|---------:|------:|
| BART             | Ondr̂ejov, Czech Republic      |     2001 |  25cm |
| BOOTES 1         | INTA El Arenossilo, Spain     |     2002 |  30cm |
| BOOTES 2         | La Majora, Spain              |     2003 |  60cm |
| FRAM             | Pierre–Auger South, Argentina |     2004 |  30cm |
| Watcher          | Bloemfotein, South Africa     |     2005 |  40cm |
| BOOTES IR        | OSN, Sierra Nevada, Spain     |     2005 |  60cm |
| LSST CCD testing | BNL, New York, USA            |     2007 |       |
| Columbia         | UC, New York, USA             |     2007 |       |
| D50              | Ondr̂ejov, Czech Republic      |     2008 |  50cm |
| BOOTES 3         | Blenheim, New Zealand         |     2009 |  60cm |
| CAHA 1.23m       | CAHA, Spain                   |     2009 | 1.23m |
| LSST CCD testing | LPNHE Paris, France           |     2009 |       |

RTS2 installations

The system is currently being considered for various new and refurbished telescopes. Please note that 1.23m at CAHA is currently operated in semi–automatic mode, and *RTS2* is not on controls only during a few nights. More details about this can be found in .

# Coding strategy - to restart or to code properly?

At the beginning of the project, we sometimes employed a "last chance" strategy where if something fails [^4], the system will notice it, wait for a while and restart the failed part. Although this looked as very wise approach, it turned out that it hides potential serious problems and can affect system performance. Moreover, with errors in certain places it can produce situations when devices will keep restarting, produce a few lines in the system log, and exit.

Our experience is that the *if it fails, let system restart it and hope for the best* strategy is contra–productive and should not be employed. After fixing the most important bugs in the code, the programmes run on some setups for months without need for a single restart. If a problem is encountered, its root cause is found and fixed. A fixed driver is then installed and started with the remote ssh access.

The following things are vital for this strategy to work: compile all code with debugging option, change ulimit for core dumps to unlimited and knowledge of how to use *gdb*[^5] to find cause of the core dump. If all of the previous fails, have *valgrind*[^6] or a similar memory profiler installed, with knowledge of how to use it to find memory allocation problems.

Once the coder has managed all those issues, not only will the system operate smoothly, but he/she also will not be temped to switch to some language with a garbage collector[^7]. That is not to say that high-level languages are not fine for some jobs – we do use Python for GUI and Java/PHP for Web pages. But in our experience, for low–level, hardware control algorithms, nothing beats properly designed and coded C/C++ code.

# Expected project changes

Although *RTS2* is able to control autonomous observatories, there is still a lot which deserves more attention, some solutions and some coding. These items are presented in the following list.

### Image quality monitoring

The system currently provides some basic quality checks. Those includes results of a plate solving routine provided by Jibaro and/or Astrometry.net[^8] packages, so observers knows if telescope is pointing towards the expected position.

The system lacks real time display of various image quality parameters - average and median values, minimal and maximal values, number of detected objects (stars) in the image, and so on. Those are calculated and saved to the image header. Our experience shows that those should be easily accessible in real–time displays, as well as in tool for navigation through the image archive.

### Image processing

Image processing can be configured as an external script, providing relative photometry and other services. We would like to better integrate it with the system by:

-   adding calibration image database, and providing tools to maintain and use this database

-   providing observations–to–paper solutions for predefined well understood problems – among others observatorion of planetary transit occultations and micro–lensing events

### Better user interfaces

The system is primarily controlled through an ncurses based interface. While this is sufficient for experienced users, the interface is not well suited for occasional users.

Development of both Web and X-Windows Graphical User Interfaces is currently in initial phases. Plans also call for addition of applets for GNOME and other desktops environments, so we will be able to track telescope operations world–wide from a single desktop.

### Network management

The System currently lacks a central management console. Observatories are usually managed and monitored through ssh connections. While this approach is feasible, it quickly grows beyond the capabilities of a single maintainer.

There is a need for application, which will:

-   show states of individual observatories in the network

-   list unresolved problems of individual telescopes, keeping track of actions to fix the problem, and the results of those actions

-   enable scheduling of the whole network

-   synthesise results obtained by network members

It would be nice to have those features backed by simple, low-level, Internet interface. There is work in progress on an XML-RPC interface which will do just this.

### Archive access

*RTS2* keeps all important information in a database. Information about executed observations, and images acquired, together with basic image characteristics (which includes WCS coordinates, fitted by Jibaro and/or Astrometry.net) is recorded for quick retrieval.

Current archive access is provided primarily through console based utilities. Without doubt in this is a bit too old fashioned in the graphical user interfaces age.

There were PHP scripts for Web based archive access, which even included cut-out service. Unfortunately they were not very well designed. As the project matures and introduces changes to the database, those scripts cease to function, to the point when it was ruled to be too expansive to make them work again - as is the usual case with simple small fast PHP and other scripts.

Up to now multiple attempts to provide better solutions were made. Yet till now each of them has failed to deliver usable results.

Current attempts include a Google Web Toolkit XML-RPC backed application. We have reasonable hopes that this will deliver promised results, although not in a short timescale.

# Conclusions

This article presented an open-source system for robotic observatory control. It provides an overview of rationales for its development, its composition and its main features. It then focused on a list of recent improvements. The article concludes with lists of development items still left on the agenda.

*Acknowledgement* The author would like to acknowledge generous financial support provided by Spanish *Programa de Ayudas FPI del Ministerio de Ciencia e Innovación (Subprograma FPI-MICINN)* and European *Fondo Social Europeo*. Work on *RTS2* was supported, influenced and encouraged by numerous people, whose list would be too large for this article. Persons from this list which according to author deserve to be mention explicitly are Martin Jelínek, Alberto Castro-Tirado, Antonio de Ugarte Postigo, Ronan Cunniffe, Michael Prouza, René Hudec, Victor Reglero and Beatriz Sánchez Félix. The article was carefully reviewed by two anonymous referees, whose suggestions significantly improved it. Stephen Bailey made final gramatical improvements to the article.

[^1]: XML-RPC web site: `http://www.xmlrpc.com`

[^2]: Subversion web site - ` http://subversion.tigris.org/`

[^3]: CVS web site - ` http://www.nongnu.org/cvs/`

[^4]: which in our case usually means "produces core dump"

[^5]: GDB web site - `http://www.gdb.org`

[^6]: Valgrind web site - `http://www.valgrind.org`

[^7]: which promises to free developers from memory allocation problems – the most probable reason for failure of the C++ code

[^8]: Astrometry.net web site: ` http://www.astrometry.net`