Amélioration de l’interface utilisateur pour une sélection précise des outils de simulation

[laurent-laporte-pro]

Amélioration de l’interface utilisateur pour une sélection précise des outils de simulation

Présentation de la problématique

Lorsqu’un utilisateur lance des simulations d’études sur le serveur de production ou de recette d’Antares Web,
il a la possibilité de choisir la version du Solver requise. De plus, il peut également choisir d’utiliser
des outils supplémentaires disponibles sur ces serveurs, tels que l’Adequacy Patch R, Xpansion
(version R ou C++), ou le solveur Xpress.

Cependant, il convient de noter que la version Desktop d’Antares Web est plus limitée. Bien qu’elle soit livrée
avec la dernière version du Solver, elle ne dispose pas d’outils supplémentaires. Cette limitation est
principalement due à l’absence d’un interpréteur en langage R (R for Windows, R base pour Linux ou RStudio),
ce qui explique l’absence de l’Adequacy Patch R. Actuellement, bien que Xpansion soit disponible pour
ces plateformes, il n’est pas inclus dans Antares Web, il en est de même pour le solveur Xpress.

Dans Antares Web v2.14 (et versions antérieures), la boîte de dialogue de lancement des simulations propose une
configuration permettant d’activer et de configurer l’Adequacy Patch R, Xpansion et le solveur Xpress.

Afin de corriger cette interface, il est nécessaire de ne présenter ces options que si les outils correspondants sont
réellement disponibles. Dans le même temps, nous prévoyons de modifier la configuration de l’application pour
indiquer si un outil est disponible ou non, dans quelle version il est disponible, ainsi que le chemin d’accès
à l’exécutable correspondant.

Cette amélioration permettra d’offrir une expérience plus claire et cohérente pour les utilisateurs, tout en
garantissant que seules les options appropriées leur sont proposées lors du lancement des simulations.

Modification de la configuration

Description de l’évolution

La configuration de l’application est spécifiée dans un fichier nommé config.yml (ou application.yaml),
rédigé au format YAML. Cette configuration offre deux modes de lancement distincts pour les simulations :

• Le mode local permet d’utiliser Antares Solver lorsque celui-ci est installé localement
  sur le même serveur qu’Antares Web. Ce mode est privilégié pour la version Desktop d’Antares.
• Le mode slurm permet d’utiliser Antares Solver lorsqu’il est installé sur un serveur de calcul
  de type SLURM. Ce mode est utilisé sur le serveur de production ou de recette d’Antares Web.

Voici un exemple de configuration du lancement des simulations :

launcher:
  default: local
  local:
    binaries:
      850: /home/paul/opt/antares-8.5.0-Ubuntu-20.04/antares-solver
      860: /home/paul/opt/antares-8.6.0-Ubuntu-20.04/antares-8.6-solver

  slurm:
    local_workspace: /home/paul/antarest/slurm_workspace
    username: run-antares
    hostname: 10.11.12.66
    port: 22
    private_key_file: /home/paul/.ssh/id_rsa
    key_password:
    default_wait_time: 900
    default_time_limit: 172800
    default_n_cpu: 20
    default_json_db_name: launcher_db.json
    slurm_script_path: /bin/antares/launchAntares.sh
    db_primary_key: name
    antares_versions_on_remote_server:
      - '840'
      - '850'

Il faut faire évoluer la configuration pour le mode local afin de spécifier les chemins d’accès
aux outils. On se propose d’ajouter une section tools au même niveau que binary comme suit :

launcher:
  default: local
  local:
    binaries:
      850: /home/paul/opt/antares-8.5.0-Ubuntu-20.04/antares-solver
      860: /home/paul/opt/antares-8.6.0-Ubuntu-20.04/antares-8.6-solver

    # Chemins d’accès aux outils supplémentaires
    tools:
      adequacy_patch_r: /home/paul/opt/adequacy_patch_r-X.Y.Z-Ubuntu-20.04/adequacy_patch_r
      xpansion_r: /home/paul/opt/xpansion_r-X.Y.Z-Ubuntu-20.04/xpansion_r
      xpansion_cpp: /home/paul/opt/xpansion_cpp-X.Y.Z-Ubuntu-20.04/xpansion_cpp
      xpress: /home/paul/opt/xpress-X.Y.Z-Ubuntu-20.04/xpress

