HTG : HTG HIc Readers Redesign
Bonjour @maxime-stauffert,
En l'état, l'HTG HIc Readers exploite la capacité de l'HTG à définir une indexation entre l'offset d'une cellule géométrique (offset OffCell allant de 0 à GetNumberOfCells()-1 inclus) vers un offset dans le tableau de champs de valeurs (offset OffField allant de 0 à GetGlobalNodeIndexMax() inclus). Cette indexation est intrinséquement liée à l'HTG à travers le GetGlobalIndex() retourné au niveau d'un cursor.
Cette façon de faire, historique, pause un gros problème de fond. Il impose que tout nouveau champ sur cet HTG doit être dimensionné à GetGlobalNodeIndexMax() + 1 et non à GetNumberOfCells(). Ainsi, PureMask doit être dimensionné à GetGlobalNodeIndexMax()+1 (fix automne 2023).
De plus, cette façon de faire est incohérente avec la philosophie générale de ParaView/VTK qui considère que les champs de valeurs sont dimensionnés à GetNumberOfCells() (il est à craindre que les calculettes se limitent à cette dimension lors de la construction d'un nouveau champ).
Nous n'avons donc d'autres choix que :
1- de modifier l'HTG pour ne plus utiliser d'indexation utilisateur, mais une indexation automatique implicite voir implicite par partie pour le cas où l'on revient sur un HT ; cette indexation retourne sur un HTG tous les indices dans [0; GetNumberOfCells()[ ; ce travail rendra obsolète les méthodes SetGlobalIndexStart() (cette information sera stocké au niveau de l'HTG sous la forme du current last offset) et SetGlobalIndexFromLocal() (tout raffinement fera incrémenter ce current last offset au niveau de l'HTG tout en incrémentant le first/last index... pouvant être par partie) ; CE TRAVAIL POURRA ETRE REALISE DANS UNE SECONDE PHASE, D'UNE CERTAINE FACON IL EST PLUS DE L'ORDRE DU NETTOYAGE QUE DE L'IMPLEMENTATION MEME SI UN TRAVAIL D'INDEXATION AUTOMATIQUE EST A METTRE EN PLACE
2- de modifier le lecteur afin de construire d'un côté l'HTG ; notre avantage c'est que l'usage code AMR maison garantit une construction unique et continue d'un HT, on fera donc une construction du point de vue du maillage HTG en indexation implicite (DANS UN PREMIER TEMPS A L'ANCIENNE AVEC SetGlobalIndexFromLocal()) et :
-
les champs de valeurs construits par le Readers seront donc dimensionnés à GetNumberOfCells() propre à chaque HT ; on fera cela en exploitant au mieux les tableaux virtuels (constant et concaténation pour vtkDomainId, valeurs discrétes pour level par ex) ;
-
les champs de valeurs lus par le Readers seront concacténés et présenté via un tableau virtuel avec indexation prenant en entrée OffCell pour retourner un OffField qui sera alors celui du champs de valeurs lus concaténés ; cette indexation est dimensionnée à GetNumberOfCells() et retourne une valeur entre [0;GetNumberOfCells()[ ;
-
les interfaces sont des champs de valeurs qui sont lus mais ne concernent pas toutes les cellules, voir tous les sous-domaines ; avec l'emploi de tableau virtuel (indexation, valeurs discrètes, etc), on construira deux champs vectoriels dimensionnés à GetNUmberOfCells() suivant OffField, pour être comme un champ lu.
En plus du bénéfice ici indiqué, cela sera l'occasion de parcourir le coide HerculeDataSourceHIc.
J'aurais tendance à conseiller une réécriture complète de cette partie afin que l'équipe Themys s'approprie pleinement le code source, tout en s'inspirant bien sûr de l'existant.
Quoiqu'il en soit les interventions devront se faire dans :
-
HerculeDataSourceHIc/HerculeDataSourceHIc_GetData_ProcessTreeNode.h pour l'aspect description du maillage :
-
dans le constructeur pour faire SetGlobalIndexStart() dans le
constructeur
d'un HT et interdire l'intervention dans un HT existant ; -
afin de ne plus faire les trois appels à
SetGlobalIndexFromLocal
dansrun
; -
du fait que le stockage est en largeur alors que la construction est "en profondeur", une indexation est indispensable pour matcher OffCell_to_OffField ; (le code actuel prune les sous arbres correspondant à une cellule coarse masquée mais dans une phase de simplicité, peut-être sera-t-il plus simple d'ignorer cette fonctionnalité afin que OffCell et OffField couvre [0;GetNumberOfCells()[ par HT, bijection) ;
-
-
HerculeDataSourceHIc/HerculeDataSourceHIc_GetData_All_Fields.cxx pour supprimer la notion expectedSize ;
-
HerculeDataSourceHIc/HerculeDataSourceHIc_GetData_Fields.cxx modifier le code correspondant à la création de champ :
-
comme VTK_LEVEL (ce champ pourrait être construit via GenerateFields via l'emploi d'un curseur, alors qu'aujourd'hui on le stocke durablement), VTK_OCTREE_LEVEL (idem), VTK_DOMAIN_ID (ce champ est nécessairement construit par le Readers par concaténation de tableau virtuel constant ; on pourrait le produire par défaut au vu de son coût "nul" ) ;
-
les champs VTK_INTERFACE_DISTANCE et VTK_INTERFACE_NORMAL sont lus à travers la méthode mixtes() qui va produire l'équivalent d'un champ sur le matériau, il faudra donc ensuite le mettre dans un tableau virtuel exploitant une indexation commune, OffCell_to_OffField ; la particularité des interfaces, c'est qu'elles ne sont pas décrites sur toutes les cellules ni sur tous les sous-domaines, il faudra donc exploiter les tableaux virtuels (discrètes, constant, composites) afin de rediriger les valeurs au défaut intecepts (0, 0, 2) et normals (0,0,0) ;
-
les autres devront être construit avec un tableau virtuel exploitant une indexation commune, OffCell_to_OffField ;
-
-
HerculeDataSourceHIc/HerculeDataSourceHIc_GetData_Mixtes à la charge de construire un champ correspondant à un champ sur le matériau, c'est à dire de même dimension.
Même si je ne présuppose pas de la façon d'intervenir je pense qu'à plus d'un titre nous aurions intérêt à réécrire le lecteur suivant ce nouvelle éclairage. Cette réécriture devra être réalisée par l'équipe Themys comme la confirmer @guillaume.peillex. Contrairement à la première monture que vous avez devant vous qui a nécessité à peine quelques semaines d'écriture en s'inspirant grandement de l'existant afin de tenir le jalon 2020, ici nous pourrions prendre le temps de définir une architecture découplant les appels à Hercule, tenant compte des différents types de maillages, etc suivant la nouvelle orientation décrite plus haut.
Je pense que ce travail est indispensable afin de stabiliser la description HTG. De plus, il me semble que si ce chantier est lancé, il nécessitera une exclusivité des acteurs afin d'éviter un étalement dans le temps propice à des erreurs (j'estime à un mois plein). Ce sera aussi l'occasion de commenter précisément le code (chose qui n'a pu être pleinement réalisé dans la première phase).