ACTUALITES

= Actualités =

MATRICS, SINUS et COSINUS, DILER opérationnels : les premiers benchs !
Se tenir au courant des évolutions en consultant les wiki ! On passe beaucoup de temps à communiquer par ce biais, c'est pour VOUS. Merci de lire par vous même, ** surtout le wiki de DILER qui concerne les licences et les logiciels à télécharger par tous, les aides sous LINUX aussi. **

-Bench ABAQUS comparatif sur une statique linéaire en direct solver d'1Mdof : le Xéon de dernière génération équipant Matrics et Cosinus affirme sa supériorité sur l'Itanium de Scalar (presque 2 fois plus lent) !! Cependant l'Itanium montre sa capacité de calcul multi-CPU de manière plus probante que le Xéon. Une fois de plus, on s'abstiendra d'utiliser plus de 2 CPU par calcul.

-Bench ABAQUS parallélisation sur MATRICS : on reprend le modèle précédent. La parallélisation sur MATRICS du job est 2 fois plus rapide que le partage du job sur SCALAR... L'implicite se parallélise plutôt bien !!! On retrouve ce facteur 2 entre le Xéon et l'Itanium. Le job parallélisé est plus légèrement plus rapide que le job partagé. La parallélisation est intéressante pour 8 CPU avec un coeur utilisé par noeud. On s'abstiendra donc d'utiliser plus de 8 CPU par calcul parallèle avec Abaqus.



-Bench ABAQUS modèle moyen de 5Mdof (bench officiel S7B d'Abaqus = serrage de culasse sur un moteur en statique NL). Le mode de calcul classique partagé et le mode parallèlisé sont testés. Conclusions : Remarques : sur les Xeons il fallait plus de RAM définie dans le .env (10000mb) que sur SCALAR (5000mb suffisent). **Enfin, on peut affirmer aujourd'hui qu'à l'UTC résoudre un problème de statique non-linéaire de 5 millions de ddl en un incrément avec quelques itérations est de l'ordre de l'heure.**
 * En mémoire partagée, SCALAR bat les Xéon en calcul quadri-coeur : on retrouve la valeur ajoutée des processeurs IA64. Cependant, SCALAR se fait battre par COSINUS en calcul mono-coeur et bi-coeur. MATRICS seul ne tient pas la route pour ce style de job car c'est le maître du cluster et il est doté d'une faible RAM (~8Go). On remarque que les pentes des Xéons de MATRICS et COSINUS sont les même, la pente de SCALAR est plus forte. Cela confirme que les cpu x86 sont moins bons en multi-coeur que les itaniums.
 * En mémoire distribuée, MATRICS montre qu'il permet de repousser les limites en utilisant seulement 4 coeurs/noeuds et constitue la solution optimale de résolution de cette classe de job ! Inutile d'utiliser plus de 4 noeuds, le gain n'est plus significatif. La pente du graphe est la plus forte, plus forte même que celle de SCALAR !



Old news
-RADIOSS fonctionne ENFIN sur SCALAR !!!! Voici les alias des différentes versions installées : alias cpradflex='cp /opt/altair/rd/radioss_exe/radflex5_linux radflex5_linux' alias rd_s44='/opt/altair/rd/radioss_exe/s44t_il' alias rd9_s44='/opt/altair/rd/radioss_exe/s44t_il9' alias rd_s51='/opt/altair/rd/radioss_exe/s51i_il' alias rd9_s51='/opt/altair/rd/radioss_exe/s51i_il9' alias rd_e44='/opt/altair/rd/radioss_exe/e44t_il' alias rd9_e44='/opt/altair/rd/radioss_exe/e44t_il9' alias rd_e51='/opt/altair/rd/radioss_exe/e51i_il' alias rd9_e51='/opt/altair/rd/radioss_exe/e51i_il9' -OPTISTRUCT fonctionne ENFIN également ! Voici l'alias pour le déclencher : alias optistruct='/opt/altair/os/bin/LINUX_IA_64/optistruct.linux_ia64' Syntaxe : optistruct -nproc=xx -ramdisk=xxx -fem TOTO.fem avec nproc=N nb de cpus ramdisk= taille mémoire [MB] fem input file
 * Avancées suite HYPERWORKS**

Scratch SCALAR
Les deux nouveaux disques de 300GO chacun sont installés en RAID0 - c'est à dire, que l'accès est 2 fois plus rapide qu'à un seul disque et le volume total de stockage est augmenté de 600GO; ce nouveau répertoire de scratch s'appelle **/bigscratch/calculs** Il faut créer votre répertoire de calcul dans ce répertoire. Pensez à configurer les codes (ABAQUS, ANSYS...) de manière adéquate (exemple pour ABAQUS : rajouter la ligne scratch = "/bigscratch/calculs" dans abaqus_v6.env) si vous avez de gros calculs, qui ne passent pas sur **/scratch** ; pour des calculs de taille moyenne (jusqu'à 5Mdof), **/scratch** reste intéressant car il est réalisé avec 4 disques de 73 GO en RAID0 pour un volume total de 292GO (l'espace réel est plus petit, car le même espace sert à stocker les comptes des utilisateurs), donc **/scratch** est supposé 2 fois plus rapide que **/bigscratch/calculs**, qui lui-même est 2 fois plus rapide qu'un seul disque. Une commande pour aller sur ce gros scratch directement : gobig

(Note de Piotr : On ne peut pas cumuler les deux types de disques : 73GO et 300GO dans la même configuration RAID0, donc c'est à vous de choisir : **/scratch** ou **/bigscratch**)

//Bench d'un petit modèle (1,052,661ddl) : même temps de résolution sur les deux scratchs en statique linéaire (730s vs 734s) ! Ce résultat est obtenu avec 5 calculs sur /scratch (1 abaqus + 4 FEAP) et 1 calcul sur /bigscratch/calculs (1 abaqus). Il est à prévoir que plusieurs utilisateurs calculant sur// **/bigscratch/calculs** //vont significativement faire baisser ses performances...//