Thread: [Metil-lmtpp] Demande d'autorisation de suppression d'une variable globale
Status: Pre-Alpha
Brought to you by:
hugo_lec
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: 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: 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: 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: 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-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. |