$Id: TODO,v 1.66 2004/10/26 00:43:21 geuzaine Exp $

add an interactive way to choose the orientation of surfaces in
surface loops and lines in line loops

(To make things simple, all line loops should be oriented "aire a
gauche", and all surface loops whould be oriented with exterior
normals...)

********************************************************************

template the view handling/drawing routines so that we can actually
use post-pro files with float values (50% file savings can be nice
for very large maps; would bring the format up to par with an 
index-based format)

********************************************************************

Raise & offsets should modify the bounding boxes... (maybe?)

********************************************************************

Test and reintroduce the cylindrical surfaces (cylinder, cone, torus)

********************************************************************

fix the orientation of hexas, prisms and pyramids (reorder nodes
according to Orientation())

********************************************************************

add parameter to transformation operations to copy the meshes

********************************************************************

add transformations on volumes

********************************************************************

add/restore Parametric curve type (use MathEval!)

********************************************************************

add ternary operator and <,>,<=,>=,== tests in MathEval

********************************************************************

on Macs, datasets with a bounding box < 1.e-06 don't display properly
(probably because all the OpenGL stuff is done ineternally in single
precision...). Rescale?

********************************************************************

add the capability to mesh some entities using 1st order and some
other using 2nd order elements (in the same geometry)?
<gerard.fleury@inrs.fr>

********************************************************************

find a better way to display the time/timestep in the scale...

********************************************************************

make Recombine work the same as "Second order"? (i.e., allow for
interactive use?)

********************************************************************

The "Symmetry" operation should be renamed "Reflection" (?)

********************************************************************

Attractors in the 2D aniso algo are extremely buggy

********************************************************************

Memory leaks, memory leaks

- start with mesh_domain() and the parser (update: parser should be
  mostly OK now)

- check all calls to Tree_Replace: we shouldn't use it with trees of
  pointers, since we loose the original pointer when we actually do a
  'replace'

- check all calls to Tree_Insert, and test the return value (if we
  don't do the insert, free the data!)

********************************************************************

Rewrite the geometry module in C++: we should have

Point.cpp
Curve.cpp
Surface.cpp
Volume.cpp

It's much shorter than one may think. We could just keep a C interface
like in Vertex.cpp and Simplex.cpp.

********************************************************************

Rewrite the View interface in C++

********************************************************************

Include Tetgen (the same way we did it with Triangle--the license is
the same).

********************************************************************

Include the 2D Netgen algorithms and improve the integration of the 3D
algorithm (would be nice to have automatic exterior orientation of
surfaces...)

********************************************************************

All surface meshes are made in a mean plane. If your surface cannot be
projected into a plane with a 1-to-1 correspondance between the nodes,
then gmsh will fail. 

We should definitely use a better projection algorithm
(e.g. intrinstic parameterization). See the work by Desbrun et al. in
CS for this.

********************************************************************

post-processing file format:
- add an integer per simplex (region num)?
- add a format similar to the msh format (node list + simplex list)?
- add a structured format?

...or implement one of the "industry-standard" formats?

********************************************************************

Yves Krahenbuhl wrote:

> Lors de la creation des elements du 2eme ordre, et selon la courbure
> du contour exterieur, le jacobien de l'element peut devenir negatif.
> Cependant le programme genere le maillage sans protester. Il
> faudrait peut-etre faire apparaitre un message d'erreurs / ou se
> restreindre (automatiquement ou non) a une interpolation lineaire
> entre les points en question.

********************************************************************

Pb avec View->Reload si plusieurs vues dans le meme fichier

> > Hmm, je viens de tester sous Linux et je n'arrive pas a reproduire le
> > bug. A moins que... Aurais-tu toutes tes vues stockees dans le meme
> > fichier ? Car 'reload' relit simplement le fichier duquel provient la
> > vue (et il le relit entierement).
> 
> Tout  fait, toutes les vues sont dans un fichier unique.

C'est de la que vient le probleme. Le 'reload' recharge en fait le
fichier duquel provient la vue, en *forcant* sa position dans la liste
des vues chargees. Si le fichier contient plusieurs vues, il va
recharger la premiere, lui affecter la position de celle que tu veux
recharger, puis la deuxieme, en lui affectant le meme position, et
ainsi de suite. Ca fait donc un supeeer memory leak : tu recharges
bien toutes les vues, mais tu ne sais acceder qu'a la derniere... Pour
corriger ca, il faudrait que l'on garde comme info supplementaire dans
chaque vue quelle etait sa position dans le fichier.

********************************************************************

Tenseurs, Laurent Stainier <l.stainier@ulg.ac.be>

L'approche que je suggrerais est la suivante. Tout d'abord, on peut 
commencer par le cas particulier (mais sans doute le plus courant) des 
tenseurs symtriques ( valeurs relles pour tre prcis). Dans ce cas, 
les trois valeurs propres, et les vecteurs propres associs, sont bien 
dfinies et relles. On peut galement dfinir les trois invariants du 
tenseur A: I1=tr(A), I2=0.5*[tr(A)^2-tr(A^2)], I3=det(A), ou 
alternativement tr(A), tr(A^2), tr(A^3). On peut alors envisager 
diffrentes reprsentations graphiques:
- la croix de contrainte (gnralise  3D), compose  partir des 
valeurs propres et des vecteurs propres;
- les invariants (sous formes de plusieurs champs scalaires). Le choix 
des invariants n'est pas vident: en mcanique, les plus intressants 
sont certainement I1, J2, I3. Quid en EM ?
- composante par composante, ce qui serait d'ailleurs bien utile pour 
les vecteurs galement (mais peut-tre cela peut-il tre fait par 
plugin, dont je n'ai pas encore tudi le mcanisme ??).

L o a se complique franchement, c'est pour les tenseurs non 
symtriques. Quoique ! Dans ce cas l, plus aucune garantie sur les 
valeurs propres ... Mais il me semble donc que la solution peut tre de 
se ramener au cas prcdent via une dcomposition polaire A=R.U ou 
A=V.R, o U et V sont des tenseurs symtriques et R un tenseur 
anti-symtrique norm (R^t.R=1 => R^-1=R^t ; U^2=A^t.A, V^2=A.A^t), R 
reprsentant une rotation rigide en mcanique. Ce dernier a trois 
valeurs propres: 1 (avec un vecteur propre correspondant  l'axe de 
rotation) et exp(+-i \theta) o \theta est l'angle de rotation ( 
vrifier !!). Pour la reprsentation graphique, il y a l'option de 
laisser tomber R. Sinon, il faudrait de fait voir comment reprsenter U 
(ou V) avec R.

Remarque finale: le calcul des valeurs et vecteurs propres est 
videmment un peu lourd au niveau CPU, mais bon, les tenseurs peuvent 
tre stocks sous cette forme (les invariants sont facilement calculs 
 partir des v.p.), et cela nous rappelle cette belle expression "No 
free meal" !
