|
|||||
|
|
17 Juillet 2005 | By LPX | |||
- Suite au dernier commit de Romain, (typage des drawable), la fonction vizu est cassée (=> l'elementSet est caste en physet dans Python et non pas en drawable => core Dump). Apres divers tentatives de resoudre le problème, j'ai mis en place un "by-Pass" en utilisant momentanement la fonction "windowsInitialisation" pour ajouter les drawables au domaine :
vizu : ai remplacé
win.add(domain.getElementSet())
win.add(domain.getGeometry().getPointSet())
win.add(domain.getGeometry().getCurveSet())
win.add(domain.getGeometry().getSideSet())
win.add(domain.getGeometry().getWireSet())
par :
domain.getMetafor().windowsInitialisation(win)
- aussi ajouté "ELEMENTSET_ID" à la fonction "PhySet_dynamic" de Metafor.i (mais ca n'a pas regle le problème).
Pour le reste Romain, si tu as une idée ...
Suite à un test simplifie pour le TFE cerveau, j'ai remarque que les ddls TZ n'étaient jamais pris en compte.
En effet le buildDofMap valait :
template<>
void
MY_CLASS::buildDofMap ()
{
dofMap = new Lock[3];
dofMap[0] = TX|RE;
dofMap[1] = TY|RE;
dofMap[2] = TO|RE;
}
au lieu de :
template<>
void
MY_CLASS::buildDofMap ()
{
dofMap = new Lock[4];
dofMap[0] = TX|RE;
dofMap[1] = TY|RE;
dofMap[2] = TZ|RE;
dofMap[3] = TO|RE;
}
- Splits des classes en divers fichiers :
oo_meta/toolbox/ExperimentsClasses.py
oo_meta/toolbox/LineSearchClasses.py
oo_meta/toolbox/OptimisationMethodsClasses.py
oo_meta/toolbox/ParametersClasses.py
oo_meta/toolbox/ResultsFobjClasses.py
- Suppression de la normalisation de la matrice Hessienne (JtJ) de la méthode de Newton-Gauss.
Utilisation unique de la Pseudo-Inverse (avec nombre de conditionnement reglable) afin de stabiliser les variables à sensibilité trop faible.
- Adimensionalisation des variables d'optimisation (avec estimation d'un facteur d'échelle si necessaire)
- Ajout des méthodes de la Plus grande pente & du gradient conjugué ainsi que des méthodes de LineSearch (bissection - RegulaFalsi - Interpolation cubique).
- Mise en place de méthode de gestion des frontières (la méthode de pénalisation utilisée dans LM ne me semblant pas idéale)
- Ajout de l'export UI pour d'autres fonctions objectives (afin de pouvoir utiliser NG et LM)
- Sérialisation des méthodes d'opti : LM->GC
- Ajout de méthodes d'opti + évoluées
- Ajout de méthodes multi expériences - multi résultats
- Tests en tous sens
- quid de l'utilisation de la visu Metafor - gnuplot ???
- quid de laisser l'opti sous Python ou de faire des classes compilées ?
- ...
oo_meta/toolbox/parametricStudy.py
oo_meta\apps\parametric\tracIdentIHLin_NGNorm.py
oo_meta\apps\parametric\triangleForOpti_NGNorm.py
oo_meta/toolbox/ExperimentsClasses.py
oo_meta/toolbox/LineSearchClasses.py
oo_meta/toolbox/OptimisationMethodsClasses.py
oo_meta/toolbox/ParametersClasses.py
oo_meta/toolbox/ResultsFobjClasses.py
oo_meta\mtExtractors\AreaDataCurveObjectiveFunction.h/cpp
oo_meta\apps\parametric\tracEvpIso3dParam2_LM.py
oo_meta\apps\parametric\tracEvpIso3dParam2_NG.py
oo_meta\apps\parametric\tracEvpIso3dParam3_LM.py
oo_meta\apps\parametric\tracIdentIHLin_PGP1.py
oo_meta\apps\parametric\tracIRSIDBox_CG.py
oo_meta\apps\parametric\tracIRSIDBox_PGP.py
oo_meta\apps\parametric\triangleForOpti2_CG.py
oo_meta\apps\parametric\triangleForOpti2_LM.py
oo_meta\apps\parametric\triangleForOpti2_NG.py
oo_meta\apps\parametric\triangleForOpti2_NG_RCond12.py
oo_meta\apps\parametric\triangleForOpti2_NG_RCond3.py
oo_meta\apps\parametric\triangleForOpti2_NG_RCond4.py
oo_meta\apps\parametric\triangleForOpti2_NG_RCond6.py
oo_meta\apps\parametric\triangleForOpti2_PGP.py
oo_meta\apps\zQs\tetraTetra.dat/zdat
oo_meta\apps\experimentalCurves\apps.monosMaterials.tracIRSIDBox
oo_meta\apps\experimentalCurves\apps.monosMaterials.tracIRSIDBox/abaqus_epl.ascii
oo_meta\apps\experimentalCurves\apps.monosMaterials.tracIRSIDBox/abaqus_sigel.ascii
oo_meta\apps\monosMaterials\tracIrsidBox.py
ATTENTION NOUVEAUX REPERTOIRES => cvs update -d !!!
 |
|
|||
| created :29 Juin 2005 | modified : 30 Juin2005 | |||
| contact :L.Papeleux@ulg.ac.be | ||||