Skip to content
Snippets Groups Projects
Forked from gmsh / gmsh
19031 commits behind the upstream repository.
  • Christophe Geuzaine's avatar
    7379efb3
    · 7379efb3
    Christophe Geuzaine authored
    - All extrusion commands now return a list of 2 numbers (instead of 1):
      the first, as before, is the number of the "top" of the extruded region
      (i.e., a point for extrude point, a line for extrude line, ...), the
      second is the number of the "body" of the extruded region (i.e., a
      line for extrude point, a surface for extrude line, ...).
    
    - "Extrude Surface" now always creates a new volume (automatically),
      EVEN WHEN THERE IS NO LAYERS SPECIFICATION. This makes it consistent
      with "Extrude Point" and "Extrude Line", which always create new
      curves and surfaces, respectively.
    
      Important Note: you will have to modify your old .geo files to avoid
      duplicate volume definitions if you use "Extrude Surface" without
      extruding the mesh (i.e., without the "Layers" command). These
      duplicate volumes would be harmless, but they would srew up your
      physical volume definitions later on...
    
      * Solution 1: use the new volumes (recommended). To do this, just
      remove your old extra volume definitions and let Gmsh create the
      extruded volumes for you. (To retrieve the volume number created by
      Gmsh, use "aa[] = Extrude Surface {...};;": the volume number is
      "aa[1]".)
    
      * Solution 2: keep the old volumes.
    
      a) clean way: retrieve the new volume number (aa[] = Extrude Surface
      {...};;) and delete the new volume with "Delete { Volume aa[1]; }"
    
      b) dirty (but handy) way: since, in order to create the new volumes
      with the less impact possible, Gmsh uses "low" numbers (actually,
      forcing "Geometry.OldNewreg=0") for the new volumes, just remove all
      "low number volumes". For example, if you have 4 "Extrude Surface" in
      your file, you can then just do "Delete{ Volume {1:4}; }"
    
    Voila :-)
    7379efb3
    History
    Christophe Geuzaine authored
    - All extrusion commands now return a list of 2 numbers (instead of 1):
      the first, as before, is the number of the "top" of the extruded region
      (i.e., a point for extrude point, a line for extrude line, ...), the
      second is the number of the "body" of the extruded region (i.e., a
      line for extrude point, a surface for extrude line, ...).
    
    - "Extrude Surface" now always creates a new volume (automatically),
      EVEN WHEN THERE IS NO LAYERS SPECIFICATION. This makes it consistent
      with "Extrude Point" and "Extrude Line", which always create new
      curves and surfaces, respectively.
    
      Important Note: you will have to modify your old .geo files to avoid
      duplicate volume definitions if you use "Extrude Surface" without
      extruding the mesh (i.e., without the "Layers" command). These
      duplicate volumes would be harmless, but they would srew up your
      physical volume definitions later on...
    
      * Solution 1: use the new volumes (recommended). To do this, just
      remove your old extra volume definitions and let Gmsh create the
      extruded volumes for you. (To retrieve the volume number created by
      Gmsh, use "aa[] = Extrude Surface {...};;": the volume number is
      "aa[1]".)
    
      * Solution 2: keep the old volumes.
    
      a) clean way: retrieve the new volume number (aa[] = Extrude Surface
      {...};;) and delete the new volume with "Delete { Volume aa[1]; }"
    
      b) dirty (but handy) way: since, in order to create the new volumes
      with the less impact possible, Gmsh uses "low" numbers (actually,
      forcing "Geometry.OldNewreg=0") for the new volumes, just remove all
      "low number volumes". For example, if you have 4 "Extrude Surface" in
      your file, you can then just do "Delete{ Volume {1:4}; }"
    
    Voila :-)
TODO 8.16 KiB
$Id: TODO,v 1.55 2004-07-02 02:40:43 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...)

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

We could modify "Extrude Surface" to *always* create a new
volume. This would make it consistent with "Extrude Point" and
"Extrude Line", which always create new curves and surfaces,
respectively. (with multi-layered exruded meshes, we could do exactly
s we do with Extrude Line: if number==0, use the volume number...)

I'm not sure if we should do it or not... This would introduce
some incompatibilities in old geo files:

- users could do a "Delete Volume" after the extrusion to fix the
  old files (aa[] = Extrude Surface{..};; Delete{Volume aa[1];}

- ...if the new volume creation didn't bork the automatic 
  numbering. For this, we could use the following hack:

  // FIXME: this is a really ugly hack for backward compatibility, so
  // that we don't screw up the old .geo files too much. (Before
  // version 1.54, we didn't always create new volumes during "Extrude
  // Surface". Now we do, but with "CTX.geom.old_newreg==1", this
  // bumps the NEWREG() counter, and thus changes the whole automatic
  // numbering sequence.) So we locally force old_newreg to 0: in most
  // cases, since we define points, curves, etc., before defining
  // volumes, the NEWVOLUME() call below will return a fairly low
  // number, that will not interfere with the other numbers...
  int tmp = CTX.geom.old_newreg;
  CTX.geom.old_newreg = 0;
  Volume *v = Create_Volume(NEWVOLUME(), 0);
  CTX.geom.old_newreg = tmp;


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

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

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

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

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

add some code to make the node/element list ordered+dense (with no
gaps)? this seems to be one common problem users have with our mesh
format...

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

add an option to plot the bounding box of views, with or without
labels (scales)

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

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

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

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.

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

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++

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

Improve Triangle integration: bgmesh on file, 2nd intermediate mesh?,
etc.

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

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

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

Include the 2D and 3D frontal algos from Netgen (it's LGPL now...)

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

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. See the work
by Desbrun et al. in CS for this.

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

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 suggérerais est la suivante. Tout d'abord, on peut 
commencer par le cas particulier (mais sans doute le plus courant) des 
tenseurs symétriques (à valeurs réelles pour être précis). Dans ce cas, 
les trois valeurs propres, et les vecteurs propres associés, sont bien 
définies et réelles. On peut également définir 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 
différentes représentations graphiques:
- la croix de contrainte (généralisée à 3D), composée à 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 mécanique, les plus intéressants 
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 mécanisme ??).

Là où ça se complique franchement, c'est pour les tenseurs non 
symétriques. 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 précédent via une décomposition polaire A=R.U ou 
A=V.R, où U et V sont des tenseurs symétriques et R un tenseur 
anti-symétrique normé (R^t.R=1 => R^-1=R^t ; U^2=A^t.A, V^2=A.A^t), R 
représentant une rotation rigide en mécanique. 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 (à 
vérifier !!). Pour la représentation graphique, il y a l'option de 
laisser tomber R. Sinon, il faudrait de fait voir comment représenter 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 stockés sous cette forme (les invariants sont facilement calculés 
à partir des v.p.), et cela nous rappelle cette belle expression "No 
free meal" !