A fortiori, les outils supplémentaires sont toujours disponibles dans les versions en production et en recette,
car ils sont requis pour effectuer les simulations. Dans ce cas, il n’est pas nécessaire de prévoir la configuration
des outils supplémentaires pour le mode "slurm".

Le cas échéant, on pourra dupliquer la section "tools" pour le mode "slurm"

Description de la section tools

La section tools est optionnelle, par défaut, c’est un dictionnaire vide.
Elle contient les champs optionnels suivants :

• adequacy_patch_r: chemin vers le fichier exécutable de l'outil "Adequacy Patch R",
• xpansion_r: chemin vers le fichier exécutable de l'outil "Xpansion R",
• xpansion_cpp: chemin vers le fichier exécutable de l'outil "Xpansion c++",
• xpress: chemin vers le fichier exécutable de l'outil "Xpress".

Les chemins vers les outils peuvent être des chemins absolus ou des chemins relatifs.
Le format du chemin sera compatible avec Posix et Windows.
Les chemins peuvent contenir le caractère "~" pour indiquer un chemin relatif au répertoire de travail de l'utilisateur.
Les chemins peuvent être des chemins relatifs par rapport au répertoire du fichier de configuration.

Lecture de la configuration tools

Lors de la lecture de la configuration, il faudra tenir compte du répertoire du fichier de configuration
et respecter les contraintes suivantes :

• Les chemins relatifs au répertoire de travail de l’utilisateur doivent être résolus (à l’aide de la fonction
  expanduser).
• Les chemins relatifs au répertoire du fichier de configuration doivent être résolus (à l’aide de la fonction
  joinpath)
• Les chemins doivent pointer vers un fichier exécutable, donc :
  • il faudra lever une exception si le fichier n’existe pas.
  • il faudra lever une exception si le fichier n’est pas exécutable.

La fonction principale de l’application (le main) doit être modifiée pour tenir compte des exceptions
ainsi éviter d’afficher une stack trace verbeuse dans ce cas.

Modification de la boîte de dialogue de lancement

Description de l’évolution

La boîte de dialogue de lancement d’une simulation LauncherDialog se compose de plusieurs groupes.
L’affichage des groupes est conditionné par la configuration.

Les règles suivantes s’appliquent en mode "local" :

• Pour le groupe "Xpansion", il faut tenir compte de la version de l’étude et de la disponibilité
  des outils xpansion_r et xpansion_cpp.

  • L’option "Version R ≤ 7.x)" doit être masqué lorsque xpansion_r est vide ou lorsque la version de l’étude
    est postérieure ou égale à 800.
  • L’option "Version C++" doit être masqué lorsque xpansion_cpp est vide ou lorsque l’étude ne possède pas
    de configuration pour Xpansion C++.
  • Si les deux options sont masquées, on peut soit masquer le groupe "Xpansion" (et le titre), soit afficher
    un message "Xpansion non disponible"

• Pour le groupe "Adequacy Patch", il faut tenir compte de la disponibilité de l’outil adequacy_patch_r
  (pour rappel, Adequacy Patch C++ n’utilise pas cette configuration)

  • Les options de l’Adequacy Patch doivent être masquées si adequacy_patch_r est vide.
  • Si les options sont masquées, on peut soit masquer le groupe "Adequacy Patch" (et le titre), soit afficher
    un message "Adequacy Patch R non disponible"

• Pour les paramètres avancés, il faut tenir compte de la disponibilité de l’outil xpress

  • L’option "Use the Xpress solver (≥ 8.3)" doit être masqué lorsque l’option xpress est vide ou lorsque la version de l’étude est antérieure à 830.

En mode "slurm", il faut appliquer les mêmes règles en considérant que tous les outils sont disponibles.

[skamril]

Pour le front, on a besoin d'un endpoint permettant de connaître les outils disponibles pour une étude donnée (getAvailableSimulationTools ?) :

{
  xpansion: {
    r: boolean,
    cpp: boolean,
  } | false,
  adequacyPatchR: boolean,
  xpress: boolean
}

Le back devra vérifier que les chemins sont définis et valides avant de renvoyer true.

[laurent-laporte-pro]

Merci Samir, c'est un bon point de départ, mais je me pose plusieurs questions ?

• Ne faudrait-il pas plutôt un end point qui permette de récolter toutes les informations nécessaires sur une étude afin d'afficher la boîte de dialogue de lancement pré-configurée. On doit justement travailler sur ce sujet et mettre la configuration dans l'étude, mais avant cela, on pourrait déjà concevoir le formulaire côté front. Est-ce que cela demande beaucoup de boulot ?
• Sinon, je veux bien définir un end point qui demande les informations de lancement.

