Réunion TAcq/Sophya - c++ std-11-17

Europe/Paris
200/0-Bleue - Salle Bleue (IJCLab)

200/0-Bleue - Salle Bleue

IJCLab

30
Montrer la salle sur la carte

Réunion TAcq/SOPHYA du jeudi 22 juillet 2021 

OdJ: le point sur le passage de SOPHYA à un standard récent de c++ ( >= c++11) pour permettre le développement du corrélateur logiciel optimisé dans TAcq.

  • Présents: Réza Ansari, Hadrien Grasland, Christophe Magneville , O. Perdereau (en salle bleue) 
  • Guy Barrand et Jean-Eric Campagne ( à distance , en zoom)  

• Discussion sur le passage de SOPHYA en standard c++11

Test de compilation en cours sur MacOS - parmi les petits problèmes rencontré, la confusion entre la fonction bind() de la librairie standard (en lien avec les sockets et primitives réseau) et la fonction std::bind() qui permet l'application partielle de fonction avec certains arguments fixés. Autre problème, différence sur la définition de ptr_diff. En effet, parmi les modifications introduites, il y a la définition des types d'entier et de float utilisés par sophya (int_4, int_8 ...) à travers les types c++ définies dans stdint.h : int_16_t , int_32_t , int_64_t ... (définitions de sophya en octets, et celles du c++ en bits)  - Le type utilisé pour les index de tableaux dans sophya (sa_size_t ) a été défini comme ptrdiff_t, mais cela pose problème, étant donné ptrdiff_t est défini comme long int ou long long int selon les plateformes/compilos. On décide de revenir à la définition de sa_size_t comme int_8 ou int_4.  

Pour les essais de compilation de la branche stdint de sophya, avec les flags de compilations pour >= c++11, destinée à devenir la branche standard : 

  • Hadrien teste sur Linux avec compilo récent
  • Reza teste sur Mac-OS
  • Christophe fait les tests sur linux avec le compilo standard / par défaut 

• Système de build et de test automatique de SOPHYA sur la plateforme gitlab  

Hadrien a mis en place le système de build et de test automatique de SOPHYA , sur une branche privée pour le moment. Ce test automatique prend en charge tout le build, y compris ProjectPI en 2 versions, X11 et wxWidget. Il lance aussi les programmes de test (au moins ceux qui renvoient un code de retour) et exécute les exemples (runcxx). Hadrien fait une demo du système  et décrit les principales étapes - On part en effet de l'instanciation d'une machine virtuelle Linux, sur laquelle Hadrien installe le compilo, puis les librairies externs, puis sophya...  Excellent travail,  très impressionnant ! 

