$Id: road_map.txt,v 1.1 2007/03/15 09:14:38 michel Exp $

Liste des "actions" a realiser, dans un ordre de priorites decroissantes (ou
chronologique) :

  + Item qui peut être externalisé
  - Item à faire nous-même.

- mettre à disposition le logiciel.
  o si urgence : cvs
  o faire un package épuré
    - numéro version avec tag
    - ftp ou page web.
  o pserver.

- jargon
  o changer dans le code SED -> flux uniquement dans CR#. Finalement non,
    puisque l'architecture actuelle pourra lire n'importe qu'elle
    information spectrale.
  o residuals are not residuals

- Directory relatif au fichier descripteur.
  o Dans fichier descripteurs, accepter un nom de fichier relatif pour les
    données. Actuellement chemin relatif au directory courant. Devrait être
    chemin relatif au fichier descripteur.
    - Si pas trouvé par rapport au dir du descripteur, essayer dir courant ?
    - Chemin absolu ne change rien.
  o modifier les fichiers modèles du practice (plus besoin de variables
    d'environnement dans le chemin de fichier).

- faire marcher / tester la SED.

- fichiers descripteurs
  o nouveau parseur avec retour des résultats.
    - models -> modeling(s)
    - targets -> data
    - functions -> model, model = set of functions.
    - residuals: changer logique.
      o pas de default
      o commenté -> skipped
      o noms des fonctions appelées explicites.
    - data+model+residuals = "group"
  o définir la synthaxe du fichier de configuration. Cela comprend la
    définition des paramètres, modèle, données, etc (tout ce qui existe déjà)
    _ET_ la présentation des résultats du fit (matrices de covariances, etc.,
    a préciser justement).
  o E/S xml.

+ Réorganiser le practice directory.
  o Mettre la documentation dans practice/doc.
  o Faire des directives générales
    - short introduction to yorick.
    - short introduction to LITpro.
    - Example with Obj0. (disque uniforme).
      o How to build a descriptor file.
  o Pour chaque objet (Obj1, Obj2, ...)
    - Obj1_practice_directives (.asciidoc ? .txt ?)
    - Obj1_practice_manual (.asciidoc ? .txt ?)

- finaliser importateur de données amber.
  o importation SED.
  o controler echantillonnage SED = f(lambda). Calcul automatique des
    bandwidths manquante.
  o Faire le help dans les fonctions.

+ importer différents format de fichiers spectre. (-> Nicolas + Florentin)
  o reconnaissance automatique du format à partir du fichier.
  o => generation de la bonne hash table.

- programmer le "parser". La fonction doit faire exactement ce que fait
  lpm_parse_model() actuellement. Il faudra ajouter l'importation des
  résultats du fit (matrices de covariances, etc., a préciser justement)
  éventuellement stockés dans le fichier de configuration.

- faire une fonction qui écrit le fichier de configuration à partir de world.
  o WORLD  <--- read/write --->  CONFIG_FILE

- RFE: fonction show_data
  o Afficher les données rejetées/sélectionnées

- fonction slicer_map

- RFE: fonction plot_residuals

- fonction plot_spectrum (ou plot_radial, world, "SED")

- fonction sniffer_map avec gaussiennes

- fonction sniffer_map avec modèle courant.

- RFE: plot_uvcoverage_color
  o 20061205-5_plot_uvcoverage_color.txt
  o lp_plot_uvcoverage should change the color of the markers according to the
    wavelength. Otherwise, we cannot see anything useful if the spectral
    domain is short (overlap of the markers).

+ implanter un modèle "astrophysique" de Paul.

- écriture d'un simulateur de données OIFits.
  Dans un premier temps, essayer d'utiliser ASPRO. 
  Quid de la voie IDL de Monnier ? 
  à voir le moment venu

+ oi_write.

- autoriser des paramètres vectoriels.
  o visualisation des matrices de covariance et de correlation ?
  o gestion au niveau du moteur de fit ?

- LA DOC !!!
  o premier jet CRAL.
  o collaboration ensuite.
  o ecrire une documentation dynamique.
   - utilisation de l'outil asciidoc trouve par Eric.
   - (possible: s'aider du (ou referencer au) texte du tutorial de Goutelas
     pour une intro generale)

- Mécanisme d'interruption par le GUI.
  o déterminer le mécanisme d'interruption de Yoga par le GUI. Le GL
    implémente une méthode de 'stop+ dump' dans Yoga pour permettre un degré
    zéro de contrôle par le GUI.

- implanter un modèle instrumental

+ visibilité différentielle
  o Spécifier une classe visibilité différentielle où la méthode de calcul
    du canal spectral de référence est défini précisément
  o Devrait idéalement permettre différentes méthodes (AMBER, VEGA, etc.)

+ Système de gestion de bugs (-> Nicolas + Florentin)

- DB avec drivers.
  o calcul des résidus
  o simulation des données.
  o lecture des données.
  o controle des données.
  o ... (voir code)

- fit sur données hétérogènes : fichier.yhd généré préalablement.
  o publier la hash table.
  o nouvelle classe de DB

+ flags: fonction pour modifier les flags (-> Florentin)

- flags: fonction pour ré-appliquer les flags.

+ moteurs de fit supplémentaires à l'OCA ?
  o Simulated Annealing.
  o interfaçage avec LITpro.

- inclure d'autres moteurs de fit: Simulated Annealing, pseudo clean,
  random sampling et permettre le choix a l'utilisateur.

+ parallélisation des calculs ?
  o soit lancer des batchs en parallèle, un pour chaque condition
    initiale. Il faut collecter les résultats ensuite.
  o soit c'est un moteur de fit qui s'occupe de la parallélisation:
    exemple du recuit simulé.