Herezh++

Bonjour Gérard,

J'aimerais pouvoir réaliser une moyenne glissante au cours des itérations d'une grandeur globale, mettons l'énergie cinétique. L'idée serait de définir un critère, par exemple pour l'amortissement mixte ou pour la sortie du calcul.
Je ne vois pas comment faire ça avec une fonction nD puisque elle ne connait que les grandeurs à l'incrément courant. Il y a bien la notion de "variables utilisateurs" que j'utilise par ailleurs mais je ne vois pas comment les utiliser pour ce besoin.

Si tu as des solutions merci de m'en faire part. Julien est bien venu dans cet échange !
Frank

Bonjour Frank,
je pense que la bonne solution c'est d'utiliser une fonction nD externe qui permettent de sauvegarder les grandeurs que l'on veut et de les réutiliser à la demande suivant un algo propre à l'utilisateur: ce sera facile et souple de le faire via une méthode externe en python par exemple (ou autre).

Salut Frank,

je ne connais pas de fonctions nD interne à Herezh qui puissent stocker des valeurs (car il faut stocker plusieurs valeurs d'énergie cinétique).

mais il y a FONCTION_EXTERNE_ND. Si la fonction est définie à l'extérieur de Herezh++, tu pourras stocker ce que tu veux. Par contre, pour le fonctionnement, je peux pas aider, je n'ai jamais utilisé. Il y a bien la doc Herezh à ce sujet, mais entre la doc et la pratique sur ce genre de truc technique, il y a un gap. Le mieux serait que Gérard te donne un exemple simple qui tourne. ça ferait une bonne base. Si ce genre d'exemple existe dans la base de vérification d'Herezh, ça serait l'idéal.

Oui bien sûr c'est la méthode ultime qui permet de tout faire ou presque. J'avais réussi à les mettre en oeuvre sur des cas tests élémentaires lorsque tu les as développées mais le principe du "tuyau" s'il fonctionne sous Linux ne fonctionne pas dans le Shell Linux intégré à Windows. Cette méthode n'est donc pas fonctionnelle pour le Cnes. Dommage...

Merci pour ta réponse rapide.
Frank

Merci Julien pour ta réponse que je n'avais pas remarqué. Elle est en phase avec celle de Gérard.
Bon ça fait plaisir de vous lire et de vous imaginer vous aussi devant votre PC :-)
A quand une bonne poignée de main et le choc d'un verre de bière !

Peut-être que c'est le moment pour explorer le fait que les pipes ne fonctionnent pas ... car l'utilisation de fonctions externes te donnerait beaucoup de latitude.
a priori je ne vois pas pourquoi dans l'environnement interne unix (qui côtoie windows) les pipes ne fonctionnent pas, car il ne s'agit pas d'une émulation (si j'ai bien compris) mais d'un vrai unix (ou linux) et dans cet environnement les pipes sont utilisés partout: donc il devrait y avoir plein de pb ... donc si le système fonctionne correctement il y a des chances que les pipes sont opérationnel: reste à savoir comment ?

Oui tu as raison, je vais restaurer mes cas tests et explorer ce problème de pipe. Comme pour tout problème en info je ne dois pas être le seul à l'avoir rencontré.
Je te tiens au courant
Frank

oui il doit sûrement y avoir une solution à ce problème de pipe.

si malgré tout, ça ne marche pas, j'aurais bien une solution à tester mais elle est affreuse et non garantie de succès :)
ça impliquerait un maillage fictif, le ddl TEMP, les variables utilisateurs et quelques fonctions nD (et tout ça sous réserve que TEMP soit accessible comme variable utilisateur)

creuse l'histoire du pipe. Si t'es désespéré, on pourra y revenir.

Bonjour Gérard, Julien

Je poursuis mes investigations sur le bon usage de l'amortissement mixte.
J'ai un cas très sévère d'un gros ballon sous largueur (demande Cnes) qui ne converge pas en RD cinétique à 5e-4. J'ai repéré une valeur basse de le norme de convergence pour le passage en visqueux de 6.5e-4, avec un lambda qui passe de 2 à 40.
En 1 itération après la bascule l'énergie cinétique passe de 1e2 à 1e8 !

Je suspecte un problème lié au recalcul de la masse lors du passage cinétique->visqueux. D'après la doc (§20.3.7) avec les paramètres ci-dessous la masse est recalculée au passage. Est-ce un bon choix ? Avez-vous des propositions de paramétrage ?

Difficile de faire beaucoup de test car il faut 24h pour faire 2000 itérations !!!

typeCalRelaxation= 4 lambda= 1 type_calcul_mass= 2 option_recalcul_mass= 0
parametre_calcul_de_la_masse_ casMass_relax= 3
lambdaAvecPonderation_Globale_ f_lambda
propCinetiqueAvecPonderation_Globale_ f_propCinetique
parametre_calcul_de_la_viscosite_ type_calcul_visqu_critique= 1 opt_cal_C_critique= 1 f_= 0.9

- En se mettant en mode debug, peut-être regarder l'intensité des masses fictives via une sortie d'isovaleurs.
La masse étant calculée à partir de la matrice de raideur, si cette dernière a des valeurs bizarres cela peut conduire à des masses bizarres.
Une raideur bizarre peut provenir a) d'une loi mise en défaut, b) d'un élément distordu (ex: surface nulle) ??? c) d'une combinaison de a) et b)
Donc peut-être sortir également en iso, la contrainte de mises, le module de compressibilité, l'épaisseur ... la surface ... bref, explorer...
On peut aussi sortir en maple une statistique sur les masses fictives sur la ref N_tout histoire d'avoir directement les min, max etc et de voir s'il y a quelque chose de bizarre

- Dans le cas où on a des masses nulles (ou très faibles), et qu'on imagine que ça peut-être normal par exemple en transitoire, on peut limiter les faibles valeurs à l'aide du paramètre choix_mini_masse_nul=
- possible aussi de désactiver le recalcul de la masse via le mot clé: et_pas_recalcul_masse_a_la_transition_
ou en utilisant une fonction nD via nom_fct_nD_option_recalcul_mass_

Bonjour Frank,
est-ce que je peux clore ce post ?

Bonjour Gérard,
Il n'y a pas eu d'avancée sur ce sujet mais c'est ok pour ma demande. Merci

Frank