Pour le nom de la fonction, j'aurais une préférence pour getAvailableSolverTools ou simplement getAvailableTools, au choix.

Pour les données à retourner, je pense qu'il faut une structure à plat qui coincide bien avec le back:

{
  xpansionR: boolean,
  xpansionCpp: boolean,
  adequacyPatchR: boolean,
  xpress: boolean
}

Pour le point d'entrée, je te propose ceci :

@bp.get(
    "/launcher/tools",
    tags=[APITag.launcher],
    summary="Retrieve available tools",
    response_model=LauncherToolsDTO,
)
def get_available_tools() -> Any:
    logger.info("Get available tools")
    return service.get_available_tools()

[skamril]

Ne faudrait-il pas plutôt un end point qui permette de récolter toutes les informations nécessaires sur une étude afin d'afficher la boîte de dialogue de lancement pré-configurée.

Oui, on pourra changer le nom et la structure de retour par la suite, c'est pas problématique car c'est un endpoint privé (y'a-t-il moyen de l'indiquer clairement avec Pydantic ?).

Ne faudrait-il pas plutôt un end point qui permette de récolter toutes les informations nécessaires sur une étude afin d'afficher la boîte de dialogue de lancement pré-configurée.

Ça me va.

[laurent-laporte-pro]

@MartinBelthle , j'ai déplacé ta question ici pour pouvoir en discuter

@laurent-laporte-pro, si les 2 launchers sont disponibles (normalement pas le cas en prod mais possible en local), est-ce qu'on considère qu'on prend slurm en référence donc tous les outils sont disponibles ? En fait je ne sais même pas comment l'appli se comporte si on a les 2 launchers

[laurent-laporte-pro]

@MartinBelthle, oui la configuration permet d'avoir les deux launchers, mais un seul n'est actif à la fois :

launcher:
  default: local
  local:
    ...

  slurm:
    ...

Il faudra donc considérer le launcher par défaut donné par le paramètre default.

[MartinBelthle]

Ah oui effectivement

[laurent-laporte-pro]

@MartinBelthle, j'ai déplacé ta remarque ici pour avoir un fils de discussion

Est-ce qu'on veut vraiment lever une exception dans ces cas là ?

• Les chemins doivent pointer vers un fichier exécutable, donc :
  • il faudra lever une exception si le fichier n’existe pas.
  • il faudra lever une exception si le fichier n’est pas exécutable.

Parce que pour le binaire du launcher aucun de ces 2 checks n'est effectué actuellement. De plus si on s'en sert simplement pour renvoyer un binaire au front, ça me semble inutile.

[laurent-laporte-pro]

Il faut absolument revoir la façon dont le fichier de configuration de l'application est chargé.

J'ai relevé les cas d'utilisation suivants :

• Dans antarest.main.fastapi_app, lors de la création de l'application FastAPI.
  • Cette fonction est appelée lorsque l'application est lancée avec le WSGI.
  • C'est le cas nominal to lancement de la version Desktop ou du lancement avec le point d'entrée GUI.
• Dans antarest.utils.create_env, mais je pense que c'est du code mort (à vérifier)
• Dans les tests unitaires…

Dans tous les cas, l'application web est en cours d'initialisation et n'est pas encore lancée : il est donc raisonnable de lever une exception si la configuration n'est pas bonne.

[laurent-laporte-pro]

@MartinBelthle, je déplace ta remarque ici :

J'ai ouvert une PR #1616 qui contient seulement le back office mais qui n'est pas terminée

[laurent-laporte-pro]

Il est préférable d'attendre d'avoir les spécifications détaillées avant de soumettre une PR.

J'envisage deux scénarios possibles :

1. Faire rapidement une correction pour la version v2.14.4.
2. ou faire une évolution dans la prochaine version.

Cependant, je pense que la solution consistant à apporter une correction rapide pourrait ne pas être la meilleure option, car nous avons un travail de fond à faire pour mettre en œuvre la configuration du lancement des études au niveau de l'étude elle-même. C'est pourquoi je suggère de prendre le temps d'élaborer des spécifications détaillées avant de commencer le développement.

[MartinBelthle]

Je vois. Ma PR #1616 permet certainement de faire une quick correction mais n'est peut-être / sûrement pas pérenne.