Comment configurer ANSYS RSM v18 avec un cluster sous PBS Pro

ANSYS v18 a été récemment publié apportant quelques nouvelles fonctionnalités intéressantes et en tant que fervent utilisateur d'ANSYS Fluent, il semble que cette nouvelle version apporte beaucoup d'améliorations de ce côté permettant une progression complète du CAD à la simulation à travers le même interface avec un Mesher Fluent beaucoup plus fort (anciennement connu sous le nom de Tgrid).

Du côté HPC, le changement majeur pour la configuration RSM est l'apparition d'ARC: ANSYS RSM Cluster, ce qui permet de créer un véritable cluster pour les tâches distribuées. Auparavant, le service RSM était divisé en deux composants RSM Manager et RSM Server et consistait à envoyer des tâches à l'un des serveurs RSM via le gestionnaire RSM, mais il n'était pas possible d'utiliser plusieurs serveurs en même temps, ce qui nécessitait un planificateur de taches tiers (Windows HPC, PBS, LSF, ...). ARC semble être là pour résoudre ce problème et supprimer le besoin d'un autre planificateur . Comme vous l'aurez compris, ANSYS a décidé de s'attaquer à un nouveau secteur avec son propre planificateur de tâches / gestionnaire de charge de travail.

Certains de ces changements incluent:

  • Un seul service

