======================================================================= ======================================================================= POINTS A PRIORITE ELEVEE ======================================================================= ======================================================================= LONG TERME ========== * Multigrille et algebre lineaire en general. Resolution sur gros maillage, mailles allongees, ... + interaction avec parallelisme, periodicite. MOYEN ET COURT TERME ==================== SCRIPTS ET DOC ------------- * Documentation - doc noyau sur les nouveaux modeles de turbulence + ordre 2 en temps des TS - doc noyau sur LWC - doc utilisateur (et noyau ?) sur les nouvelles fonctionnalites electriques (module electrotechnique) - doc utilisateur de l'interface (quand stabilise) - ajouter si les tomes 1 a 5 en pdf sous doc/NOYAU - traduction en anglais de la doc - enrichir et refondre le tutorial, recuperer le tutorial Manchester - reecrire la doc Inimas (notations non coherentes avec le reste au niveau des CL) - doc noyau, resolp, revoir la formulation du paragraphe sur la definition de l'operateur L, avant l'equation 11. - doc noyau sur clipke - doc noyau calcul du pas de temps en compressible - doc noyau lois de paroi (IDEUCH=2) + MAJ de RCPROD et RCFLUX - doc noyau gradients et limitation des gradients - doc noyau distance à la paroi + y+ * Le "commente_exemple" de cree_sat est peut etre tres long, notamment sur Tantale * Benchmark machines - Mettre a jour le cas test FATHER (prendre un etat stabilise, gerer les sorties texte) + repasser le cas sur toutes les architectures - Preparer un cas plus dimensionnant (maillage FATHER de 4 millions d'elts ?) - Version allegee du code pour benchs externes * Reorganiser la base des cas tests IHM --- * Quand on ne visite pas la page des physiques particulieres, meme si on n'a rien a y faire, le code plante et demande de remplir usipph. * Modifier les tests sur les couleurs pour ne pas etre oblige de definir toutes les faces dans l'interface (si on les definit dans le noyau) * Pb des "d" quand on rentre des 1.D0 par megarde * Phys part, Matisse, suivi des evolutions du noyau (CL de sortie, ...) * Blinder le cas ou on change le nombre de variables dans usini1 (scalaire de plus ou changement de modele de turb). A priori, il y a seulement a relire nscaus dans CSVNUM BASE ---- * Remettre SRROM et DIFLT0 a -GRAND dans cpini1.F quand l'IHM leur redonnera une valeur par defaut * Ordre 2 en temps en v2f -> terme en f_barre a modifier (il est en RTP et pas RTPA donc ne doit pas etre extrapole mais interpole) * Supprimer usrubm * Dans les messages de verification -> renvoyer a l'interface graphique en meme temps que usini1.F ou autre * Dans jacobi et gradco (et bicgstab ?) on compare le residu en racine carree, alors que ce n'est pas nécessaire. Gain en temps ? * Loi de paroi + pb du jet impactant * Recuperer et tester le PISO du stage I85 (complements de tests) * Calcul de la distance a la paroi : - Pb de calcul de la paroi pour les suites de lecture en k-omega (calcul apres phyvar) -> faire un premier passage dans usclim avant phyvar pour calculer ITYPFB ? - Renforcer la robustesse du reperage des faces de paroi (parfois test sur ITYPFB=IPAROI, parfois test sur ICODCL=5) * Dans le cas 2 echelles, on calcule y+ a partir de uk. Or cette relation n'est pas vraiment valable dans la sous-couche visqueuse. Si le modele est bas-Reynolds (comme le k-omega), k va fortement decroitre en paroi et le y+ base sur uk sera trop petit. Comme on calcule ensuite u*=u_tau/y+, on obtient des valeurs tres fortes et non physiques de u*. Ce n'est pas un reel probleme car dans la sous-couche visqueuse, on n'utilise pas la valeur de u* dans les CL (vitesse, turbulence, scalaire). Mais l'affichage de u*=1.D5 dans le listing fait curieux !!! En modele HR, comme k est mauvais est decroit moins vite en paroi, on n'a moins ce probleme. On peut modifier clptur de la maniere suivante : si y+(uk) < YPLULI, alors on recalcule u*=SQRT(nu*u_tau/y) et y+=y.u*/nu ... a verifier qu'alors y+(u*) est toujours < YPLULI ? ... a replacer dans le contexte du travail sur YPLULI ? * Evaluer et renforcer la robustesse vis-a-vis des ss-prg utilisateurs -> par ex uselrc peut etre appele sans avoir ete mis dans FORT. -> cf. mail FA du 01/03/06 * Rajouter dans ustsns un exemple de forcage de debit. Ne pas utiliser la methode de la valid 1.1.0 mais plutot : save tsnm1 if(ntcabs.gt.1) then tsn = tsnm1*(Debit_voulu/max(Debit_calcule,1D-12)) tsnm1 = tsn else tsn = Rho*Vitesse_moyenne**2*Lambda_Moody/(2*Diam_Hydraulique) tsnm1 = tsn endif do iel = 1, ncel crvexp(iel) = volume(iel)*tsn enddo * En cas d'utilisation de van Driest, le Fourier max et le pas de temps sont calcules avant l'amortissement -> peut etre limitant * PARCOM et PERCOM de CLVOLC peut-etre redondants par rapport a cs_maillage_grd_calc COGZ ---- * Suites partielles (sans suivax) -> verifier la coherence avec les dernieres quantites stockees, i.e. verifier qu'on ne les utilise pas si on ne les a pas relues -> a faire en meme temps qu'une eventuelle possibilite de demarrage a froid * Modifs Libby-Williams (facteur 2 dans lwctss.F et correction dissipation associee) LAGR ---- * ICONFO est dimensionne en dur à 100 dans 3 sous-programmes (lagcel, lagnex, lagnwc) -> centraliser son dimensionnement et tester si le nb de sommets est > à 100. * Prevoir le cas ILAGR=2 pour INEEDY (i.e. forces de paroi) * Verif commentaires lagraf.F et lagout.F sur Ensight apres modifs AD ELEC ---- * uselrc n'est pas standard. Il est activé par IELCOR=1 et pas seulement par le fait de le placer dans FORT -> eliminer le test sur IELCOR dans scalai.F. Il faudrait cependant conserver un IELCOR dans uselrc pour activer le recalage par defaut prevu dans uselrc sans avoir a placer le ss-prg dans FORT. Attention, uselrc est commun a Joule et Arcs électriques. CFBL ---- * Stabiliser ! RAYT ---- * Transferer vers fvm le raybrd.F qui ecrit sa part ensight tout seul tranquillement sans se soucier du parallélisme .... ALE --- * Branchement de couplage avec Aster. Changement du numero de maillage fvm (10 par defaut) pour l'envoi vers Calcium * Recreer proprement des historiques de deplacement -> faire des historiques a noeud fixes et des histo a position geometrique fixee. * Non compatible avec la periodicite de rotation (a cause de inimas qui necessiterait de connaitre le gradient de w) -> au pire le changer en ne reconstruisant pas a ces points la * Compatibilite avec le compressible (equation sur rho, IFLMB0 pour inimas dans cfmsfl et cfmsgs ?) INTEGRATION DVLPTS EXTERNES --------------------------- * Integration aéros * Integration ALE (IFS) * Integration de modifs issues de l'affaire Saturne dans Salome * Modifs couplage homard * Integrations couplages CS/CS et autres dvlpts DESIDER ======================================================================= ======================================================================= POINTS A PRIORITE MODEREE OU FAIBLE ======================================================================= ======================================================================= SCRIPTS ET DOC ------------- * Refonte des Makefiles * Dans la doc, on pourrait creer un "apropos", par exemple "apropos gradient" qui renverrait a un exemple de calcul de gradient dans un sous-programme utilisateur -> on pourrait rajouter une ligne "c-apropos" suivi des mots clefs, sur lesquels on ferait un "grep". BASE ---- * Ordre 2 en temps : est-il interessant de passer dans bilsc2 avec f(n+1/2) plutot que de passer deux fois avec f(n) et f(n+1) ? * Dans codits, on ne prend pas en compte les TS positifs pour ne pas affaiblir la diagonale. Mais on pourrait tout de meme les integrer dans la reconstruction du second membre (dedoublement de ROVSDT, un pour la diago, un pour le second membre) * Tester la normalisation dans resolp * Le decalage de la diagonale est-il necessaire ? * Rhie & Chow sur la pression : - identifier un cas ou R&C a une influence reelle - tester la methode de stabilisation par clusters (LETEM) * Tester Rhie & Chow sur convection (voir si traite par lot LES) * CL sur grad transpose est icoff, pourquoi pas icoef ? * On reserve de la luminance en charbon, meme si on ne fait pas de rayonnement (en lagr, on ne teste pas si on rayonne) (?? a verifier) * Dans bilsc2, on reconstruit en upwind : interet ? * Pour la diffusion, on reconstruit avec (gradI+gradJ)/2.(II'-JJ') au lieu de gardI.II'-gradJ.JJ' -> repute plus stable, mais est-ce le cas ? Erreur sans doute + gde (meme si l'ordre est identique) * Dans distyp, on initialise y+ par une valeur permettant d'obtenir une valeur maximale dans les zones n'ayant eventuellement pas bien converge. Au premier pas de temps, on met le max de u*/nu, ensuite on utilise la valeur de u*/nu du pas de temps precedent. Lors d'une suite de calcul, on utilise aussi le max de u*/nu car y+ n'est pas sauvegarde -> difference entre un calcul 10iter+10iter et un calcul 20iter ... cela ne vaut cependant pas la peine de stocker y+ (limitation de la taille du fichier suite). On peut eventuellement tjs initialiser par le max de u*/nu.-> evaluer la perte de temps CPU. * CL de paroi en temperature meme si le calcul est en enthalpie. Plus generalement, est-il necessaire de definir systematique une variable temperature dans un calcul en enthalpie (deja le cas pour certaines phys part). * Utilisation de gradrc/gradmc suivant les termes. * Plantage si VISLS0=0 car division par HINT dans clptur * Entrer lambda et rho cp separement ? Coherence avec l'interface ? * Voir si on peut modifier vissec pour entrer directement W7, W8, W9 et eviter une double recopie. * Dans le test de pente, le terme DPDXA est reconstruit avec un gradient, donc il fait intervenir des points plus lointains que C, U et D. On peut donc imaginer une variation de la fonction entre U, C et D qui implique un passage en upwind mais que le test soit compense par les valeurs en UU et DD et que du coup le passage en upwind ne se fasse pas. -> A tester * Interpolation de la viscosite aux faces : en cas de discontinuite forte, l'interpol Stage lagrangien augmente arith est fausse mais l'interpol harmoniq est exacte. Dans le cas des PDC, on a dans resolp une interpol de ce style avec forte discontinuite. -> a tester ? * Reperage des capteurs d'historiques qui sont hors domaine. On pourra se baser sur les developpements de FVM et d'interpolation de maillage. On pourra ainsi definir une part Ensight nodale et la visualiser. On peut reflechir a cette methode pour extraire des points autrement que par FINDPT (qui est lourd en temps calcul si le nb de pts devient grand ... mais seulement dans ce cas !!). * IRCFLU : separer la convection de la diffusion. * Estimateurs d'erreur : - refaire une analyse du temps CPU - verifier la doc - si necessaire ne les calculer que si necessaire (impression listing, sortie post, fin de calcul) - estimateurs plus simples ? Utilisation des calculs deja faits dans le pas de temps pour donner une valeur plus proche ? - coherence avec iphydr, ordre en temps, ... * Prevoir un arret base sur le temps physique, pas juste sur NTCABS (def d'un TTMABS ; en debut de pdt on regarde si TTCBAS>TTMABS et si oui on fixe NTMABS=NTCABS, le reste est alors inchange. Si TTMABS<0 on ne teste pas) -> attention a certaines periodicite comme la periodicite de sortie des fichiers suite. * Et si on decoupait et reorganisait blisc2.F ? * Pb de IPUCOU et Rij avec la periodicite de rotation a cause de la viscos orthotrope (a priori OK donc en SSG qui a une viscos scalaire) * On pourrait peut etre economiser une vingtaine de percom/parcom en modifiant un peu visdyn (moins elegant, a ne faire que si il y a un gain effectif) * Dans vissec, le calcul du terme en div(u) a partir du flux de masse (en n+theta) et de rho extrapole risque de n'etre pas coherent et fournit en outre une valeur qui n'est pas en n (comme le demanderait l'extrapolation des termes sources places dans propce) * Tester le calcul d'un Hessien par approximation diffuse. Utilite pour un schema QUICK, un schema de diffusion d'ordre 2 meme si on n'est pas en 1/2-1/2, ... * Tester le couplage vitesse/pression par lagrangien augmente. * TS de masse et variance * Interet et maturite du modele "strain stress lag" * Algo stat -> suivi Manchester sur interet et comparaison avec autres codes * Dans le cas d'un voisinage etendu traite separement (en parallele), les communications necessitent un PARCVE en plus des PARCOM et PERCOM. Ces appels sont integres dans les routines CFLITR, CGRDMC et CLMGRD. Or pour le cas du filtre LES, la communication du volume des cellules pourrait n'etre faite qu'une fois dans CLVOLC, a condition que le voisinage etendu y soit bien defini. COGZ ---- * Analyser la pertinence et la complexite des suites en combustion d'un calcul sans combustion. LAGR ---- * Definir un cas test analytique : chute de particules dans un ecoulement ascendant uniforme, sur maillage regulier et/ou fortement deforme -> on doit pouvoir calculer la vitesse limite theorique. * Sous-programme de gestion des forces exterieurs (type gravite) et bien sur adapter lagcou et TSFEXT en consequence * Le traitement de la vitesse du fluide vu lors d'un rebond est une inversion de la composante normale et une conservation de la compos tangentielle -> cela correspond a une CL de flux nul et ne respecte pas le cisaillement -> on peut peut-etre mieux faire en faisant intervenir la CL de vitesse a la paroi (un truc genre VIT = CL + AA*(VIT_ini - CL) ) * Post-processing des trajectoires via FVM ? * Amelioration du suivi des particules (cellules concaves, pertes de particules) * Prise en compte des polygones quelconques dans lagnew * Prise en compte de la granulo avec un profil log-normal * Prise en compte des collisions RAYT ---- * Analyser la pertinence et la complexite des suites en rayonnement d'un calcul sans rayonnement (notamment faire intervenir ISUIRD dans le test autour de raypar dans raycli). ======================================================================= ======================================================================= REMARQUES POUR MEMOIRE ======================================================================= ======================================================================= * csprnt.F : le format "$" n'est pas reconnu sur un compilateur sous ... Windows !!!!!!! * Attention au recalage pression au deuxieme pas de temps. * Attention grdcel n'echange pas la variable ; peut etre problematique pour les utilisateurs ; evite de dupliquer les echanges pour les variables de calcul (on ne stocke pas les gradients) * Augmenter le nbre d'arg dans usthht (si utile) * Dans les TS de masse, les tableaux SMACEL sont dimensionnes a NCETSM*NVAR. Or NVAR concerne toutes les variables de toutes les phases ... surdimensionne. Mais a priori insoluble autrement ! * On utilise pour le moment une approche "explicite" pour la periodicite de rotation de QDMX, QDMY, QDMZ --> Il serait cependant interessant de tester l'approche avec des neumann quand il y a une periodicite de rotation sur un vecteur ou un tenseur (ca reviendrait a une sorte de symetrie) * Ce qui sort d'invers n'a pas ete tourne (a priori ok mais a savoir) * Pour le clipping variance d'une variable seulement utile en combustion gaz il faudrait que l'on soit sur que la variable soit resolue avant sa variance (detail : sinon, y a la variable au t prec et c'est faux) * Pas de prise en compte du schema d'ordre 2 en temps pour les physiques particulieres actuelles : - pas de besoin avant plusieurs annees apres interview - en particulier pas de LES en combustion avec saturne - noter egalement que la masse volumique est determinee de maniere complexe et que le traitment simple qu'on lui applique entrainera sans doute des difficultes On garde les sources sous le coude pour eviter de rendre ces sous-programmes plus complexes qu'ils ne le sont deja * Attention au thetav dans le bilsc2 pour les estim ======================================================================= ======================================================================= BONNES PRATIQUES (POUR MEMOIRE) ======================================================================= ======================================================================= * Une routine par fichier (sauf eventuellement si elles sont toutes "privees", sauf la premiere), 6 lettre par nom de routine exactement 6 lettres au plus et 2 lettres au moins par nom de variable (bannir les variables I, N, J ou K ) * Ne pas mettre de tabs dans les fortrans. * Eviter les lignes de fortran commentees dans les us* : sinon jamais compile donc forcement faux * Continuation character : & et pas de + (on utilise un caractere qui ne veut rien dire en fortran afin de ne pas le confondre) * Donner aux entiers des noms commencant par I, J, K, L, M, N * Eviter les goto a la mode case Mettre des do enddo et pas de do continue Virer les do while si possible (mettre un goto si necessaire) * Eviter l'acces a des pointeurs de pointeurs de pointeur dans les boucles mettre un entier avant, c'est plus lisible et ca va plus vite. * Encadrer les write et print sauvages par ifdef debug (ex de cpcym1 : le test doit il etre conserve ?) Attention : verifier que ce qui est dans les tests ne sert pas ailleurs * Mettre des reels en D et pas en E Pas de E50 (ca n'existe pas sur IRIX : out of range) * Eviter a = 3.d0*b preferer si possible double precision trois trois = 3.d0 a = trois * b