ELODIE : Incidents dans Tacos

Le fonctionnement de Tacos est automatique, et vous pouvez l'observer dans la fenêtre Réduction de stel. Cependant, il arrive parfois que des erreurs se produisent. Pour nous permettre de mieux identifier et traiter les conditions d'erreur, nous vous demandons de réaliser alors une sauvegarde du contenu de la fenêtre Tacos, comme suit :

Historique de la fenêtre Tacos

Les informations que TACOS vous transmet dans la fenetre Réduction sont recopiées automatiquement dans le "logbook" qui est en icone au début du programme. Elles sont recopiées à la fin d'une session (fin de travail ou fin de nuit) dans le fichier $IMADIRPATH/systeme/glog.dat. Cependant, les messages d'erreur du système n'y figurent pas, et sont uniquement montrés à l'écran. C'est pourquoi il peut etre intéressant d'enregistrer le contenu de la fenetre de réduction en cas d'erreur particulière.

Pour enregistrer le contenu de la fenêtre ("l'historique"), il suffit de placer le pointeur dans la fenêtre Réduction, puis d'appuyer sur le bouton droit (M comme Menu) de la souris : vous obtenez le menu suivant :

La fonction de sauvegarde est dans le menu Historique : on l'atteint en cliquant le bouton droit (M) sur le triangle d'appel de ce menu :

Ceci fait apparaître en haut à gauche de l'écran la fenêtre de sauvegarde. On ne peut pas modifier le répertoire : le nouveau fichier sera donc créé dans votre répertoire racine (Home). Donnez-lui le nom suivant : ertacos.date.n par exemple ertacos.200994.3 si c'est le 3ème fichier d'erreur que vous créez le 20 Septembre 1994

Il vous suffit ensuite de recopier ce fichier dans /elodie/suivi, en écrivant dans une fenêtre de commande :

	cp ertacos.200994.3 /elodie/suivi

par exemple, pour le fichier ertacos.200994.3 cité plus haut.

Signalez nous les erreurs dans le cahier de coupole, pour que nous puissions les examiner.

Vous trouverez ci-dessous le détail de quelques situations d'erreur et des pistes pour y remédier.

Lancement

Au lancement de Tacos, il arrive parfois que le bloc de référence ne puisse pas être lu correctement. On obtient alors un message du type suivant :

tacos -echo -server
INTERHOME=  /home/queloz/src/tacos
Inter: mode server, block = block.ref
Pbm durant la lecture du fichier : block.ref_dbl.
    !!!!!!Le bloc de donnée n'a pas été lu
Voulez vous une copie du bloc de référence (o/n) [def: n ] : o
Pbm durant la lecture du fichier : block.ref_dbl.
    !!!!!!Le bloc de donnée n'a pas été lu
stel{queloz}2:

et on se retrouve avec le prompt.

Il suffit alors de relancer tacos dans la même fenêtre, comme suit :

	 tacos -echo -server

et tout doit rentrer dans l'ordre.

Cette alarme se produit principalement lors de la réduction des localisations ou des images d'étoiles.
Avec l'afficheur, vous pouvez détecter les zones saturées en changeant de LUT.
Dans le cas où la saturation n’est pas évidente, vous pouvez continuer la réduction.
Dans le cas où la saturation est très importante, les résultats de la réduction ne sont pas valables, et nous vous conseillons de refaire la pose, principalement pour les localisations, qui sont utilisées pour la réduction des poses suivantes.

telcoord

Cette erreur se produit lorsque LIDO n'a pas été capable d'obtenir les coordonnées du télescope.
Rappelons que les coordonnées du télescope doivent être associées à toutes les poses, même celles d'étalonnage.

Les causes de cet incident sont en général les suivantes :

La session TELESCOPE n'est pas lancée sur le HP150 du télescope (on n'a pas d'affichage sur la visualisation des coordonnées).
Il faut en effet que cette session soit lancée pour que LIDO puisse connaître les coordonnées du télescope. Pour lancer la session :
- - taper sur n'importe quelle touche du HP150 du télescope, vous obtenez l'invite du HP A900.
- - présentez-vous sous le nom TELESCOPE .
- - une fois obtenue l'invite du CI, tapez de nouveau TELESCOPE : la session commence, et l'affichage des coordonnées se met en place.
Le process a900 n'existe pas : On le voit en utilisant la fonction examiner ou modifier les process de la maintenance de archiv : il faut que a900 existe. S'il n'existe pas, la maintenance propose de le lancer.
La communication est rompue avec le HP : On le voit en essayant de faire une fonction du télescope à partir de la fenêtre de commande de LIDO : la commande est bien lancée par a900, mais la réponse ne vient pas immédiatement, et on sort en time-out. Dans ce cas, il faut sortir de LIDO, tuer tous ses process par la maintenance de archiv, et relancer LIDO.

Comme les coordonnées du télescope sont nécessaires pour la réduction des poses sur les objets, il faut donc remédier immédiatement au défaut. Cela est beaucoup moins grave pour les poses d'étalonnage, et il suffit en général d'attendre le début des observations pour obtenir les coordonnées. Cependant, la réduction est suspendue tant que vous ne validez pas par Okcette notice dalarme : cela vous impose d'être attentif à l'écran de stel pour ne pas perdre trop de temps.

Cette erreur peut arriver, naturellement, quand on fait des poses "sur le ciel" pendant la journée, sans pointer le télescope. Si elle arrive pendant la nuit, il faut vous demander si l'objet pointé est bien celui que vous avez sélectionné dans le catalogue.
Dans tous les cas, les coordonnées du catalogue, si elles existent, seront prises pour la réduction.