Avec le nouveau V18, ANSYS a supprimé les services du serveur RSM. Le gestionnaire RSM permet désormais à un client de communiquer directement avec un gestionnaire de workload / planificateur de taches, qu'il s'agisse d'ANSYS ARC ou d'un tiers. Un client communique d'une machine à un service RSM Manager distant soumettant le travail au planificateur, ou communique avec un gestionnaire RSM local à un planificateur distant via d'autres moyens de communication (c'est-à-dire SSH).

  • Plus d'application RSM :{

En lisant les «changements importants pour les utilisateurs R17» dans le Guide de l'utilisateur de RSM v18, mes yeux se sont arrêtés là-dessus:

L'application de configuration RSM ne fournit plus d'interface de surveillance de travail autonome. La surveillance des tâches est désormais intégrée dans Workbench et EKM.

La perte d'une application RSM autonome devrait susciter quelques inquiétudes parmi les utilisateurs d'ANSYS! Depuis quelques versions, ANSYS a ajouté une nouvelle fenêtre dans Workbench (une fenêtre 'jobs') qui récupérait simplement les mêmes informations que l'application RSM mais l'information était toujours disponible dans l'application RSM Standalone, permettant à un utilisateur de vérifier le statut d'un travail sans avoir à ouvrir l'application Workbench, pas si petite! En V18, l'application autonome n'existe plus. Pourquoi !!?

Edit: il semble qu'ANSYS aurait corrigé le tir à la version 18.1 et a ressuscité l'application RSM Monitoring standalone. Le seul problème est que celle-ci n'affiche les jobs que pour l'utilisateur et la machine courante!
  • Le nouvel assistant de configuration RSM

Un point positif est l'ajout de ce nouvel assistant pour configurer le cluster RSM:

  rsm.png

Figure 1. Le nouvel assistant RSM

 

Le petit écran d'ordinateur à l'intérieur de la fenêtre principale semble indiquer que cette transition vers un nouveau RSM pose (peut-être) les bases d'une nouvelle interface qui devrait venir dans les prochaines versions ...? 

À l'aide de ce nouvel assistant, la possibilité de configurer directement les files d'attente RSM à partir de la machine client à la place de la machine sur laquelle est installé le gestionnaire RSM permet à chaque utilisateur d'avoir sa propre configuration stockée sur son propre ordinateur. De plus, si vous vous connectez à un planificateur tiers, la dernière étape vous réjouira du fait que toutes les files d'attente du planificateur seront transmises automatiquement au RSM.

 

Même si cela peut être pratique, les responsables informatiques peuvent également trouver utile de disposer d'une configuration RSM gérée de manière centralisée pour partager avec tous les utilisateurs au lieu de configurer chaque ordinateur un par un. Les étapes suivantes vous montreront comment configurer le RSM v18 avec un cluster distant exécutant PBS Pro sous Linux et partager la configuration avec d'autres utilisateurs.

 

Pas à pas

Sur la machine du serveur

  1. Installez le service RSM Manager
  • Connectez-vous à votre machine Linux / Windows et ouvrez une invite de terminal / commande
  • Navigez vers:
    • Linux: /ansys_inc/v180/RSM/Config/tools/linux/
    • Windows: C:\Program Files\ANSYS Inc\v180\RSM\Config\tools\windows

(ou votre dossier choisi pour l'installation)

  • Tapez:

./rsmconfig -mgr

Un service sera installé (à l'intérieur de /etc/init.d pour Linux ou un service Windows) et configuré pour démarrer automatiquement au démarrage.

  1. Partagez votre dossier Staging/Scratch via le partage Samba/Windows.

Notez que le V18 n'utilise pas les anciens partages RSM_Mgr et RSM_Cs. Vous pouvez maintenant spécifier le nom de votre partage intermédiaire. Dans notre cas, nous utilisons le même dossier pour limiter le nombre de réplications.

 

Sur une machine client

1. Créez un dossier partagé sur l'ordinateur client ou un chemin disponible centralement.

Par exemple un NAS ou un centre de données. Ici, nous allons utiliser:

\\nas\RSM\

2. Pointez votre configuration vers ce nouveau dossier

Ouvrez une invite de commande et tapez:

“C:\Program Files\ANSYS Inc\v180\RSM\bin\rsm” appsettings set JobManagement ConfigurationDirectory \\nas \RSM\

Vous devriez maintenant voir un nouveau dossier dans votre dossier partagé nommé ANSYS avec un chemin complet menant à RSM\Ansys\v180\RSM\ avec à l'intérieur un fichier *.rsmcc pour chaque cluster configuré.

 

3. Ajouter un nouveau cluster
  1. Démarrer l'assistant de configuration RSM
  2. Ajoutez le nom du cluster distant, le type de planificateur (PBS) et entrez un nom:

 

name.png

Figure 2. Ajouter un nouveau cluster 

Une fois que vous cliquez sur Appliquer, si cela fonctionne, vous devriez être en mesure d'aller à "File Management"

 

  1. Décider du type de transfert

Dans la plupart des cas, vous choisirez en tant que "Gestion de fichiers client à cluster" la méthode "Transfert de fichiers OS": transfert vers le répertoire de transfert via un partage réseau.. Un environnement plus sécurisé pourrait établir un transfert SCP mais perdra en vitesse de transfert.

  • En tant que "Partage réseau du cluster" et "répertoire", entrez votre répertoire de transfert, dans notre cas /scratch

files.png

Figure 3. Gestion de fichiers 

N.B.: comme le partage de réseau, je soupçonne qu'un chemin UNC représentant le répertoire de partage fonctionnerait mais cela conduit à une erreur lors du démarrage de la job

“UNC path \\machinename\scratch\9dw5rij7.qvb passed to Linux machine.”

Il semble que le partage réseau est passé en tant que répertoire de travail ... Pour l'instant, utilisez le chemin Linux pour les deux jusqu'à résolution.

Edit: v18.1 semble avoir corrigé cette erreur et vous pouvez maintenant utiliser le UNC path en tant que partage réseau. La seule chose à noter est que si vous utilisez un sous-répertoire, vous ne devez le spécifier que sur l'adresse du répertoire partagé et non sur l'adresse du répertoire sur le cluster, par exemple:

Cluster staging network share: \\machinename\scratch\my-sub-scratch

Cluster staging directory: /scratch

 

  • Dans la section “Cluster Side File Management”, vous décidez si vous souhaitez que le nœud principal copie les fichiers dans un répertoire de travail local sur le ou les nœuds sélectionnés pour exécuter votre travail. Ce type de comportement dépend du type de travail que vous souhaitez exécuter:

> Pour les jobs structurels/FEA, beaucoup de fichiers peuvent être écrits localement et les I/O sont cruciales, donc une réplication sur un partage local peut être utile pour un accès direct.

> Pour les jobs CFD, généralement quelques fichiers sont écrits et il suffit de travailler dans un partage réseau.

Si vous disposez d'une infrastructure réseau solide, comme InfiniBand ou 10-Gigabit Ethernet, la combinaison du répertoire de transfert et du dossier de travail est bénéfique en termes de réplication de fichiers.

Validez et accédez aux files d'attente.

 

  1. Détecter les files d'attente

Si votre configuration est correcte, cliquez sur le bouton "Actualiser les files d'attente" et le RSM doit importer toutes les files d'attente PBS en créant une file d'attente RSM correspondante pour chacune d'entre elles.

queues.png

Figure 4. Files d'attente importées

 

Vous pouvez maintenant décider quelles files d'attente vous voulez importer et le nom correspondant dans le RSM que vous voulez. Essayez votre configuration avec une job de test en soumettant vos informations d'identification de soumission de travail.

 

Si vous gérez les fichiers différemment selon la file ou le type de travail, je recommande de créer une autre configuration de cluster avec les mêmes paramètres sauf dans la fenêtre de gestion de fichiers (par exemple, une configuration CFD pour travailler dans le répertoire de transfert et une autre pour travailler dans le scratch).

Une fois que vous avez fermé cette fenêtre et que vous avez enregistré votre configuration, votre nouvelle configuration apparaitre dans le dossier partagé. Pour autoriser un utilisateur à utiliser la même configuration, exécutez 2.b. sur chacune de vos machines client.

Faites-nous part de votre expérience et de votre impression sur cette nouvelle version qui apporte beaucoup de (bonnes / mauvaises?) nouvelles fonctionnalités.

 

Bonne chance

Share this post

Commentaires (2)

  • Quentin

    Hi Ritvij, 18.1 adds a modification on the default shell used and you need to add the PBS binaries folder to the PATH. Modify the following file to add PBS folder to the RSM PATH: /ansys_inc/v182/RSM/Config/tools/linux/rsm_env_profile and add: export PATH=$PATH:/opt/pbs/bin or the correct PBS directory if yours differs.

    12/12/2017, 6:32:06 PM
  • Ritvij Vyas

    I have done the exact same steps for RSM18.1; and it does not work. It seems to not find where the PBS executables are located. it is going to /tmp to find them. It is working perfectly in 18.0

    8/7/2017, 12:47:26 PM

Laisser un commentaire