=======================================================================
=======================================================================
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 peut etre tres long

* Reorganiser la base des cas tests

* Script blue gene integre

* Adapter les scripts d'autovalidation pour prendre en compte les fichier
  de sortie binaire EnSight (changement ASCII => binaire du mode verif)

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
----
* Adapter la gestion des familles de faces internes si celles-ci n'existaient pas
  (notamment en cas de renumerotation ou de decoupages des faces gauches)

* Modifier les commentaires des routines utilisant le selector, rajouter
  MAXELT et LSTELT aux autres routines usts* et traiter proprement usdpst.F

* 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)

* Dans jacobi et gradco (et bicgstab ?) on compare le residu en racine
  carree, alors que ce n'est pas ncessaire. 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

* Dans ECRHIS, les fichiers .hst sont reecrits entierement au moment du dump
  du fichier hst.tmp. Il suffirait de ne rajouter que ce qui est nouveau ...

* Unifier les boucles de sous-iterations ALE et U/P. La boucle U/P doit etre remontee
  pour pouvoir impliciter les CL (notamment pour MIGAL). Attention a ce qui est remis
  aux anciennes valeurs en fin de boucle. Pour l'instant, dans le cas U/P on met la
  nouvelle pression dans RTPA, alors que dans le cas ALE on remet au contraire tous les
  RTPA dans RTP et on reprend l'ancien flux de masse.

* Changer distyp et distpr pour utiliser l'algorithme stationnaire ?

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 paralllisme ....

ALE
---
* Branchement de couplage avec Aster. Changement du numero de maillage fvm (10 par defaut)
  pour l'envoi vers Calcium

* 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 ?)

* Dans le cas de sous-iterations ALE implicite, on doit aussi stocker les CL
  de P et U car dans condli on fait des appels a GRDCEL pour calculer les CL
  reelles. Sinon, on ne revient pas exactement a l'etat precedent ... mais
  est-ce grave (seule la reconstruction est modifiee) ?
  De meme, au premier pas de temps d'une suite de calcul, a cause de l'iteration
  d'initialisation ALE, les CL utilisees pour le GRDCEL avec ou sans ALE ne sont
  pas les memes ... mais la encore, est-ce grave ?

* Evaluer la necessite de combiner les boucles P/U avec implicitation des CL et les
  boucles ALE .... -> faut-il reellement revenir a l'etat initial dans les boucles ALE ?


INTEGRATION DVLPTS EXTERNES
---------------------------
* Integration aros

* 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)

* 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
  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 bilsc2.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" 

* 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.

* Supprimer les dpendances croises entre cs_mesh.*, cs_mesh_connect.*, cs_halo.*,
  et cs_ext_neighborhood.*, ou au moins faire apparaitre la hierarchie des structures
  (peut necessiter la creation d'un fichier cs_mesh_priv.h, et le maintien d'un lien
  entre les structures de maillage publiques et privees, ou le passage de certains
  membres des structures par argument ou sous-structures de travail pour eviter qu'un
  niveau ait besoin de connaitre les structures du niveau superieur).

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 ou C (penser au script rmb.sh). 

* 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  