Hadrien précise qu'il n'est pas actuellement possible de déployer le système de build automatique sur gitlab dans un environnement Mac OS (sans doute pour des raisons de licence Darwin

Changer le statut de Hadrien en maintainer , SOPHYA  et TAcq -> FAIT 

 

• Corrélateur et TAcq

 Hadrien ne prévoit pas de problème particulier pour le développement de son code optimisé de calcul de calcul des corrélations et son intégration dans la structure de TAcq avec les threads (tâches) de traitement et le système de partage de mémoire entre ces tâches. Par contre il envisage d'utiliser  le standard c++17 pour le code de TAcq qui comprend plusieurs fonctionalités utiles, parmi lesquelles aligned_alloc (allocateur avec spécification d'alignement mémoire, et qui est disponible depuis c version 2011. aligned_alloc permet par exemple d'allouer des std::vector correctement alignés. 

TAcq ne compilera donc qu'avec c++17 . Il faudra être attentif à l'alignement des données des paquets  BRPaquet, et surtout, les les paquets après FFT qui seront manipulés par le code du corrélateur. 

Question de Christophe (cmv) sur la disponibilité de compilo c++17 sur les machines de Nançay. Hadrien précise que CentOS 8 a un compilo suffisamment récent, mais la durée de vie courte de CentOS8 limite son usage dans le temps. CentOS 7 bénéficie d'un support de plus longue durée, mais  mais il faut installer un compilo plus récent

• PI/piapp  

Réza donne brièvement quelques nouvelles du développement de PI/piapp, la version avec wxWidget. Guy approuve la décision de maintenir une version de PI avec X11/Motif. Plus de détails lors d'une prochaine réunion.

 

Notes concernant des tests et essais faits après la réunion   

• Compilation et test de la branche git stdint sophya 

Hadrien a modifié la définition de sa_size_t sur la branche stdint et Réza a vérifié la compilation et l'exécution de tous les programmes de tests  listés dans la documentation sophya. Il s'agit au total de plus de 20 programmes de tests, et plus de 70 cas de tests avec le jeu des options et arguments. Hadrien propose de compléter si possible les quelques programmes qui ne renvoie pas de code retour (exemples; spar, tluc ...) afin d'étendre l'étendue de couverture des tests automatiques.

• Erreurs lors de l'exécution des tests 

Il y a effectivement deux programmes de test, plus exactement 2 cas qui renvoient un code d'erreur, comme Hadrien l'avait signalé. J'ai (Reza) détecté un troisième cas avec le programme tfitsdt - voir ci-dessous. Note: ces problèmes n'ont rien à voir avec la compilation c++11.

  1. Le programme tspm renvoie un code d'erreur pour le cas d'exécution avec les cartes sphériques de type ECP ( tspm E ). Il s'agit en effet d'une inconsistance dans les différentes routines du numéro de pixel de/vers les coordonnées angulaires (theta, phi). Il s'agit de savoir si le premier pixel d'un anneau (couverture complète) est à phi=0 ou phi=1/2 taille de pixel. Même question se pose pour theta, au moins dans le case de couverture partielle. Il faudra corriger cette erreur. L'opération est assez simple, mais il faut le faire avec soin, afin de ne pas introduire de bug supplémentaire. Il faut aussi vérifier l'exécution correcte de tlegpsht et tstisharp. Réza fera la correction avec Christophe.
  2. L'exécution du programme tmtdt se bloque lorsque le programme est lancé avec l'argument SWFITS (swap sur fichier fits, même si on spécifie un seul thread. Je (Réza) n'ai pas identifié le problème. Il se peut que cela soit une protection au niveau de c-fitsio, en effet, dans ce programme, le fichier fits est ouvert dans un thread différent de celui qui l'utilise. Même avec un seul thread pour le remplissage ou lecture de NTuple/DataTable, le programme utilise deux threads, le thread principal qui ouvre le fichier et un thread fils qui fait le travail, alors que le thread principal est en attente. En cherchant sur le web, on voit que c-fitsio a des limitations spécifiques et qu'il faut le compiler avec une option si on veut l'utiliser en multi-thread ( voir https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node15.html )      
  3. En lancement le programme tfitsdt qui effectue des vérification de création, remplissage, relecture de DataTable avec I/O fits (et aussi PPF), j'ai détecté un cas où le programme indique une erreur d'exécution. Il faut exécuter le programme avec l'option -useptr, ( tfitsdt -useptr 6 ) où on utilise l'accès au données d'une ligne de la table avec les pointeurs de l'objet DataTableRowPtr . C'est un mode d'utilisation sans filet de sécurité qui pose problème si on se trompe sur le type de donnée d'une colonne. Le code de retour renvoyé par tfitsdt a révélé en effet indirectement une petite inconsistance dans le code de la classe FitsHandler<BaseDataTable>. La DataTable relue depuis le fichier FITS modifiait le type des colonnes de type string. La table était créée avec trois colonnes string de type S, S16, S64  (S chaîne de longueur indéfinie, non fixée, S16 et S64 de longueur fixe, maximale de 16, 64 caractères), et à la relecture, on obtenait S,S64,S provoquant l'erreur à l'exécution. Cette erreur est due à la différence de type entre le pointeur de donnée de champ utilisé dans le code, et la donnée de la colonne. L'utilisation de DTCell et les opérateurs de conversion assure un accès aux données conforme à la nature des données, et n'occasionnait pas d'erreur à l'exécution, malgré la petite différence des types de chaînes de caractères après relecture des tables depuis le fichier fits (cas d'exécution tfitsdt 6 ) L'action du programme était conforme à la logique du code du handler fits dans le fichier FitsIOServer/fitshdtable.cc. Les trois colonnes S,S16,S64 donnent comme type de champ ds le BINTABLE 72A,16A,64A (72 étant la valeur demandée par défaut pour les chaînes de caractères ds  tfitsdt.cc). A la relecture, le test sur la largeur en caractères des colonnes dans le code était <16  et <64  (tests d'inégalité stricte) pour la création de colonnes S16 et S64 respectivement. J'ai changé les tests d'inégalité strict en <=16 et <=64 pour retrouver les types de colonnes chaînes de caractères après relecture identiques à ceux de la table écrite, ce qui de fait élimine l'erreur à l'exécution de tfitsdt -useptr 6 . Notons que ce changement ds  fitshdtable.cc peut occasionner un effet de bord dans de rares cas, où pour un champ FITS 16A (ou 64A) par exemple, le dernier caractère d'une chaîne avec 16 (ou 64) caractères significatifs est perdu. En effet la longueur S16 et S64 des DataTable de SOPHYA inclue le caractère zéro (0) de terminaison de chaîne de caractère  c.  

