Herezh++

bonjour Julien,
Je modifie le tracker en "evolution" car il me semble que c'est des évolutions au fonctionnement actuel que tu sollicites.
Ceci étant, je vais essayer de répondre à ta demande mais je propose plusieurs étapes différentes.
1) je vais essayer d'introduire la possibilité indiquée dans le #268 pour appliquer les CL à chaque itération, ceci dans l'algo choisit,
2) je vais essayer d'introduire le fait de disposer spécifiquement sur une ref de noeuds des grandeurs "moyenne, maxi, mini etc. sur ref N" de manière identique à ce qui est disponible en sortie maple. Une fois ces grandeurs calculées, elles sont automatiquement exportées comme grandeurs globales. L'intérêt est a priori un calcul très rapide des ces grandeurs.
3) définir des variables globales qui serait == à des fonctions nD sur des noeuds.

A priori 1) + 2) permettraient de réponse à ta demande immédiate. Le 3) est plus ambitieux et en fait en pratique différent du cas des intégrales car cela n'interviendra a priori pas du tout aux mêmes endroits et due au fait des encapsulages (indépendances) objet cela va nécessiter une gestion particulière. A priori je ne pense pas que ce soit trivial a implanter mais à voir au bilan final.

Le pb, c'est que j'ai plusieurs choses sur le feux et il faut que je finalise les différents chantiers correctement si je veux éviter d'avoir des incohérences. De plus il faut également que je respecte le plus possible la chronologie des affaires. Pour cela j'aimerais bien avoir un endroit pour dire qu'est-ce qui est en route et comment cela avance...

bref... affaire en cours, je vais avancer et je te tiens au courant

j'ai trouvé comment mettre en place une "roadmap". L'idée est de décrire les différentes évolutions d'herezh qui sont en cours.
Il faut regarder par exemple dans le projet "Herezh++" l'onglet roadmap
a suivre

suite à l'évolution #274 (cf. roadmap) la version 6.977 intègre
- la possibilité de relire les CLL à chaque itération
- la possibilité de faire une statistique sur une ref de noeud (cf. doc) ce qui génère une variable globale. Ensuite utilisation d'une variable relais pour utiliser les infos de la statistique dans une fonction nD

- l'évolution apporte également, sous forme détournée, la réponse au point 3). En effet, maintenant pour définir une variable globale sur une fonction nD s'appliquant sur un noeud on peu:
a) définir une ref sur le noeud
b) définir une statistique sur cette ref
c) définir une variable utilisateur (ici relais) sur la statistique ce qui permet d'obtenir la valeur de la fonction nD
et la statistique permet d'étendre le principe à plusieurs noeuds, en particulier à N_tout

Me dire si cela permet de répondre à la demande.
Merci

ci-joint mon calcul à tout hasard

j'ai commencé par vérifier à l'état initial les coordonnées des centres moyens des 5 sets de noeuds qui m'intéressent : N_seg_fps_1, 2, 3, 4 et 5

dans un premier temps, c'était ok pour le 1, 2 et 3. Puis tout à coup, ça ne fonctionnait plus pour le 4 et 5. En fait je me suis aperçu d'un segmentation fault en fin de calcul. Et puis, les bugs ont commencés à être aléatoires. J'espère que ça le fera chez toi.

J'ai bloqué tous les noeuds dans le calcul test.info de l'archive pièce jointe. Le .CVisu est configuré pour sortir les stats du set N_seg_fps_3.

Voici les 4 bugs que j'ai constaté :

bug 1) le meilleur cas. Le calcul termine malgré un segmentation fault final. Le résultat est ok. Je le constate en comparant les colonnes 3, 13 et 23 (moyenne) par rapport à ce que me renvoie le script a_her.pl en lançant : a_her.pl toto.her N_seg_fps_3

bug 2) le calcul plante juste après l'affichage de l'incrément avec l'affichage suivant : ======================================================================
INCREMENT DE CHARGE : 1 intensite 1 t= 1 dt= 1 ======================================================================
Warning : attention cas non traite: ("""suite de symboles incompréhensibles que je ne met pas ici car ça fait bugger redmine""") voir image pièce jointe
Segmentation fault

remarque : ce cas est rare, je l'ai obtenu qu'une seule fois

bug 3) idem 2) mais avec l'affichage suivant : ======================================================================
INCREMENT DE CHARGE : 1 intensite 1 t= 1 dt= 1 ======================================================================
Erreur : degre de liberte non defini !

UneVariable() 
Erreur : valeur incorrecte du type Enum_boolddl !
NOM_DDL(Enum_boolddl )

passage dans la methode Sortie

======== erreur (Sortie) detectee ======

bug 4) idem 2) mais avec l'affichage suivant : ======================================================================
INCREMENT DE CHARGE : 1 intensite 1 t= 1 dt= 1
Segmentation fault

REMARQUE IMPORTANTE : j'ai constaté que si on efface les fichiers résultats (.BI, .PI, etc...), on obtient presque toujours le bug 1), donc un calcul qui se déroule bien avec juste un seg fault final. Par contre, en présence des fichiers d'un calcul précédent, on obtient presque toujours l'un des 3 autres bugs.

Assez surprenant que le calcul soit perturbé par un calcul précédent alors que ça n'a rien à voir avec un RESTART.

parfait,
merci pour ton retour.
Remarque: je pense que c'est mieux d'utiliser une fonction vectorielle plutôt que 3 fonctions scalaires (coordonnées) cf. l'exemple que j'ai mis sur #274 cela va te permettre d'utiliser une seule variable relais, cela devrait être plus économique.
Bon... à voir
En tout cas je suis content que cela fonctionne.
Je ferme le ticket