History

Wiki »

TODO

IMPORTANT LINKS

Questions

  • Est-ce qu'on tient compte des Ephemerids lors de la création d'une requete Alerte ou pas ?
  • What is the 'flag' attribute ? (@AK)

DIVERS TODOs

  • Installation script : l'écrire entièrement en Python (à la place du Bash)
  • Introduire le composant Ephemerids (donne position lune, soleil, planètes pour la nuit...)
  • (?) Réintroduire la notion de RequestBuilder puisqu'il doit récupérer l'information donnée par Ephemerids, aussi bien pour construire une Routine que pour une Alerte
  • Compléter la grammaire de commandes PYROS à destination des telescopes et cameras (en essayant de faire des mises en commun)
  • Mieux gérer l'héritage dans les modèles : pyros_user => user, telescope => device, detector => device, etc... ; l'héritage doit être "transparent", ex: pyros_user.name = pyros_user.user.name, telescope.name = telescope.device.name, etc...
    => lire la partie " Les modèles parents classiques" de la section "L'héritage des modèles" de cet article : https://openclassrooms.com/courses/developpez-votre-site-web-avec-le-framework-django/techniques-avancees-dans-les-modeles
  • Ajouter le développement des simulateurs (en cours) dans la roadmap
  • Faire apparaitre une classe Factory à laquelle le Simulator fait appel pour créer ses instances du modèle ; c'est une classe utilitaire, à mettre à part, et utilisable par d'autres parties du code
  • Upgrade Django => 1.10
  • Roue à filtre : doit pouvoir être associée à Camera ou bien à Tele (c’est prévu dans la BD ou pas ?)
  • Il faut un système de LOG utilisé par tous les modules (Django en a un par défaut ?)
  • table filter_wheel : ajouter un champ "position" (numérique, c'est pas forcément un angle)
  • table filter : ajouter un champ "epaisseur équivalente" (donne le recul nécessaire à faire pour ajuster la focalisation) : un filtre a une épaisseur (a priori la même pour tous les filtres mais pas forcément) et on doit donc refocaliser pour en tenir compte
  • ajouter un NODE dans lequel on met le telescope (comme CADOR qui est un noeud regroupant plusieurs telescopes Tarot) : on peut par exemple imaginer que le GFT sera plus tard associé au telescope Butes du SPM ou au telescope chinois géré par le CSC (60cm), ou au GWAC du Chili
  • Créer un super agent SystemWatcher qui surveille tous les "agents" et les relance en cas de problème => ainsi, on n'a qu'un seul cron à exécuter pour relancer SystemWatcher s'il crashe (et c'est lui qui se charge de relancer les autres)
  • Weather : plusieurs sources à traiter en parallèle, et en faire la synthèse ; plusieurs avantages:
    • redondance : si une source crashe, on a les autres
    • validité des données : on est davantage sûr d'un phénomène s'il est confirmé par plusieurs sources
    • identification de panne : si 1 seule source annonce la pluie et 2 autres non (ou l'inverse), on peut penser que cette source est défaillante
    • complémentarité : les différentes sources n'apportent pas exactement la même information, elles peuvent se compléter (ex: cloud sensor et rain detector)
  • Ajouter des boutons de navigation sur le planning, permettant de passer au planning précédent (historique), ou suivant, ou de revenir à celui du jour : <PREC> <NOW> <SUCC>

General tasks (notes Etienne Pallier)

  • Analysis (and calibration) module:
    Pour l'instant, il est considéré qu'un plan forme une seule image. Lors de la fin de l'exécution d'un plan, la tâche execute_plan crée une tâche analysis à laquelle il envoie l'id du plan qui vient d'être exécuté. La tâche d'analysis récupère le plan en question, et récupère son nom. Pour le moment, les images crées ont le nom du plan correspondant. Il y a une ligne de TODO dans la tâche d'analysis qui dit de vérifier si le plan provient bien d'une alerte avant--de faire les analyses. Dans tous les cas, les calibrations sont appliquées.
    => Pour faire évoluer ce système d'image (puisqu'un plan crée plusieurs images), il faudra être capable de dire dans le execute_plan : une image vient d'être terminée par la caméra. Auquel cas on créera une tâche analysis à chaque-image crée, en lui donnant l'id du plan et le nom de l'image.
  • Données simulées : faire l'inventaire des données dont on a besoin (action en cours), données qui entrent (inputs) et qui sortent (output) de notre système
  • Scheduler:
    • Améliorer l'affichage du planning: ajouter une colonne "Observatory status" dans laquelle on affichera pour chaque séquence des icônes donnant le status en cours du ciel (cloudy, ...), le status des instruments (ex: icone d'un matériel en panne pour dire qu'on a un soucis sur le matériel)... ; en cliquant sur ces icones, on aurait plus de détails sur ce qui se passe
    • Heure TU (UTC)
    • N'afficher que la fenêtre de temps actuelle (mais on doit pouvoir scroller)
    • Remplacer EXECUTED par COMPLETED, EXECUTED (partial) par INTERRUPTED, PENDING par EXPECTED
    • Il faudrait une page qui montre toutes les séquences rejetées et exécutées (à préciser)
  • Interface with GIC:
    • Produire les données à envoyer au GIC dans un repertoire GIC/TO/ (pour que le GIC vienne les y chercher)
    • Récupérer les données envoyées par le GIC depuis un autre repertoire GIC/FROM/
  • Interface with FSC:
    • Copier (ou linker) les données à envoyer au FSC dans un repertoire FSC/TO/ (ou autre solution ?)
  • Tests unitaires (pyrosrun.sh unittest): les tests unitaires ne devraient pas faire appel à Celery (rabbitmq), or 2 tests ne passent pas si rabbitmq n'est pas lancé:
    • test_full_creation (common.tests.RequestBuilderTests)
    • test_change_all_working (alert_manager.tests.TestStrategyChange)
    • => il faut donc enlever le lien avec Celery dans ces tests (ou alors sortir ces tests des tests unitaires)
      )
  • Observer:
    • Refactoriser tasks.execute_plan{vis,nir}
    • Gérer le Dithering : au début, c'est la camera NIR qui devait le gérer, mais ça risque d'être le Telescope !!! => va compliquer énormément les séquences d'observation.
    • Organisation physique des données sur le disque
      • -Estimer le nombre de fichiers (et volume total)
      • 3 espaces sur le disque (ou 3 disques ?):
        Un espace disque dédié aux images créées au fur et à mesure, nommé PRODUCED_DATA/
        Un espace disque dédié aux entités externes (GIC, FSC), nommé EXTERNAL_ENTITIES/
        Un espace disque dédié au téléchargement par les utilisateurs, nommé DOWNLOAD/
        • Sur l’espace (1):
          1 repertoire par nuit => pas très adapté car les AR et RR peuvent être exécutées sur plusieurs nuits.
          => préférer un repertoire par requete, que ce soit une alerte (AR), ou une routine (RR)
          => on peut même ajouter un sous-repertoire par sequence, ce qui aurait du sens puisque la sequence est l’unité de la planification.
          => il n’est sans doute pas nécessaire de descendre en dessous du niveau de la sequence (1 sous-repertoire par album c’est à dire par détecteur, puis 1 sous-repertoire par plan, quoi que...)
          -- Nom des dossiers : dès le début, un suffixe “_active” pour dire que c’est en cours de construction, puis supprimer ce suffixe quand la requête est terminée. Ex: alerte_1234_active/ => alerte_1234/-
          -- Nom des images (même principe) : au début, un suffixe “.tmp”, qu’on supprime ensuite quand l’image est écrite entièrement.-
        • Sur l’espace (2):
          1 repertoire FSC/
          1 repertoire GIC/
          Ces répertoires contiennent 2 sous-repertoire TO/ (ce qui doit être récupéré par l’entité) et FROM/ (ce que l’entité nous envoie).
          A priori le répertoire FSC/ n’a besoin que d’un sous-répertoire TO/, et ce sous-rep pourrait soit contenir une COPIE des fichiers, soit des LIENS vers les fichiers originaux (solution préférable).
    • Récupération des données d’une Request par son propriétaire (où tout autre user du même SP ?)
      Ca risque d’être lourd à télécharger via du http, donc peut-on imaginer de donner un accès FTP direct sur le disque dur, dans un repertoire dédié à la récupération des données (dans lequel on aura recopié seulement les données demandées par l’utilisateur) => espace (3)
  • Sequence:
    • Priority:
      Une request est créée par un User qui appartient à un SP (Scientific Program).
      La priorité de la Request est celle du SP.
      Par contre, au sein de la Request, on pourra moduler la priorité de chaque séquence (cf /Sequence), afin de prioriser certaines sequences par rapport aux autres. Par défaut, cette variation de priorité sera nulle (0) pour chaque Sequence.
      Par exemple, on pourra faire varier la priorité d’une Sequence de +ou 5 par rapport à la priorité de la Request.-
    • Quota:
      Les quotas sont attribués par le TAC (Time Allocation Committee) tous les 6 mois, pour chaque thème ou programme scientifique.
      Le TAC attribue une lettre A (prioritaire), B (si il reste de la place), C (rejeté).
      Au niveau du GFT, on traduit ces lettres en “grande priorité”, “priorité moyenne”, et “petite priorité” (le C n’est pas rejeté).
      On estime alors le temps nécessaire pour le SP, et on le traduit en pourcentage.
      On pourra donc attribuer un quota (en %) à chaque SP.
      => Le temps total de toutes les Requests (toutes leurs séquences) de tous les Users d’un même SP ne devra pas dépasser le quota du SP.
    • Date: on doit pouvoir la donner sous 2 formes:
      • “Tonight” => nuit en cours ou bien nuit qui arrive
      • Date précise JJ/MM/AAAA (maximum à now + 7 nuits)
    • Execution strategies:
      • Request level:
        "Best effort, do as much sequences as you can"
        => option: "All or nothing": if ANY sequence fails, request fails
      • Sequence level
        “Optional sequence”
        => option “Mandatory sequence”: if THIS sequence fails, request fails
        “This night only”
        => option, “Reportable à la nuit suivante” (jusqu’à 7 nuits maxi)
    • Période de visibilité JD1-JD2:
      • Donnée par le logiciel ETC/IS
      • c’est pour UNE NUIT (celle en cours, la prochaine, ou bien une date ultérieure pas trop loin pour que les users ne planifient pas trop en avance). Si la séquence n’a pas pu être exécutée pour cette nuit, il faut essayer de la -reprogrammer pour la nuit suivante (si le user a coché cette option) => il faudra donc recalculer le JD1-JD2 qui sera un peu différent pour chaque nuit, et ainsi de suite, jusqu’à ce qu’on arrive à une période de visibilité VIDE car le target n’est alors plus visible du tout
      • D’autre part, il peut y en avoir plusieurs dans la nuit, et il faudra que l’ETC/IS les donne TOUTES:
        • 2 pour un target naturel (par exemple, il se couche en début de nuit, et se lève en fin de nuit, donc 2 périodes)
        • Jusqu’à 12 pour l’ISS
        • => prévoir donc N périodes (au moins 2)
        • => obliger l’astronome à en CHOISIR une seule (s’il le souhaite, il pourra de toutes façons faire une autre séquence avec la 2ème période de visibilité…):
  • Workflow du "démarrage du système" à documenter (tout se qui se déclenche quand on lance le logiciel pour la toute première fois...) : lancement du monitoring, qui à son tour lance un scheduling, …
  • public/ : faut-il garder ce dossier qui ne contient qu’un seul dossier static/ ? (ce dossier static/ est-il utile à qqch ?)
  • Démarrage: Ce n’est pas Monitoring mais Majordome qui doit lancer le 1er scheduling en début de nuit
  • Fin de nuit: Majordome fait un system.pause(), ensuite une task de calibration est lancée qui doit vérifier que tout est ok avant de faire START (dome fermé, Tele fermé, …)
  • Créer un mode DEV : jouer avec la variable DEBUG (ou autre ?) dans src/pyros/settings.py pour mettre à TRUE en mode DEV afin d’éviter d’avoir à commenter certaines lignes lors du lancement du workflow (sinon, c’est trop long)
  • User : faire une view pour le profil
  • RoutineManager : Faire un TEST import/export d’une requete
  • Roue à filtre : doit pouvoir être associée à Camera ou bien à Tele (c’est prévu dans la BD ou pas ?)
  • Observation_manager/Tasks : créer une classe mère héritant de Task, dont les classes filles (plan_vis et plan_ir) vont hériter
  • Architecture projet (organisation dossiers):
    • src/ : laisser seulement les applications, et mettre tous les autres dossiers (fixtures/, images/, ...) dans un dossier MISC/)
  • RUN :
    • S'assurer que tous les prérequis sont présents et démarrés avant de lancer Pyros (sinon, générer un message d'erreur expliquant le problème):
      • RabbitMQ
      • Mysql (sauf si on a choisi sqlite)
  • TESTS (intégration continue):
    • Même remarque que pour le "RUN" ci-dessous concernant le check des prérequis
    • Inclure "trial comet" dans les tests pour s'assurer que Comet est bien installé (+ "rm -r _trial_temp/" ensuite pour faire le ménage après le test)
    • Mettre en place une exécution systématique des tests à chaque commit (unitaires + fonctionnels)
      (pour faire plus simple, on peut imaginer que le serveur de test linux fasse un "git pull" toutes les 30mn, puis une exécution des tests, et l'envoi d'un email en cas de problème)
  • Installation script:
    • Si l'environnement virtuel existe déjà, demander s'il doit être recréé (par défaut "Non")
    • Renommer le script install_requirements.sh en install.sh
    • Faciliter l'installation du logiciel complet avec CONDA, qui gère toutes les dépendances du logiciel, même les dépendances non Python (mysql, rabbitmq, ...), et c'est du multi-plateforme : (cf -https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions)
  • Pyros :
    • Doit pouvoir être démarré indifféremment AVANT (par défaut) les devices, ou APRES (actuellement, le AVANT est TODO)
    • De manière générale, doit être le plus possible "tolérant aux pannes"
    • Doit être le plus générique et donc paramétrable possible
  • Comet installation : Include in the install_requirements.sh script (by using stable official version for Python 3 (when available) on Linux (and Mac) and Windows 10
  • git : Create a "dev" branch (do not write anymore on the "master" branch)
  • Simulators :
    • on doit se rendre compte qu'ils sont "vivants" (ils seront progressivement remplacés par les vrais devices, mais resteront toujours utilisables à leur place)
      • Le Monitoring doit les interroger régulièrement sur leur statut (check_status, DONE)
      • Il doit stocker les statuts dans la BD (TODO)
      • Ces statuts doivent être affichés au fur et à mesure sur la page web du "device" correspondant (Devices, Site, Weather) (TODO)
    • quels sont les devices bloquants et non bloquants ?
      • Bloquants: si indisponibles (en panne ou pas démarrés), Pyros met en pause le sous-système d'observation
        Seules 3 fonctions restent toujours actives: alertes, monitoring, et serveur web (pour les routines et la surveillance)
        • Telescope
        • Camera VIS (???)
        • PLC (weather + observation conditions + site)
      • Non bloquants: si indisponibles (en panne ou pas démarrés), Pyros se contente d'en prendre note, et continue son fonctionnement normal tout en restant dans l'attente de leur redémarrage pour les réintégrer
        • Camera VIS (???)
        • Camera NIR
  • Users: gérer les 3 profils (admin, expert, user)
  • Scheduler :
    • Eviter que la vue du Scheduler s'affiche avec une erreur (IndexError) quand il n'y a aucun schedule dans la BD (http://127.0.0.1:8000/scheduler/) => idem pour toutes les autres vues de tous les modules
    • Affichage d'un schedule : pour chaque ligne (séquence), ajouter une colonne à gauche qui donne le nom (short name) de la Request dont la séquence fait partie (quand on clique sur ce nom, on va vers une vue de la Request qui sera soit une AlertRequest soit une RoutineRequest)
    • le rendre complètement autonome, indépendant du projet, afin qu'on puisse facilement le sortir du projet, et le proposer comme un composant générique utilisable dans n'importe quel autre logiciel ; il devra donc gérer ces communications avec les autres modules via des interfaces
  • Doc :
    • TEST:
      • Unit tests : test of each module
      • Functional tests (with Celery and simulators): complete workflow
    • LAUNCH:
      • Start simulators
      • Start Celery
      • Start pyros
    • USE:
      • Administration of the database: http://localhost:8000/admin
      • Interacting with Pyros: http://localhost:8000
        • Watch the environment: Devices, Site, Weather
        • Watch the schedule: Schedule
        • Watch the data processing (workflow): System (Dashboard)
        • Submit a Routine Request (and get results): Routines
        • Watch alerts: Alerts
        • Simulate an Alert: Alerts (TODO: Un user "admin" doit pouvoir déclencher une alerte type depuis la page web Alerts)
        • Manual operations on the Telescope : Devices/Telescope (TODO)
        • Manage users : Users

Applications tasks (notes Paul Carensac)

Dashboard

  • Create the backoffice views as the modules are integrated in pyros
  • Think about a system of permissions

Scheduler

  • views
    • Link the main page to the current schedule instead of the simulation page
    • Show user sequences in the schedules (with links)
    • Give accces to old schedules (day / days before / all end-night plannings / all plannings)
    • Give access to the refused sequences of a schedule, and the reasons of rejects
  • scheduler
    • Verification when there are not fields in the scheduler tables (index out of range)
    • Change the system to determine night start/end (they must be given in parameter, only if first_schedule is True)
    • Store the reasons of rejects (create a new attribute, in shs ?)
    • What is the 'flag' attribute ? (@AK)
    • Do not create the execute_sequence tasks if it's not the night ( 120 seconds)-
    • Priority and quota computing
    • Quotas evolution
    • Blank space filling
    • At the end of a scheduling send, it to the IC ?

Alert Manager

  • Web :
    • Print if there is an alert in progress in the main page
    • Link the alerts to their status and results
  • Connect to a real VOEvent broker
  • Determine the communication with FSC for strategy change
  • VOEvents :
    • Extract the good fields (see AK Q&A 07/01/2016)
    • Fill the request & alerts objects
    • Use strategies to build a request
    • Possibility to change the default strategy
    • Handle VOEvent updates
    • Be careful to not create 2 alerts for a same GRB, seen by 2 different satellites

Analyzer

  • Apply the calibrations in the right function
  • Apply the analyses only if it's a GRB
  • Implement the analyses
  • Send analyses to FSC

Majordome

  • TaskManager
    • When a sequence is cancelled, give back the quota to the user
    • In case of alert, do not stop the ongoing plan, and make the instruments abort
  • execute_sequence
    • Add the PLC checks at start (to see if we do the slew)
    • Use the global telescope (instead of creating one here)
    • Give first_schedule as false when a scheduling is launched
    • Remove the default countdown (1, for tests)
  • system_pause
    • Abort the instruments
    • Stop the execution tasks
  • system_restart
    • Start a scheduling
  • change_obs_conditions
    • Change sequences status (if needed)
    • If some status changed, re-launch a scheduling

Monitoring

  • views
    • Move the dashboard here
    • Print the instrument status
    • Print PLC informations (with the evolution)
    • In the dashboard screens, put scroll on each screen to see the old logs
  • Monitoring task
    • Uncomment the scheduling at the beginning
    • Implement night start/end computation
    • Initialize communication with the instruments
    • Configure intruments at start
    • Send software versions to the IC
    • Initialize connection with PLC
    • After the starting actions, loop to wait for the instruments configuration to be finished
    • Ask PLC for status
    • Ask filter wheel for status
    • Store the instruments & PLC status
    • Send all status to IC
    • Analyse PLC status (obs conditions, ...)
    • Create tasks of obs condition changes
    • At the beginning of the loop, ping the DISABLED devices. If they answer, change their status (TBD), and do their initialization (ex: If it's a camera, set its temperature to -150°)

Observation Manager

  • execute_plan :
    • Uncomment the instruments_ready waiting function
    • Uncomment the observation_ending waiting function
    • Try to remove code duplication (plan_execution_vis & plan_execution_nir)
    • Determine what needs to be done at the end of an observation
  • create_calibrations :
    • Make the calibration images
    • Generate super images
    • Send them to the IC

Routine Manager

  • Web
    • Put the goods fields (for coordinates etc)
    • Only propose the objects that matches the conditions (ex: scientific programs of the user only)
    • Do all the needed checks
    • Add automatic computation of JD1/JD2
    • Add checkbox for JD / GD
    • Add options : copy my sequence on x days, and authorise report
    • Add ETC-IS simulation
    • Add help for new users (and for it the first time an account come on the page)
  • Do more checks at unserialization
  • views
    • When saving, do more checks on coordinates, jd1/2 etc
    • Uncomment filter for alerts removing
    • When submitting, use the monitoring to determine sequences status
    • When submitting, modify the first_schedule to False, when scheduling
    • When unsubmitting, uncomment the check for EXED and EXING removing
    • When unsubmitting, uncomment the scheduling and change the first_schedule to False

User Manager

  • Password recovery
  • Profile page
  • User validation by administrator / commission
  • Handle permissions and access

Common

  • Change the 'first_schedule' to False at the end of RequestBuilder.validate()

Devices

  • When a socket connection fails (exception thrown), set the device to DISABLED (or that kind of status) in the DB, and create a system_pause task (majordome)