Rien
Rien
- ALE 3D : création du maillage auxiliaire en 3D, de la géométrie
du maillage auxiliaire et application des conditions aux limites. Pas de cas-tests
pour l'instant vu que les Facet
et Edge vont disparaitre bientôt.
- VizWin : Capture d'écran dans 12
formats différents dont VRML et PS vectoriel (routine VizWin::save()
).
- Topologie : Ajout d'un premier embryon pour la géométrie
du maillage et de la classe Topology
qui remplacera à terme les Facet
et Edge.
- Optimisation de la mémoire :
- Modification de Physet
(suppression des données superflues et de la dérivation de
ReadWrite). L'allocation
des "properties"
est maintenant faite uniquement lorsque c'est nécessaire (la TStack<T>
est un pointeur NULL par
defaut). Ceci permet de ne plus trop se tracasser de ce qui doit être
Physet ou pas.
- Face et Volume
: allocation des MIT_Topology
uniquement si nécessaire
- Curve etr Surface
: allocation des bounding box (BoxValue)
et dernières valeurs projetées (ProjectionValue)
uniquement si nécessaire
- Nettoyage de "try2assign_all_ptr()"
dans tous les objets géométriques.
- Suppression automatique du tableau de numéros de composants dans
GeoObject<T> (no_comp)
- Contour : utilisation de
OrdonateContour uniquement
si nécessaire.
- Physet : ajout d'une fonction
meminfo() qui permet de retourner la taille réelle de l'objet (lui-même
+ ce qui a été alloué). Cependant, il faut encore l'introduire
dans les autres classes.
- Introduction d'exceptions dans GObject.
- Nettoyage des classes de Géométrie (notamment BoxValue
et ProjectionValue).
Gains mémoire
L'opération de réduction de la mémoire consommée
est nécessaire vu que les entités géométriques vont
être utilisées pour décrire la géométrie du
maillage. Avant ce commit, un volume coûtait 2664 octets (!), une bête
ligne droite coûtait 212 octets et un simple point, 176 octets. Quand
on sait que la création de la topologie va nécessiter la création
d'un point par noeuds + 12 lignes, 6 contours, 6 surfaces, 6 faces, 1 skin et
1 volume par élément 3D hexa, ça fait peur. A ce rythme
là, il faudra bientôt avoir 2 Go de RAM pour faire passer la barre
de Taylor...
Le tableau excel suivant résume les gains obtenus sur les éléments
"vides" (c'est-à-dire des simples "sizeof()" ) -
voir sizeof.xls. J'ai aussi sorti, pour info,
le contenu du "Brain" d'oofelie : voir
brain.xls.
En pratique, la grande majorité des cas-tests tournent plus vite (gain
de 10% pour l'amortisseur 3D !). Pour moi, c'est dû aux opérations
inutiles dans les constructeurs (copie de l'heure de création, du flag
RW, des 8 properties vides par défaut, ...).
Pour la batterie oofelie, on gagne environ 2Mo sur le moteur piezo (mptp.e)
sur un total de 102 Mo et 8 Ko sur asef(treillis)
! Pas grand chose donc mais c'est normal vu que ce sont des petits cas-tests
et qu'ils n'utilisent pas la géométrie.
Les gros gains se feront pour l'ALE et le contact défo-défo.
Compilation
- Attention, j'ai dû recompiler VTK pour utiliser gl2ps
(export postscript vectoriel). Les nouvelles libs sont disponibles sur mon
site ftp.
- J'ai fait de la lib gl2ps une dll qui est aussi disponible sur mon site.
En debug, j'utilise une lib statique.
- Au niveau de la compilation, il faut maintenant utiliser "Multithread
DLL" pour compiler oofelie. J'ai dû recompiler nurbslib en "multithread
DLL" pour que tout fonctionne bien.
- Si vous utilisez mon projet, vous avez aussi besoin des librairies static-debug
VTK qui permettent de debugger VTK (assez utile quand la visualisation plante)