Action : correction de le fichier fitshtable.cc - tests d'inégalité stricte transformé en <=16 , <=64 pour la création de champs de type S16 S64 lors de la lecture de BINTABLE fits . commit fait dans gitlab 

• Les typedefs stdint.h et  ptrdiff_t 

Hadrien avait proposé de vérifier la définition des types c++ int32_t int64_t , std::ptrdiff_t, comme indiqué ici https://stackoverflow.com/questions/4160945/long-long-int-vs-long-int-vs-int64-t-in-c

Reza a complété le petit programme qui est recopié ci-dessous. 

Les résultats d'exécution sur MacOS  10.14 , compilo Apple clang version 11.0.0 (clang-1100.0.33.17) :

 ---- Checking if is_int64<T> ... 
int:        0  -sizeof=4
int64_t:    1  -sizeof=8
long int:    0  -sizeof=8
long long int:    1 -sizeof=8
std::ptrdiff_t     0  -sizeof=8
---- Checking if is_longint<T> ... 
int32_t:    0  -sizeof=4
int64_t:    0  -sizeof=8
long int:    1  -sizeof=8
long long int:    0  -sizeof=8
std::ptrdiff_t     1  -sizeof=8

et sur Linux (machine deco) ,  g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

---- Checking if is_int64<T> ... 
int:        0  -sizeof=4
int64_t:    1  -sizeof=8
long int:    1  -sizeof=8
long long int:    0 -sizeof=8
std::ptrdiff_t     1  -sizeof=8
---- Checking if is_longint<T> ... 
int32_t:    0  -sizeof=4
int64_t:    1  -sizeof=8
long int:    1  -sizeof=8
long long int:    0  -sizeof=8
std::ptrdiff_t     1  -sizeof=8


Source du programme de  vérification des typedefs de stdint.h de c++ 

sh> g++ -std=c++11 -o tst_type tst_type.cc


#include <iostream>
#include <cstdint>

template <typename T>
bool is_int64() { return false; }

template <>
bool is_int64<int64_t>() { return true; }

template <typename T>
bool is_longint() { return false; }

template <>
bool is_longint<long int>() { return true; }

int main()
{
  std::cout << "---- Checking if is_int64<T> ... " << std::endl;
  std::cout << "int:    \t" << is_int64<int>() << "  -sizeof="<<sizeof(int) << std::endl;
  std::cout << "int64_t:\t" << is_int64<int64_t>() << "  -sizeof="<<sizeof(int64_t) << std::endl;
  std::cout << "long int:\t" << is_int64<long int>() << "  -sizeof="<<sizeof(long int)  << std::endl;
  std::cout << "long long int:\t" << is_int64<long long int>() << " -sizeof="<<sizeof(long long int) << std::endl;
  std::cout << "std::ptrdiff_t \t" << is_int64<std::ptrdiff_t >() << "  -sizeof="<<sizeof(std::ptrdiff_t ) << std::endl;
  
  std::cout << "---- Checking if is_longint<T> ... " << std::endl;
  std::cout << "int32_t:\t" << is_longint<int32_t>() << "  -sizeof="<<sizeof(int32_t) << std::endl;
  std::cout << "int64_t:\t" << is_longint<int64_t>() << "  -sizeof="<<sizeof(int64_t) << std::endl;
  std::cout << "long int:\t" << is_longint<long int>() << "  -sizeof="<<sizeof(long int) << std::endl;
  std::cout << "long long int:\t" << is_longint<long long int>() << "  -sizeof="<<sizeof(long long int) << std::endl;
  std::cout << "std::ptrdiff_t \t" << is_longint<std::ptrdiff_t >() << "  -sizeof="<<sizeof(std::ptrdiff_t ) << std::endl;

  return 0;
}

 

 

Il y a un compte-rendu associé à cet événement. Les afficher.