✎ groupe-dfo-bbo:projets:nomad:nomad-server [Groupe de recherche en DFO-BBO]

Modifiez cette page et cliquez sur « Enregistrer ». Voyez le guide de mise en page pour une aide à propos du formatage. Veuillez ne modifier cette page que si vous pouvez l'améliorer. Si vous souhaitez faire des tests, faites vos premiers pas dans le bac à sable.

====== Nomad Server ======

**But**: On veut utiliser NOMAD avec Oríon.

Oríon utilise des fonctions qu'on a déjà vues avec BBOpt: ''suggest'', ''observe'', ainsi qu'une autre pour le parallélisme: ''set_state''.\\
{{ :groupe-dfo-bbo:projets:nomad:interactions_nomad_orion.png?nolink&400 |}}
Le problème est que notre boîte noire est __asynchrone__. Oríon peut recevoir un point, puis en recevoir un autre, sans que le premier point soit évalué. On peut donc imaginer un NOMAD asynchrone, qui suggère des points quand on lui demande, quitte à suggérer les mêmes points deux fois de suite si NOMAD n'a aucune nouvelle information. Il y a des similitudes avec pMADS asynchrone.

Conséquence: NOMAD ne peut pas attendre que les points soient (tous) évalués avant de continuer.

Proposition 1: Recommencer NOMAD à chaque appel pour se rendre au point courant
  * Avantage: On a déjà un processus en place qui sert à reproduire des runs
  * Inconvénient: C'est broche à foin

Proposition 2: Nomad Server. Version de NOMAD qui est un serveur de points.\\
  * Lorsque Nomad Server reçoit une requête ''suggest'', il génère tous les points d'une itération (i.e., on utilise le paramètre GENERATE_ALL_POINTS_BEFORE_EVAL, déjà implémenté). Les points sont triés, et le nombre de points demandé est envoyé. Nomad Server n'attend pas que les points soient évalués, il continue simplement (ou il pourrait aller dans une boucle d'attente). 
  * Lorsque Nomad Server reçoit une commande ''observe'', il met la cache à jour.
  * La commande ''set_state'' est à voir plus en détail (implémentation dans un deuxième temps). Elle serait similaire à ce qu'on fait déjà avec le hot restart: Il s'agit de donner les bonnes valeurs au mesh size, barrier, cache et autres afin que Mads reparte d'un point donné. Cette commande est utile pour le parallélisme (donc est-ce que plusieurs Nomad Server rouleraient en parallèle?) 
  * Nomad Server roulerait continuellement, jusqu'à recevoir une commande lui disant de s'arrêter. Les conditions d'arrêt de Mads seraient ignorées.
  * L'étape Update de Mads évalue s'il y a eu un succès ou un échec en regardant les points dans la cache. 
    * Succès: facile à identifier parce qu'on a encore l'ancien meilleur point. -> refine mesh
    * Échec: Tous les points ayant été générés autour du frame center courant ont été évalués, et aucun n'est un succès. -> enlarge mesh
    * Sinon: On ne touche pas au mesh.
  * Lier les commandes Oríon à des callbacks, par exemple au début de l'étape Update.
  * Le code de Nomad Server inclut le code de Nomad. On pourrait avoir 2 exécutables - ''nomad'' et ''nomad-server''.

Il y aura des détails à régler, par exemple le calcul de hMax, mais j'estime que ce ne sera rien de trop compliqué.

Avantages:
  * Intégration dans Oríon bien sur
  * Intégration ailleurs éventuellement
  * Utile pour d'autres concours à venir, et pour la communauté ML en général, car on va parler leur langage
  * Nomad standard n'est pas affecté

Inconvénients:
  * Plus long à implémenter. Estimé: 2 semaines à temps plein
  * Il faut s'assurer de ne pas briser la théorie

Résumé

Note : En modifiant cette page, vous acceptez que le contenu soit placé sous les termes de la licence suivante : CC Attribution-Share Alike 4.0 International