Ceci est le signe d'une dispersion trop importante des valeurs d'un coefficient au cours de la réduction des poses de lumière uniforme. En recommençant la pose de lumière uniforme, vous avez une bonne chance d'obtenir un ensemble de 3 images cumulées de meilleure qualité, et cette notice n'est alors pas affichée.
Si le défaut subsiste, il faut, comme il est dit dans la notice, reprendre la séquence d'étalonnage à partir des calibrations.

Ces notices signalent principalement un défaut de mise au point.
La réduction des poses d'étalonnage en longueur d'onde doit normalement conduire à une dispersion d'environ 3,1 km/s pour l'ensemble des raies. Les valeurs obtenues actuellement (Octobre 1994) sont de 3,107 km/s avec la mise au point réglée à 1845 microns.
Si la mise au point se dégrade, on obtient une augmentation de cette dispersion, comme on peut le voir sur la courbe de la page suivante. La limite « acceptable » est 3,135 km/s. Au delà, le programme de réduction refuse de construire une solution.
Dans tous les cas où cet incident s'est produit, cela correspondait à un défaut de la mise au point, qui a disparu quand on est revenu à la valeur précédente.
Essayez donc de vérifier la valeur de la mise au point (par les Mouvements, demandez l'état) ou de la modifier.

On peut travailler, mais on n'a pas la résolution maximum.

Visualiser /home/queloz/focus.ps

Cette notice vous alerte si le bruit de lecture n'est pas conforme à sa valeur typique. Cela arrive parfois, principalement à l'occasion d'opérations de maintenance de la caméra CCD.

Comment cela affecte-t-il les résultats obtenus ? On perd un facteur 2 ou 3 sur le flux ...à bas rapport signal/bruit en mode coorélation.

on ne peut pas faire des OBTH sans étalonnage au thorium double !!!

Vous devez utiliser les valeurs de NOPROG et NOCAT qui vous sont attribuées : vous les trouvez ici. Vérifiez que votre catalogue est correct, et n'utilisez que des valeurs valides quand vous écrivez les paramètres d'une étoile.

calng

après cette erreur, la solution en lambda n'est pas retenue, il faut recommencer la pose ! L'image est cependant sauvée. Ce thorium n'est pas utilisé.

date

Ce panneau comporte une ligne pour écrire la bonne date.

quand on utilise la fibre ciel, on commence par faire la corrélation du ciel, et on doit donc ajuster le picc du ciel. Si ce pic est faux, et donc lié au bruit, on l rejette, et on n'utilise alors que le niveau moyen de la fonction de corrélation. Voir notice de réduction 3.6.1 Cas d'une image OBJ2.

De plus, il existe une sécurité dans LIDO qui empèche de faire cette demande ...

C'est une alarme qui n'arrive que quand on utilise TACOS off-line. Ou il existe déja un répertoire correspondant à cette date.

Ceci peut être dû à des actions de maintenance . L'observateur n'a pas d'outil pour se sortir seul de ce mauvais pas !

Le programme extrait quand même le spectre sans correction des cosmiques --> attention au résultat !!!!

fitllnc

fithpbm

Sur localisation, ... cela ne devrait plus arriver, cette situation peut être causée par des délais importants dans le système. Il faut absolument recommencer la pose. Si le défaut persiste ... ouille!

Localisation : Dispositif : en particulier l'atténuateur d'étalonnage, qui doit être à 0.

On ne peut pas aller plus loin sans indiquer le gain. On peut le lire sur LIDO. Attention : il faut donner la bonne valeur !!!!!

on contrôle la précédente ./. lastdatnuit... Par exemple si on a créé la nuit à 1heure ... et on veut encréer une autre dans l'après midi .........!!!!!!!!!!!!!!!!!!!

Tester le message de retour pour voir si on peut faire l'offset pour éviter de planter le système.

Effet possible : sur une * en absorption c'est le continu qui sature --> attention !!! tout peut être faux. Si c'est une * en émission, cela n'a que peu d'importance si on ne s'intéresse pas à ces raies saturées. Il se peut enfin que le nombre de cosmiques soit important pour une pose longue (1h, par exemple)

Cette erreur est arrivée en particulier lorsque les spectres étaient déplacés par la lame d'élargissement, arrêtée dans une position intermédiaire.
Pour s'assurer que cette lame est bien centrée, lancez au moyen de la commande Mouvements l'élargissement du spectre, puis arrêtez le : la lame se recentre alors automatiquement. C'est arrivé aussi par un refroidissement accidentel du spectro. Si on ne trouve pas d'erreur sur l'instrument, il faut refaire la localisation complète (début de mission)

localisation complète : on doit en trouver 67 . Comment peut-on en trouver moins ? Cette erreur ne doit pas arriver !

Le cumul de 2 n'est pas possible : on utilise une pose pour éliminer les cosmiques ....... cela sera revu !!

lié au cumul ... va changer ... signe que l'on change d'objet avant de recevoir l'ensemble des images prévues par le cumul.

le fram sur disque wsera bon, et on pourra rejouer l'image par la suite si on fait l'offset nécessaire.

nocoda, nocodb, nodup, ... sont mauvais . On a un INCONNU ! erreur du catalogue ? ou du logiciel ???

De plus, il existe une sécurité dans LIDO qui empèche de faire cette demande ...

sur les thorium simultané, on n'arrive pas à avoir le pic de corrélation du thorium dans la fenêtre ... La dérive de calibration est imposée à 0. Cela peut se produie si on n'a pas assez de flux sur la fibre thorium : lampe ? atténuateur ? ou par exemple pose avec arrêt immédiayt (il aurait mieux valu faire un abandon !) ou gros pb sur le spectrographe : inondation d'azote liquide par exemple.

erreur > 10sec, pour t > 100sec On pourra rentrer à la main l'heure de milieu de pose.