metil-lmtpp Mailing List for metil
Status: Pre-Alpha
Brought to you by:
hugo_lec
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(3) |
Feb
(8) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
|
Oct
(3) |
Nov
(6) |
Dec
(10) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(14) |
Oct
|
Nov
(1) |
Dec
|
From: <gou...@lm...> - 2010-11-18 10:18:07
|
Bonjour à tous, Je viens d'effectuer un changement sur LMTpp qui peut être genant pour certains. En effet, les class générées à partir des formulations reprennent leur ancien nom d'il y a plusieurs années. Pour les utilisateurs qui n'utilisent pas l'argument 'types' de la fonction 'make_pb' (la plupart des gens), il suffit de remplacer les nom de class Problem_FORM_type0_D par l'ancien nom Problem_FORM_double_D, où FORM est le nom d'une formulation et D est la dimension. Pour les autres personnes et ceux qui veulent connaitre la raison du changement, vous trouverez plus d'explications plus loin. Je vous présente mes excuses pour la gêne occasionnée, Camille PS : Pour plus d'explications Avant ce dernier changement, LMTpp générait des class qui avaient un nom du type Problem_FORM_typeN_D avec : FORM, le nom de la formulation N, le numero du n-ième type de scalaire utilisé (généralement ca se limite à N=0) D, la dimension Quand on regénérait des problèmes avec plusieurs types de scalaires en changeant leur ordre, il y avait alors des problèmes à la compilation. Pour éviter ce problème, on est revenu à des class avec un nom du type Problem_FORM_SCA_D avec : FORM, le nom de la formulation SCA, le nom du scalaire utilisé D, la dimension Pour les scalaires qui ont des caractères spéciaux dans leur nom (par exemple 'LMT::Pol<2,3,double>'), ces caractères sont remplacés de la manière suivante dans SCA : '<' devient '_LessThan_' '>' devient '_GreaterThan_' ',' devient '_Comma_' ':' devient '_Colon_' |
From: <gou...@lm...> - 2010-09-17 10:34:36
|
Merci Hugo pour ta réponse ! Quoting Hugo LECLERC <le...@lm...>: >> >> Je souhaite tester si les coefficients de deux Vec sont tous égaux à >> un epsilon près. J'aimerai donc savoir s'il existe dans LMT++ une >> fonction du style : >> > Hello, > > Tu peux par exemple utiliser "norm_inf( a - b ) <= epsilon" > > C'est équivalent à "all( abs( a - b ) <= epsilon )" ou "max( abs( a - b ) ) > <= epsilon"... par exemple > > Pour les opérateurs, tu as DistBetweenVecInfEq comme exemple mais c'est fait > pour norm_2. > > À+ > > -- > Hugo LECLERC (IR CNRS) > Tel : +33 (0)1 47 40 23 40 / +33 (0)6 63 30 34 21 > LMT-Cachan > (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > 61, av. du Président Wilson > F-94230 Cachan > France > |
From: Hugo L. <le...@lm...> - 2010-09-17 09:39:45
|
> > Je souhaite tester si les coefficients de deux Vec sont tous égaux à > un epsilon près. J'aimerai donc savoir s'il existe dans LMT++ une > fonction du style : > Hello, Tu peux par exemple utiliser "norm_inf( a - b ) <= epsilon" C'est équivalent à "all( abs( a - b ) <= epsilon )" ou "max( abs( a - b ) ) <= epsilon"... par exemple Pour les opérateurs, tu as DistBetweenVecInfEq comme exemple mais c'est fait pour norm_2. À+ -- Hugo LECLERC (IR CNRS) Tel : +33 (0)1 47 40 23 40 / +33 (0)6 63 30 34 21 LMT-Cachan (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) 61, av. du Président Wilson F-94230 Cachan France |
From: <gou...@lm...> - 2010-09-17 07:48:58
|
Salut à tous, Je souhaite tester si les coefficients de deux Vec sont tous égaux à un epsilon près. J'aimerai donc savoir s'il existe dans LMT++ une fonction du style : template <class T1, int s, class IVO1, class T2, class IVO2, class T3> bool test_equality(const Vec<T1,s,IVO1> &v1, const Vec<T2,s,IVO2> &v2, const T3 &tolerance) { if ( v1.size()!=v2.size() ) return false; for (int i=0;i<v1.size();i++) if ( abs_indication(v1[i]-v2[i]) > epsilon ) return false; return true; } ou une classe abstraite avec un operator() qui prendrait trois arguments en entrée. Certes je pourrai utiliser le booléen suivant : norm_inf( v1 - v2 ) < epsilon mais cela implique de faire beaucoup de calculs inutiles, surtout quand on sait que le test sera négatif dans l'énorme majorité des cas. Merci pour vos réponses, Camille |
From: <gou...@lm...> - 2010-09-06 15:10:40
|
Salut à tous, Merci Felipe d'avoir proposé cette solution. Elle me convient parfaitement. A plus, Camille Hugo LECLERC <le...@lm...> a écrit : > Hello, > > Ok pour le patch de Felipe, c'est effectivement une solution s'il y a des > gens qui en ont besoin et qui ne se sont pas signalé et qu'on n'a pas leurs > codes dans nos tests. > > Merci. > > À+ > > -- > Hugo LECLERC (IR CNRS) > Tel : +33 (0)1 47 40 23 40 / +33 (0)6 63 30 34 21 > LMT-Cachan > (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > 61, av. du Président Wilson > F-94230 Cachan > France > |
From: Hugo L. <le...@lm...> - 2010-09-06 13:58:20
|
Hello, Ok pour le patch de Felipe, c'est effectivement une solution s'il y a des gens qui en ont besoin et qui ne se sont pas signalé et qu'on n'a pas leurs codes dans nos tests. Merci. À+ -- Hugo LECLERC (IR CNRS) Tel : +33 (0)1 47 40 23 40 / +33 (0)6 63 30 34 21 LMT-Cachan (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) 61, av. du Président Wilson F-94230 Cachan France |
From: Federica D. <da...@lm...> - 2010-09-06 13:33:52
|
J'ai peut être loupé un truc, mais j'ai essayé (avant la patch ici- bas) de compiler toutes les formulations sauf inter_elasticity (qui donnait une erreur) en commentant F_POINTER et il n'a pas donné d'erreurs... Federica -- Federica Daghia, Ph.D Assistant Professor École Normale Supérieure de Cachan - ENS Cachan DGM - LMT Cachan 61, avenue du Président Wilson 94235 Cachan Cedex - FRANCE Tel.: +33 (0)1 47 40 53 01 Fax: +33 (0)1 47 40 27 85 On Sep 6, 2010, at 3:30 PM, Felipe Bordeu Weldt wrote: > hello, > > voici le patch pour réparer le problème de f_pointer. > > > fbordeu@pc-lmm29:~/Coffee/LMT$ git diff > include/formulation/formulationassembly.h > diff --git a/include/formulation/formulationassembly.h > b/include/formulation/formulationassembly.h > index c45c34b..b1b61a5 100644 > --- a/include/formulation/formulationassembly.h > +++ b/include/formulation/formulationassembly.h > @@ -2,7 +2,9 @@ > #define FORMULATION_ASSEMBLY_H > #include "containers/mat.h" > > +#ifdef need_f_pointer > extern LMT::Vec<double>* F_POINTER; > +#endif > > namespace LMT { > > @@ -38,7 +40,9 @@ namespace LMT { > mat_already_allocated = false; > connectivity_calculated =false; > tol = AbsT(0.000001); > + #ifdef need_f_pointer > F_POINTER = &f_nodal; > + #endif > } > // > ~FormulationAssembly() { > > il permet de compiler sans rien déclarer, pour tout le monde. > et pour le gens qu'ont besoin de f_pointer il faut ajouter > -Dneed_f_pointer dans vos flags de compilation (fichier SConstruct). > > ... > CPPFLAGS = cppf2 + ' -DMAIN -Dneed_f_pointer' +MpiCppFlag , > ... > > voilà problème résolu. > > bonne journée. > > Felipe, > > -- > > Felipe Bordeu Weldt > Ingénieur de Recherche > ------------------------------------- > Tél. : 33 (0)2 40 37 16 57 > Fax. : 33 (0)2 40 74 74 06 > Fel...@ec... > Intitut GeM - UMR CNRS 6183 > École Centrale de Nantes > 1 Rue de La Noë, 44321 Nantes, FRANCE > ------------------------------------- > > > > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp |
From: Felipe B. W. <bo...@lm...> - 2010-09-06 13:30:34
|
hello, voici le patch pour réparer le problème de f_pointer. fbordeu@pc-lmm29:~/Coffee/LMT$ git diff include/formulation/formulationassembly.h diff --git a/include/formulation/formulationassembly.h b/include/formulation/formulationassembly.h index c45c34b..b1b61a5 100644 --- a/include/formulation/formulationassembly.h +++ b/include/formulation/formulationassembly.h @@ -2,7 +2,9 @@ #define FORMULATION_ASSEMBLY_H #include "containers/mat.h" +#ifdef need_f_pointer extern LMT::Vec<double>* F_POINTER; +#endif namespace LMT { @@ -38,7 +40,9 @@ namespace LMT { mat_already_allocated = false; connectivity_calculated =false; tol = AbsT(0.000001); + #ifdef need_f_pointer F_POINTER = &f_nodal; + #endif } // ~FormulationAssembly() { il permet de compiler sans rien déclarer, pour tout le monde. et pour le gens qu'ont besoin de f_pointer il faut ajouter -Dneed_f_pointer dans vos flags de compilation (fichier SConstruct). ... CPPFLAGS = cppf2 + ' -DMAIN -Dneed_f_pointer' +MpiCppFlag , ... voilà problème résolu. bonne journée. Felipe, -- Felipe Bordeu Weldt Ingénieur de Recherche ------------------------------------- Tél. : 33 (0)2 40 37 16 57 Fax. : 33 (0)2 40 74 74 06 Fel...@ec... Intitut GeM - UMR CNRS 6183 École Centrale de Nantes 1 Rue de La Noë, 44321 Nantes, FRANCE ------------------------------------- |
From: Martin G. <ge...@lm...> - 2010-09-03 14:42:03
|
Le jeudi 2 septembre 2010 12:51:57, Federica Daghia a écrit: > Je creuse dans ça avant qu'on décide de le virer? Ouaip! Faut voir avec Manue et Camille... Martin. |
From: Federica D. <da...@lm...> - 2010-09-02 19:52:10
|
Salut, donc, j'ai juste fait un petit test en récompilant coffee (avec les formulations dont je me sers) avec F_POINTER commenté et à premier abord ça a l'air de marcher. Par contre j'y vois pas clair sur ce que ça peut vouloir dire pour d'autres utilisateurs qui se servent d'autres formulations. Je creuse dans ça avant qu'on décide de le virer? Federica -- Federica Daghia, Ph.D Assistant Professor École Normale Supérieure de Cachan - ENS Cachan DGM - LMT Cachan 61, avenue du Président Wilson 94235 Cachan Cedex - FRANCE Tel.: +33 (0)1 47 40 53 01 Fax: +33 (0)1 47 40 27 85 Quoting Martin Genet <ge...@lm...>: > Salut Fédé! > >> Salut! Ça va a S Francisco? > > Ouais, ici tout est plutôt cool! > > :) > >> Je t'écris séparément pour pas embêter tout le monde... > > À mon avis ça vaut le coup de discuter de ça tous ensemble... > > (Fédé a dit OK :P) > >> J'ai fait un rgrep dans tout le repertoire de Coffee et je trouve ça: >> >> agassac:/utmp/loupiac/daghia/Coffee% rgrep "F_POINTER" ./ >> Fichier binaire ./build/x86_64/DDM/SST_x86_64.o concordant >> Fichier binaire ./build/x86_64/DDM/lib_DDM.a concordant >> Fichier binaire ./build/x86_64/coffee.o concordant >> Fichier binaire ./build/x86_64/datastruct.o concordant >> Fichier binaire >> ./LMT/.git/objects/pack/pack-db7927f27116d57af47547c684f860c7b60ed89d.pack >> concordant >> ./LMT/include/formulation/formulationassembly.h:extern >> LMT::Vec<double>* F_POINTER; >> ./LMT/include/formulation/formulationassembly.h: F_POINTER >> = &f_nodal; >> ./coffee_src/coffee.cpp:LMT::Vec<double>* F_POINTER; ///< >> Pointer of the reaction forces, used in CAS4 >> ./formulations/CAS_2_e_ortho_corot.h:extern LMT::Vec<double>* F_POINTER; >> ./formulations/CAS_2_elasticity_iso.h:extern LMT::Vec<double>* F_POINTER; >> ./formulations/formulation_inter_unil.py: cw.add(Fi, >> '(*F_POINTER)[ indices[ '+str(k_node)+' ] + '+str(k_dim)+' ]', >> Write_code.Add) >> ./formulations/CAS_2_e_iso_corot.h:extern LMT::Vec<double>* F_POINTER; >> ./formulations/formulation_inter_elasticity.py: cw.add(Fi, >> '(*F_POINTER)[ indices[ '+str(k_node)+' ] + '+str(k_dim)+' ]', >> Write_code.Add) >> >> Du coup je vois qu'il est défini dans coffee.cpp mais l'utilisation se >> fait dans des CAS_2 bizarres (notamment, nul part dans meso_pli, >> meso_interface ou d'autres lois typiques de Coffee). T'es d'accord? >> Alors pourquoi? ça sert à quoi dans les formulations 'classiques'? > > On a fait ça pour assembler F élément-par-élément plutôt qu'en > assemblant K puis en faisant F = K * U... > >> D'autant plus que si je commente la ligne qui parle de F_POINTER dans >> coffee.cpp et dans LMTpp (2 lignes) Coffee a l'air de compiler. J'ai >> pas testé ce que ça donne le calcul, par contre... > > Il me semblait que vous aviez utilisé ça pour le meso-model aussi, > mais visiblement non. > > Il me semblait aussi que Camille avait utilisé ça pour ses > formulations, faut voir avec lui. > > Il me semble toujours que c'est nécessaire pour la formulation > corotationnelle (de la même manière que pour mes formulations à moi). > >> J'ai toujours pas compris, si F_POINTER est utilisé pour assembler le >> résidu, pourquoi ça n'apparaît pas dans les formulations dont on se >> sert habituellement (ou dont tu te servait). J'ai peut être pas >> compris quelques choses... > > Je crois que c'est dans formulation_assembly, pas dans formulation. > C'est ça ta question non? :) > > Bon, si vous voulez l'enlever, pas de soucis pour moi: je peux > enlever mes formulations de Coffee, car je ne calcule plus qu'avec > Abaqus! :) > >> Pour l'instant je ne suis pas pour le virer, il faut que je >> comprenne ça d'abord. Si ça sert pour le corot >> il faut que je demande à Manue aussi. > > :D > > Martin. > >> Quoting Martin Genet <ge...@lm...>: >> >> > Salut à tous, >> > >> > En fait, c'est pas pour moi en particulier, mais pour Coffee en général... >> > >> > Un petit rappel des faits: >> > >> > Le mercredi 10 juin 2009 03:25:48, gou...@lm... a écrit: >> >> Salut Martin, >> >> >> >> A ma dernière mise à jour de LMTPP, mon code ne compilait plus. Cela >> >> était du au fait que tu avais rajouté >> >> >> >> extern LMT::Vec<double>* F_POINTER; >> >> >> >> dans formulation.h >> >> >> >> Pour contourner le problème, j'ai du déclarer LMT::Vec<double>* >> >> F_POINTER dans mes programmes. >> >> >> >> C'est embetant parce que beaucoup de monde devra faire cette déclaration. >> >> >> >> Ne serait-il pas possible que tu enlèves ce LMT::Vec<double>* >> >> F_POINTER de formulation.h ? >> >> >> >> Merci pour ta réponse, >> >> >> >> Camille >> > >> > Le mercredi 10 juin 2009 05:57:01, gou...@lm... a écrit: >> >> J'arrive à contourner le problème quand je génère du code avec le type >> >> "double". >> >> >> >> Par contre, quand je génère mon code avec des complexes ou des >> >> polynomes, je ne peux pas contourner le problème sans modifier LMTPP. >> >> >> >> Quitte à modifier LMTPP, je me dit qu'il vaut mieux autant virer >> >> F_POINTER. Je vais donc l'enlever et faire un patch pour Hugo. >> > >> > Le mercredi 10 juin 2009 07:53:39, Martin Genet a écrit: >> >> tout le monde est d'accord pour dire que c'est crade >> >> le problème c'est qu'on n'a pas vraiment trouvé d'autre solution >> >> pour construire un résidu par élément dans le newton de coffee >> > >> > Le mercredi 10 juin 2009 08:04:57, Hugo Leclerc a écrit: >> >> C'est fait mais il est toujours dans formulation_assembly.h >> >> >> >> extern est embétant mais surtout obligatoire parce que sinon, >> >> beaucoup de gens >> >> vont avoir le message F_POINTER défini dans plusieurs endroits >> >> (différents .cpp >> >> qui incluent le même .h) et ne pourront rien faire. >> > >> > Le mercredi 10 juin 2009 08:08:12, Hugo Leclerc a écrit: >> >> Pour que tout le monde soit content sauf moi et les golgoths qui se font >> >> toujours péter la gueule par goldorak, j'ai dit que f_nodal était un >> >> Vec<double> >> >> >> >> Là, c'est super cradal. >> > >> > Le mercredi 10 juin 2009 09:15:03, gou...@lm... a écrit: >> >> Cette solution me convient faute de mieux pour l'instant >> > >> > Il semblerait que ça ne convienne plus à Camille...quelqu'un a-t-il >> > une solution pour réparer ça sans casser Coffee? >> > >> > Bonne journée! >> > >> > Martin. >> > >> > PS: Il est 7h30, quand San Francisco se lève, quand San Francisco se >> > lève, où êtes-vous? >> > >> > >> > >> > >> > >> > >> > >> > >> > Le jeudi 2 septembre 2010 04:28:46, PASQUIER Raphaël a écrit: >> >> >> >> Il me semble que cela servait à Martin Genet. >> >> A lui demander >> >> >> >> >> >> >> >> > Bonjour à tous, >> >> > >> >> > Je souhaite supprimer la variable globale "extern LMT::Vec<double>* >> >> > F_POINTER" definie dans le fichier >> >> > "include/formulations/formulationassembly.h". Elle existe depuis plus >> >> > d'un an et devait être là de manière temporaire. Je voudrais donc >> >> > savoir si des gens l'utilisent encore afin que je puisse la supprimer >> >> > sans risque. >> >> > >> >> > Les raisons qui me poussent à vouloir les supprimer sont multiples : >> >> > - À chaque nouveau *.cpp que je fais et qui utilise >> >> > "formulationassembly.h", je dois déclarer un "LMT::Vec<double>* >> >> > F_POINTER". Sinon, j'ai des problèmes à la compilation. >> >> > - J'ai également des problèmes à la compilation quand j'essaye des >> >> > compiler avec des types scalaires autres que "double". En effet, >> >> > "extern LMT::Vec<double>* F_POINTER" impose que le membre "f_nodal" de >> >> > la struct "FormulationAssembly" soit de type "Vec<double>". C'est très >> >> > rigide et il faudrait mieux que ça soit un "Vec<T>" (où "T" est un >> >> > paramètre template) comme les autres membres de la struct. Ainsi bien >> >> > des problèmes à la compilation pourraient être évités. >> >> > - Les variables globales c'est maaaal. >> >> > >> >> > Certes, je pourrais faire cette suppression dans mon coin, ainsi que >> >> > de typer "f_nodal" en "Vec<T>". C'est ce que j'ai déjà fait plusieurs >> >> > fois dans le passé. Mais à chaque fois que je veux repartir de la >> >> > toute dernière version de LMTpp, les problèmes à la compilation >> >> > ressurgissent. Et là, je commence à en avoir marre de ce truc >> >> > super-crade qui traîne depuis plus d'un an. >> >> > >> >> > Alors je vous le redemande, puis-je virer la variable globale "extern >> >> > LMT::Vec<double>* F_POINTER" sans risque ? Sans réponse de votre part, >> >> > je prendrai ça pour un oui. >> >> > >> >> > Cordialement, >> >> > >> >> > Camille >> >> > >> >> > >> >> > >> >> >> --------------------------------------------------------------------------- >> >> >--- This SF.net Dev2Dev email is sponsored by: >> >> > >> >> > Show off your parallel programming skills. >> >> > Enter the Intel(R) Threading Challenge 2010. >> >> > http://p.sf.net/sfu/intel-thread-sfd >> >> > _______________________________________________ >> >> > Metil-lmtpp mailing list >> >> > Met...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp >> >> >> >> >> >> >> >> Cordialement, >> >> Raphaël Pasquier >> >> >> >> >> >> -- >> >> Raphaël PASQUIER (AI LMT) >> >> Tel : 01 47 40 27 36 >> >> Email : rap...@lm... >> >> rap...@fr... >> >> LMT-Cachan >> >> (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) >> >> 61, av. du Président Wilson >> >> F-94230 Cachan >> >> France >> >> >> >> >> ------------------------------------------------------------------------------ >> >> This SF.net Dev2Dev email is sponsored by: >> >> >> >> Show off your parallel programming skills. >> >> Enter the Intel(R) Threading Challenge 2010. >> >> http://p.sf.net/sfu/intel-thread-sfd >> >> _______________________________________________ >> >> Metil-lmtpp mailing list >> >> Met...@li... >> >> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp >> >> >> > >> > >> ------------------------------------------------------------------------------ >> > This SF.net Dev2Dev email is sponsored by: >> > >> > Show off your parallel programming skills. >> > Enter the Intel(R) Threading Challenge 2010. >> > http://p.sf.net/sfu/intel-thread-sfd >> > _______________________________________________ >> > Metil-lmtpp mailing list >> > Met...@li... >> > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp >> > >> >> >> >> > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > |
From: Martin G. <ge...@lm...> - 2010-09-02 19:24:54
|
Salut Fédé! > Salut! Ça va a S Francisco? Ouais, ici tout est plutôt cool! :) > Je t'écris séparément pour pas embêter tout le monde... À mon avis ça vaut le coup de discuter de ça tous ensemble... (Fédé a dit OK :P) > J'ai fait un rgrep dans tout le repertoire de Coffee et je trouve ça: > > agassac:/utmp/loupiac/daghia/Coffee% rgrep "F_POINTER" ./ > Fichier binaire ./build/x86_64/DDM/SST_x86_64.o concordant > Fichier binaire ./build/x86_64/DDM/lib_DDM.a concordant > Fichier binaire ./build/x86_64/coffee.o concordant > Fichier binaire ./build/x86_64/datastruct.o concordant > Fichier binaire > ./LMT/.git/objects/pack/pack-db7927f27116d57af47547c684f860c7b60ed89d.pack > concordant > ./LMT/include/formulation/formulationassembly.h:extern > LMT::Vec<double>* F_POINTER; > ./LMT/include/formulation/formulationassembly.h: F_POINTER > = &f_nodal; > ./coffee_src/coffee.cpp:LMT::Vec<double>* F_POINTER; ///< > Pointer of the reaction forces, used in CAS4 > ./formulations/CAS_2_e_ortho_corot.h:extern LMT::Vec<double>* F_POINTER; > ./formulations/CAS_2_elasticity_iso.h:extern LMT::Vec<double>* F_POINTER; > ./formulations/formulation_inter_unil.py: cw.add(Fi, > '(*F_POINTER)[ indices[ '+str(k_node)+' ] + '+str(k_dim)+' ]', > Write_code.Add) > ./formulations/CAS_2_e_iso_corot.h:extern LMT::Vec<double>* F_POINTER; > ./formulations/formulation_inter_elasticity.py: cw.add(Fi, > '(*F_POINTER)[ indices[ '+str(k_node)+' ] + '+str(k_dim)+' ]', > Write_code.Add) > > Du coup je vois qu'il est défini dans coffee.cpp mais l'utilisation se > fait dans des CAS_2 bizarres (notamment, nul part dans meso_pli, > meso_interface ou d'autres lois typiques de Coffee). T'es d'accord? > Alors pourquoi? ça sert à quoi dans les formulations 'classiques'? On a fait ça pour assembler F élément-par-élément plutôt qu'en assemblant K puis en faisant F = K * U... > D'autant plus que si je commente la ligne qui parle de F_POINTER dans > coffee.cpp et dans LMTpp (2 lignes) Coffee a l'air de compiler. J'ai > pas testé ce que ça donne le calcul, par contre... Il me semblait que vous aviez utilisé ça pour le meso-model aussi, mais visiblement non. Il me semblait aussi que Camille avait utilisé ça pour ses formulations, faut voir avec lui. Il me semble toujours que c'est nécessaire pour la formulation corotationnelle (de la même manière que pour mes formulations à moi). > J'ai toujours pas compris, si F_POINTER est utilisé pour assembler le > résidu, pourquoi ça n'apparaît pas dans les formulations dont on se > sert habituellement (ou dont tu te servait). J'ai peut être pas > compris quelques choses... Je crois que c'est dans formulation_assembly, pas dans formulation. C'est ça ta question non? :) Bon, si vous voulez l'enlever, pas de soucis pour moi: je peux enlever mes formulations de Coffee, car je ne calcule plus qu'avec Abaqus! :) > Pour l'instant je ne suis pas pour le virer, il faut que je comprenne ça d'abord. Si ça sert pour le corot > il faut que je demande à Manue aussi. :D Martin. > Quoting Martin Genet <ge...@lm...>: > > > Salut à tous, > > > > En fait, c'est pas pour moi en particulier, mais pour Coffee en général... > > > > Un petit rappel des faits: > > > > Le mercredi 10 juin 2009 03:25:48, gou...@lm... a écrit: > >> Salut Martin, > >> > >> A ma dernière mise à jour de LMTPP, mon code ne compilait plus. Cela > >> était du au fait que tu avais rajouté > >> > >> extern LMT::Vec<double>* F_POINTER; > >> > >> dans formulation.h > >> > >> Pour contourner le problème, j'ai du déclarer LMT::Vec<double>* > >> F_POINTER dans mes programmes. > >> > >> C'est embetant parce que beaucoup de monde devra faire cette déclaration. > >> > >> Ne serait-il pas possible que tu enlèves ce LMT::Vec<double>* > >> F_POINTER de formulation.h ? > >> > >> Merci pour ta réponse, > >> > >> Camille > > > > Le mercredi 10 juin 2009 05:57:01, gou...@lm... a écrit: > >> J'arrive à contourner le problème quand je génère du code avec le type > >> "double". > >> > >> Par contre, quand je génère mon code avec des complexes ou des > >> polynomes, je ne peux pas contourner le problème sans modifier LMTPP. > >> > >> Quitte à modifier LMTPP, je me dit qu'il vaut mieux autant virer > >> F_POINTER. Je vais donc l'enlever et faire un patch pour Hugo. > > > > Le mercredi 10 juin 2009 07:53:39, Martin Genet a écrit: > >> tout le monde est d'accord pour dire que c'est crade > >> le problème c'est qu'on n'a pas vraiment trouvé d'autre solution > >> pour construire un résidu par élément dans le newton de coffee > > > > Le mercredi 10 juin 2009 08:04:57, Hugo Leclerc a écrit: > >> C'est fait mais il est toujours dans formulation_assembly.h > >> > >> extern est embétant mais surtout obligatoire parce que sinon, > >> beaucoup de gens > >> vont avoir le message F_POINTER défini dans plusieurs endroits > >> (différents .cpp > >> qui incluent le même .h) et ne pourront rien faire. > > > > Le mercredi 10 juin 2009 08:08:12, Hugo Leclerc a écrit: > >> Pour que tout le monde soit content sauf moi et les golgoths qui se font > >> toujours péter la gueule par goldorak, j'ai dit que f_nodal était un > >> Vec<double> > >> > >> Là, c'est super cradal. > > > > Le mercredi 10 juin 2009 09:15:03, gou...@lm... a écrit: > >> Cette solution me convient faute de mieux pour l'instant > > > > Il semblerait que ça ne convienne plus à Camille...quelqu'un a-t-il > > une solution pour réparer ça sans casser Coffee? > > > > Bonne journée! > > > > Martin. > > > > PS: Il est 7h30, quand San Francisco se lève, quand San Francisco se > > lève, où êtes-vous? > > > > > > > > > > > > > > > > > > Le jeudi 2 septembre 2010 04:28:46, PASQUIER Raphaël a écrit: > >> > >> Il me semble que cela servait à Martin Genet. > >> A lui demander > >> > >> > >> > >> > Bonjour à tous, > >> > > >> > Je souhaite supprimer la variable globale "extern LMT::Vec<double>* > >> > F_POINTER" definie dans le fichier > >> > "include/formulations/formulationassembly.h". Elle existe depuis plus > >> > d'un an et devait être là de manière temporaire. Je voudrais donc > >> > savoir si des gens l'utilisent encore afin que je puisse la supprimer > >> > sans risque. > >> > > >> > Les raisons qui me poussent à vouloir les supprimer sont multiples : > >> > - À chaque nouveau *.cpp que je fais et qui utilise > >> > "formulationassembly.h", je dois déclarer un "LMT::Vec<double>* > >> > F_POINTER". Sinon, j'ai des problèmes à la compilation. > >> > - J'ai également des problèmes à la compilation quand j'essaye des > >> > compiler avec des types scalaires autres que "double". En effet, > >> > "extern LMT::Vec<double>* F_POINTER" impose que le membre "f_nodal" de > >> > la struct "FormulationAssembly" soit de type "Vec<double>". C'est très > >> > rigide et il faudrait mieux que ça soit un "Vec<T>" (où "T" est un > >> > paramètre template) comme les autres membres de la struct. Ainsi bien > >> > des problèmes à la compilation pourraient être évités. > >> > - Les variables globales c'est maaaal. > >> > > >> > Certes, je pourrais faire cette suppression dans mon coin, ainsi que > >> > de typer "f_nodal" en "Vec<T>". C'est ce que j'ai déjà fait plusieurs > >> > fois dans le passé. Mais à chaque fois que je veux repartir de la > >> > toute dernière version de LMTpp, les problèmes à la compilation > >> > ressurgissent. Et là, je commence à en avoir marre de ce truc > >> > super-crade qui traîne depuis plus d'un an. > >> > > >> > Alors je vous le redemande, puis-je virer la variable globale "extern > >> > LMT::Vec<double>* F_POINTER" sans risque ? Sans réponse de votre part, > >> > je prendrai ça pour un oui. > >> > > >> > Cordialement, > >> > > >> > Camille > >> > > >> > > >> > > >> --------------------------------------------------------------------------- > >> >--- This SF.net Dev2Dev email is sponsored by: > >> > > >> > Show off your parallel programming skills. > >> > Enter the Intel(R) Threading Challenge 2010. > >> > http://p.sf.net/sfu/intel-thread-sfd > >> > _______________________________________________ > >> > Metil-lmtpp mailing list > >> > Met...@li... > >> > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > >> > >> > >> > >> Cordialement, > >> Raphaël Pasquier > >> > >> > >> -- > >> Raphaël PASQUIER (AI LMT) > >> Tel : 01 47 40 27 36 > >> Email : rap...@lm... > >> rap...@fr... > >> LMT-Cachan > >> (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > >> 61, av. du Président Wilson > >> F-94230 Cachan > >> France > >> > >> ------------------------------------------------------------------------------ > >> This SF.net Dev2Dev email is sponsored by: > >> > >> Show off your parallel programming skills. > >> Enter the Intel(R) Threading Challenge 2010. > >> http://p.sf.net/sfu/intel-thread-sfd > >> _______________________________________________ > >> Metil-lmtpp mailing list > >> Met...@li... > >> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > >> > > > > ------------------------------------------------------------------------------ > > This SF.net Dev2Dev email is sponsored by: > > > > Show off your parallel programming skills. > > Enter the Intel(R) Threading Challenge 2010. > > http://p.sf.net/sfu/intel-thread-sfd > > _______________________________________________ > > Metil-lmtpp mailing list > > Met...@li... > > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > > > > > > |
From: Martin G. <ge...@lm...> - 2010-09-02 14:47:13
|
Salut à tous, En fait, c'est pas pour moi en particulier, mais pour Coffee en général... Un petit rappel des faits: Le mercredi 10 juin 2009 03:25:48, gou...@lm... a écrit: > Salut Martin, > > A ma dernière mise à jour de LMTPP, mon code ne compilait plus. Cela > était du au fait que tu avais rajouté > > extern LMT::Vec<double>* F_POINTER; > > dans formulation.h > > Pour contourner le problème, j'ai du déclarer LMT::Vec<double>* > F_POINTER dans mes programmes. > > C'est embetant parce que beaucoup de monde devra faire cette déclaration. > > Ne serait-il pas possible que tu enlèves ce LMT::Vec<double>* > F_POINTER de formulation.h ? > > Merci pour ta réponse, > > Camille Le mercredi 10 juin 2009 05:57:01, gou...@lm... a écrit: > J'arrive à contourner le problème quand je génère du code avec le type > "double". > > Par contre, quand je génère mon code avec des complexes ou des > polynomes, je ne peux pas contourner le problème sans modifier LMTPP. > > Quitte à modifier LMTPP, je me dit qu'il vaut mieux autant virer > F_POINTER. Je vais donc l'enlever et faire un patch pour Hugo. Le mercredi 10 juin 2009 07:53:39, Martin Genet a écrit: > tout le monde est d'accord pour dire que c'est crade > le problème c'est qu'on n'a pas vraiment trouvé d'autre solution pour construire un résidu par élément dans le newton de coffee Le mercredi 10 juin 2009 08:04:57, Hugo Leclerc a écrit: > C'est fait mais il est toujours dans formulation_assembly.h > > extern est embétant mais surtout obligatoire parce que sinon, beaucoup de gens > vont avoir le message F_POINTER défini dans plusieurs endroits (différents .cpp > qui incluent le même .h) et ne pourront rien faire. Le mercredi 10 juin 2009 08:08:12, Hugo Leclerc a écrit: > Pour que tout le monde soit content sauf moi et les golgoths qui se font > toujours péter la gueule par goldorak, j'ai dit que f_nodal était un > Vec<double> > > Là, c'est super cradal. Le mercredi 10 juin 2009 09:15:03, gou...@lm... a écrit: > Cette solution me convient faute de mieux pour l'instant Il semblerait que ça ne convienne plus à Camille...quelqu'un a-t-il une solution pour réparer ça sans casser Coffee? Bonne journée! Martin. PS: Il est 7h30, quand San Francisco se lève, quand San Francisco se lève, où êtes-vous? Le jeudi 2 septembre 2010 04:28:46, PASQUIER Raphaël a écrit: > > Il me semble que cela servait à Martin Genet. > A lui demander > > > > > Bonjour à tous, > > > > Je souhaite supprimer la variable globale "extern LMT::Vec<double>* > > F_POINTER" definie dans le fichier > > "include/formulations/formulationassembly.h". Elle existe depuis plus > > d'un an et devait être là de manière temporaire. Je voudrais donc > > savoir si des gens l'utilisent encore afin que je puisse la supprimer > > sans risque. > > > > Les raisons qui me poussent à vouloir les supprimer sont multiples : > > - À chaque nouveau *.cpp que je fais et qui utilise > > "formulationassembly.h", je dois déclarer un "LMT::Vec<double>* > > F_POINTER". Sinon, j'ai des problèmes à la compilation. > > - J'ai également des problèmes à la compilation quand j'essaye des > > compiler avec des types scalaires autres que "double". En effet, > > "extern LMT::Vec<double>* F_POINTER" impose que le membre "f_nodal" de > > la struct "FormulationAssembly" soit de type "Vec<double>". C'est très > > rigide et il faudrait mieux que ça soit un "Vec<T>" (où "T" est un > > paramètre template) comme les autres membres de la struct. Ainsi bien > > des problèmes à la compilation pourraient être évités. > > - Les variables globales c'est maaaal. > > > > Certes, je pourrais faire cette suppression dans mon coin, ainsi que > > de typer "f_nodal" en "Vec<T>". C'est ce que j'ai déjà fait plusieurs > > fois dans le passé. Mais à chaque fois que je veux repartir de la > > toute dernière version de LMTpp, les problèmes à la compilation > > ressurgissent. Et là, je commence à en avoir marre de ce truc > > super-crade qui traîne depuis plus d'un an. > > > > Alors je vous le redemande, puis-je virer la variable globale "extern > > LMT::Vec<double>* F_POINTER" sans risque ? Sans réponse de votre part, > > je prendrai ça pour un oui. > > > > Cordialement, > > > > Camille > > > > > > --------------------------------------------------------------------------- > >--- This SF.net Dev2Dev email is sponsored by: > > > > Show off your parallel programming skills. > > Enter the Intel(R) Threading Challenge 2010. > > http://p.sf.net/sfu/intel-thread-sfd > > _______________________________________________ > > Metil-lmtpp mailing list > > Met...@li... > > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > > > > Cordialement, > Raphaël Pasquier > > > -- > Raphaël PASQUIER (AI LMT) > Tel : 01 47 40 27 36 > Email : rap...@lm... > rap...@fr... > LMT-Cachan > (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > 61, av. du Président Wilson > F-94230 Cachan > France > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > |
From: Bastien T. <tra...@lm...> - 2010-09-02 14:38:29
|
Bonjour, Une première version des element_set et node_set, ainsi que le lecteur de maillage .msh qui va avec, sera bientôt disponible bien qu'incomplète. En effet les entités physiques de dimension n-1 et n-2 ( en gros lignes, surfaces), qui donnent des groupes d'éléments sous GMSH, sont automatiquement transformés en groupe de noeuds pour le moment et ce pour des raisons de simplicité. Le tout devrait être pushé après relecture/test avec Raphael, sans doute courant de la semaine prochaines. Une petite page wiki sur l'utilisation et les possibilités viendra avec. Bastien P.S. : Pour ceux qui utilisent le lecteur read_msh_2, rassurez vous cela ne changera rien pour vous : les groupes sont automatiquement créer mais vous n'êtes pas obligé dans faire quoi que se soit. -- Bastien Tranquart PhD Student 2nd Year Laboratoire de Mécanique et Technologie, 61, Av. Président Wilson 94230 Cachan (FRANCE) Email : tra...@lm... Tel : +(33) 1 47 40 77 59 |
From: PASQUIER R. <rap...@lm...> - 2010-09-02 11:30:13
|
Il me semble que cela servait à Martin Genet. A lui demander > Bonjour à tous, > > Je souhaite supprimer la variable globale "extern LMT::Vec<double>* > F_POINTER" definie dans le fichier > "include/formulations/formulationassembly.h". Elle existe depuis plus > d'un an et devait être là de manière temporaire. Je voudrais donc > savoir si des gens l'utilisent encore afin que je puisse la supprimer > sans risque. > > Les raisons qui me poussent à vouloir les supprimer sont multiples : > - À chaque nouveau *.cpp que je fais et qui utilise > "formulationassembly.h", je dois déclarer un "LMT::Vec<double>* > F_POINTER". Sinon, j'ai des problèmes à la compilation. > - J'ai également des problèmes à la compilation quand j'essaye des > compiler avec des types scalaires autres que "double". En effet, > "extern LMT::Vec<double>* F_POINTER" impose que le membre "f_nodal" de > la struct "FormulationAssembly" soit de type "Vec<double>". C'est très > rigide et il faudrait mieux que ça soit un "Vec<T>" (où "T" est un > paramètre template) comme les autres membres de la struct. Ainsi bien > des problèmes à la compilation pourraient être évités. > - Les variables globales c'est maaaal. > > Certes, je pourrais faire cette suppression dans mon coin, ainsi que > de typer "f_nodal" en "Vec<T>". C'est ce que j'ai déjà fait plusieurs > fois dans le passé. Mais à chaque fois que je veux repartir de la > toute dernière version de LMTpp, les problèmes à la compilation > ressurgissent. Et là, je commence à en avoir marre de ce truc > super-crade qui traîne depuis plus d'un an. > > Alors je vous le redemande, puis-je virer la variable globale "extern > LMT::Vec<double>* F_POINTER" sans risque ? Sans réponse de votre part, > je prendrai ça pour un oui. > > Cordialement, > > Camille > > > --------------------------------------------------------------------------- >--- This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp Cordialement, Raphaël Pasquier -- Raphaël PASQUIER (AI LMT) Tel : 01 47 40 27 36 Email : rap...@lm... rap...@fr... LMT-Cachan (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) 61, av. du Président Wilson F-94230 Cachan France |
From: <gou...@lm...> - 2010-09-02 08:56:16
|
Bonjour à tous, Je souhaite supprimer la variable globale "extern LMT::Vec<double>* F_POINTER" definie dans le fichier "include/formulations/formulationassembly.h". Elle existe depuis plus d'un an et devait être là de manière temporaire. Je voudrais donc savoir si des gens l'utilisent encore afin que je puisse la supprimer sans risque. Les raisons qui me poussent à vouloir les supprimer sont multiples : - À chaque nouveau *.cpp que je fais et qui utilise "formulationassembly.h", je dois déclarer un "LMT::Vec<double>* F_POINTER". Sinon, j'ai des problèmes à la compilation. - J'ai également des problèmes à la compilation quand j'essaye des compiler avec des types scalaires autres que "double". En effet, "extern LMT::Vec<double>* F_POINTER" impose que le membre "f_nodal" de la struct "FormulationAssembly" soit de type "Vec<double>". C'est très rigide et il faudrait mieux que ça soit un "Vec<T>" (où "T" est un paramètre template) comme les autres membres de la struct. Ainsi bien des problèmes à la compilation pourraient être évités. - Les variables globales c'est maaaal. Certes, je pourrais faire cette suppression dans mon coin, ainsi que de typer "f_nodal" en "Vec<T>". C'est ce que j'ai déjà fait plusieurs fois dans le passé. Mais à chaque fois que je veux repartir de la toute dernière version de LMTpp, les problèmes à la compilation ressurgissent. Et là, je commence à en avoir marre de ce truc super-crade qui traîne depuis plus d'un an. Alors je vous le redemande, puis-je virer la variable globale "extern LMT::Vec<double>* F_POINTER" sans risque ? Sans réponse de votre part, je prendrai ça pour un oui. Cordialement, Camille |
From: Bastien T. <tra...@lm...> - 2010-08-26 15:56:30
|
Bonjour à tous, Prochainement, il va être développé des entités physiques dans les maillages sous LMtpp. Ceci afin de faire un peu l'équivalent des nodes_set et elem_set sous Abaqus et permettre d'appliquer des conditions limites et/ou propriétés matériau de façon plus aisée. Ils devraient être disponibles comme membre du maillage et être utilisable comme des elemt_list / node_list, histoire de pouvoir faire des apply dessus. Le lecteur de maillages msh (read_msh_2) sera bien entendu développé avec, histoire de pouvoir utiliser les tags etc... disponible sur le mailleur/maillage gmsh. Si certains utilisent un autre mailleur, il y aura un peu de code à faire, mais il faut que les tags soient disponibles dans le format utilisé pour le fichier de maillage : ex : le format AVS de dispose pas, pour ce que j'en sais, de la possibilité de "tagger" les noeuds ou les éléments ... Est-ce que certains d'entre vous ont déjà codé ça (histoire de pas refaire les choses) ? Ou bien avez-vous des demandes particulières vis- à-vis de cet ajout ? (ex : d'autres groupes que des noeuds ou des éléments, quel type de label (chaîne de caractère ou un entier)... ). Comme c'est moi qui code, je peux tenir compte de vos suggestions mais je vous dis d'avance que je pourrai sans doute pas tout faire tout seul ... Le développement commencera au courant de la semaine prochaine. Bien à vous, A bientôt, -- Bastien Tranquart PhD Student 2nd Year Laboratoire de Mécanique et Technologie, 61, Av. Président Wilson 94230 Cachan (FRANCE) Email : tra...@lm... Tel : +(33) 1 47 40 77 59 |
From: Martin G. <mar...@lm...> - 2009-12-16 17:25:57
|
Un point sur l'intégration: Si dans formulation.py on trouve integration_totale = True (comportement par défaut), alors le code c++ généré lorsque e.integration(expression) est appelé correspond à l'intégration analytique de expression sur l'élément. Si dans formulation.py on trouve integration_totale = False, alors le code c++ généré lorsque e.integration(expression) est appelé correspond à l'intégration de Gauss de expression sur l'élément. Par défaut, le degré de expression est calculé automatique en fonction de l'élément (2 pour les éléments linéaires, 4 pour les éléments quadratiques, etc). On peut également spécifier le degré en appelant e.integration(expression, degré), par exemple pour faire de la sous-intégration. > - Pourquoi, dans certains fichiers element.py —e.g. element_Tetra, element_Wedge, element_Hexa, ...—, certains jeux de points de Gauss —e.g. gauss_points[2] dans element_Hexa— ont-ils été commentés? Certains jeux de points de Gauss ont été décommentés (e.g. element_Tetra.py, element_Wedge.py, element_Hexa.py, ...). > - Serait-ce envisageable de créer dans ce cas des jeux qui pointent vers leur supérieur —e.g. gauss_points[2] = gauss_points[3]—? Certains jeux de points de Gauss ont été crées qui pointent vers leur supérieur (e.g. element_Tetra.py, element_Wedge.py, element_Hexa.py, ...). Martin. |
From: Martin G. <mar...@lm...> - 2009-12-16 17:12:25
|
Le problème a été magnifiquement résolu par le magnifique Hugal aujourd'hui: dans matdense.h.py vous trouvez désormais Mat &operator=(int val) { data.set(val); return *this; } Qui permet d'initialiser une matrice avec un entier... On mardi 15 décembre 2009 15:58:09, Martin Genet wrote: > Cher tous, > > En passant les variables internes de mes formulations à des champs de type 'gauss', j'ai rencontré un problème du fait que certaines des mes variables internes sont des matrices, et donc sur l'élément on doit stocker un vecteur matrice (une pour chaque point de Gauss). > > Or les vecteurs ne possédaient qu'un constructeur de type (voir vecfull.h.py): > > > Vec(const TT &v) { for(unsigned i=0;i<(unsigned)static_size;val[i++]=v); } > > qui prend en argument un élément du type des éléments stockés dans le vecteur et le mets partout dans le vecteur. Typiquement, si vous initialisez un vecteur de double avec 3, il mets 3 partout. > > Or on voulait aussi pouvoir initialiser un vecteur de matrices avec un scalaire (d'où le patch d'hier soir), et on a désormais: > > > template<class T2> Vec(const T2 &v) { for(unsigned i=0;i<(unsigned)static_size;val[i++]=v); } > > Mais un problème subsiste, justement si on cherche à initialiser un vecteur de matrices avec un scalaire, car l'opérateur = pour les matrices a été commenté (voir matdense.h.py): > > > //template<class T2> Mat &operator=(const T2 &val) { data.set((T)val); return *this; } > > On pourrait imaginer décommenter la ligne. Typiquement, si vous initialisez une matrice de double avec 3, il mets 3 partout. > > Mais un problème subsiste, si on cherche à initialiser une matrice avec une matrice. J'avais pensé à > > > template<class T2> Mat &operator=(const T2 &val) { data.set((T)val); return *this; } > > template<class T2> Mat &operator=(const Mat<T2> &val) { data = val.data; return *this; } > > Mais val.data n'est pas défini pour toutes les matrices... > > Une idée? > > Merci! > > Martin. > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > |
From: Martin G. <mar...@lm...> - 2009-12-15 14:59:36
|
On lundi 14 décembre 2009 15:49:55, Martin Genet wrote: > Le seul problème: si je ne donne pas le path exact (/home/genet/.../fields.py), il ne le trouve pas...quelqu'un sait-il comment faire? J'ai "solutionné" le problème: execfile("formulations/fields.py")... |
From: Martin G. <mar...@lm...> - 2009-12-15 14:58:44
|
Cher tous, En passant les variables internes de mes formulations à des champs de type 'gauss', j'ai rencontré un problème du fait que certaines des mes variables internes sont des matrices, et donc sur l'élément on doit stocker un vecteur matrice (une pour chaque point de Gauss). Or les vecteurs ne possédaient qu'un constructeur de type (voir vecfull.h.py): > Vec(const TT &v) { for(unsigned i=0;i<(unsigned)static_size;val[i++]=v); } qui prend en argument un élément du type des éléments stockés dans le vecteur et le mets partout dans le vecteur. Typiquement, si vous initialisez un vecteur de double avec 3, il mets 3 partout. Or on voulait aussi pouvoir initialiser un vecteur de matrices avec un scalaire (d'où le patch d'hier soir), et on a désormais: > template<class T2> Vec(const T2 &v) { for(unsigned i=0;i<(unsigned)static_size;val[i++]=v); } Mais un problème subsiste, justement si on cherche à initialiser un vecteur de matrices avec un scalaire, car l'opérateur = pour les matrices a été commenté (voir matdense.h.py): > //template<class T2> Mat &operator=(const T2 &val) { data.set((T)val); return *this; } On pourrait imaginer décommenter la ligne. Typiquement, si vous initialisez une matrice de double avec 3, il mets 3 partout. Mais un problème subsiste, si on cherche à initialiser une matrice avec une matrice. J'avais pensé à > template<class T2> Mat &operator=(const T2 &val) { data.set((T)val); return *this; } > template<class T2> Mat &operator=(const Mat<T2> &val) { data = val.data; return *this; } Mais val.data n'est pas défini pour toutes les matrices... Une idée? Merci! Martin. |
From: Martin G. <mar...@lm...> - 2009-12-14 14:50:32
|
Évidement ça marche! Le seul problème: si je ne donne pas le path exact (/home/genet/.../fields.py), il ne le trouve pas...quelqu'un sait-il comment faire? Merci! Martin. On dimanche 13 décembre 2009 17:38:59, Felipe Bordeu Weldt wrote: > execfile > > pardon > > Felipe > > Le 13 déc. 09 à 16:57, Felipe Bordeu Weldt a écrit : > > > C’est du python donc vous pouvez écrire « > > exec(mon_fichier_des_champs.py)» à la place et voilà. > > > > Felipe > > > > Le 13 déc. 09 à 16:48, gou...@lm... a écrit : > > > >> Salut, > >> > >> Ca m'intéresse également. J'ai beaucoup de fichiers de formulations > >> avec des champs communs. > >> > >> Kk > >> > >> Martin Genet <mar...@lm...> a écrit : > >> > >>> Salut à tous, > >>> > >>> Est-il possible de définir les champs d'une formulation dans un > >>> fichier extérieur à laa formulation? On pourrait ainsi utiliser les > >>> mêmes champs pour plusieurs formulation... > >>> > >>> Merci! > >>> > >>> Martin. > >>> > >>> ------------------------------------------------------------------------------ > >>> Return on Information: > >>> Google Enterprise Search pays you back > >>> Get the facts. > >>> http://p.sf.net/sfu/google-dev2dev > >>> _______________________________________________ > >>> Metil-lmtpp mailing list > >>> Met...@li... > >>> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > >>> > >> > >> > >> > >> > >> ------------------------------------------------------------------------------ > >> Return on Information: > >> Google Enterprise Search pays you back > >> Get the facts. > >> http://p.sf.net/sfu/google-dev2dev > >> _______________________________________________ > >> Metil-lmtpp mailing list > >> Met...@li... > >> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > > > > ------------------------------------------------------------------------ > > Felipe Bordeu Weldt > > Doctorant - 3° année (3° year PhD student) > > ------------------------------------------------------------------------ > > Tél : 01 47 40 22 26 > > Mob : 06 32 42 60 02 > > LMT-Cachan > > (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > > 61, av. du Président Wilson > > F-94230 Cachan > > France > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Return on Information: > > Google Enterprise Search pays you back > > Get the facts. > > http://p.sf.net/sfu/google-dev2dev > > _______________________________________________ > > Metil-lmtpp mailing list > > Met...@li... > > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > > ------------------------------------------------------------------------ > Felipe Bordeu Weldt > Doctorant - 3° année (3° year PhD student) > ------------------------------------------------------------------------ > Tél : 01 47 40 22 26 > Mob : 06 32 42 60 02 > LMT-Cachan > (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > 61, av. du Président Wilson > F-94230 Cachan > France > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > |
From: Felipe B. W. <bo...@lm...> - 2009-12-13 16:39:25
|
execfile pardon Felipe Le 13 déc. 09 à 16:57, Felipe Bordeu Weldt a écrit : > C’est du python donc vous pouvez écrire « > exec(mon_fichier_des_champs.py)» à la place et voilà. > > Felipe > > Le 13 déc. 09 à 16:48, gou...@lm... a écrit : > >> Salut, >> >> Ca m'intéresse également. J'ai beaucoup de fichiers de formulations >> avec des champs communs. >> >> Kk >> >> Martin Genet <mar...@lm...> a écrit : >> >>> Salut à tous, >>> >>> Est-il possible de définir les champs d'une formulation dans un >>> fichier extérieur à laa formulation? On pourrait ainsi utiliser les >>> mêmes champs pour plusieurs formulation... >>> >>> Merci! >>> >>> Martin. >>> >>> ------------------------------------------------------------------------------ >>> Return on Information: >>> Google Enterprise Search pays you back >>> Get the facts. >>> http://p.sf.net/sfu/google-dev2dev >>> _______________________________________________ >>> Metil-lmtpp mailing list >>> Met...@li... >>> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp >>> >> >> >> >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Metil-lmtpp mailing list >> Met...@li... >> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > > ------------------------------------------------------------------------ > Felipe Bordeu Weldt > Doctorant - 3° année (3° year PhD student) > ------------------------------------------------------------------------ > Tél : 01 47 40 22 26 > Mob : 06 32 42 60 02 > LMT-Cachan > (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) > 61, av. du Président Wilson > F-94230 Cachan > France > ------------------------------------------------------------------------ > > > > > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp ------------------------------------------------------------------------ Felipe Bordeu Weldt Doctorant - 3° année (3° year PhD student) ------------------------------------------------------------------------ Tél : 01 47 40 22 26 Mob : 06 32 42 60 02 LMT-Cachan (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) 61, av. du Président Wilson F-94230 Cachan France ------------------------------------------------------------------------ |
From: Felipe B. W. <bo...@lm...> - 2009-12-13 15:58:19
|
C’est du python donc vous pouvez écrire « exec(mon_fichier_des_champs.py)» à la place et voilà. Felipe Le 13 déc. 09 à 16:48, gou...@lm... a écrit : > Salut, > > Ca m'intéresse également. J'ai beaucoup de fichiers de formulations > avec des champs communs. > > Kk > > Martin Genet <mar...@lm...> a écrit : > >> Salut à tous, >> >> Est-il possible de définir les champs d'une formulation dans un >> fichier extérieur à laa formulation? On pourrait ainsi utiliser les >> mêmes champs pour plusieurs formulation... >> >> Merci! >> >> Martin. >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> Metil-lmtpp mailing list >> Met...@li... >> https://lists.sourceforge.net/lists/listinfo/metil-lmtpp >> > > > > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp ------------------------------------------------------------------------ Felipe Bordeu Weldt Doctorant - 3° année (3° year PhD student) ------------------------------------------------------------------------ Tél : 01 47 40 22 26 Mob : 06 32 42 60 02 LMT-Cachan (ENS Cachan/CNRS/UPMC/PRES UniverSud Paris) 61, av. du Président Wilson F-94230 Cachan France ------------------------------------------------------------------------ |
From: <gou...@lm...> - 2009-12-13 15:49:01
|
Salut, Ca m'intéresse également. J'ai beaucoup de fichiers de formulations avec des champs communs. Kk Martin Genet <mar...@lm...> a écrit : > Salut à tous, > > Est-il possible de définir les champs d'une formulation dans un > fichier extérieur à laa formulation? On pourrait ainsi utiliser les > mêmes champs pour plusieurs formulation... > > Merci! > > Martin. > > ------------------------------------------------------------------------------ > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > _______________________________________________ > Metil-lmtpp mailing list > Met...@li... > https://lists.sourceforge.net/lists/listinfo/metil-lmtpp > |
From: Martin G. <mar...@lm...> - 2009-12-13 12:46:26
|
Salut à tous, Est-il possible de définir les champs d'une formulation dans un fichier extérieur à laa formulation? On pourrait ainsi utiliser les mêmes champs pour plusieurs formulation... Merci! Martin. |