From: Roy S. <ro...@st...> - 2008-06-16 18:50:26
|
Vikram just ran into this ugly problem while trying to get Ben's code up to speed with SVN libMesh. Here's a minimal test case: test.C: extern "C" { #include "petscoptions.h" } #include <tr1/unordered_map> That's it. Trying to compile this breaks in the CFDLab in all sorts of fun ways. We can work around it for now by turning off TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems over in ICES too), but I'm curious if anyone else can replicate this. Is it a quirk of our particular (somewhat out of date) PETSc and gcc versions, or is there some conflict between the PETSc namespace and the new C++ hash map standard? --- Roy |
From: Derek G. <fri...@gm...> - 2008-06-16 19:20:38
|
No problems here on OSX with gcc 4.0.1. Nor do I have a problem on our cluster here running Suse with gcc 4.1.2. Derek On Jun 16, 2008, at 12:50 PM, Roy Stogner wrote: > > Vikram just ran into this ugly problem while trying to get Ben's code > up to speed with SVN libMesh. Here's a minimal test case: > > > test.C: > > extern "C" { > #include "petscoptions.h" > } > #include <tr1/unordered_map> > > > > That's it. Trying to compile this breaks in the CFDLab in all sorts > of fun ways. We can work around it for now by turning off > TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems > over in ICES too), but I'm curious if anyone else can replicate this. > Is it a quirk of our particular (somewhat out of date) PETSc and gcc > versions, or is there some conflict between the PETSc namespace and > the new C++ hash map standard? > --- > Roy > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Benjamin K. <ben...@na...> - 2008-06-16 20:21:28
|
No issues under CentOS-5.1 with gcc-4.1.1. On 6/16/08 2:20 PM, "Derek Gaston" <fri...@gm...> wrote: > No problems here on OSX with gcc 4.0.1. Nor do I have a problem on > our cluster here running Suse with gcc 4.1.2. > > Derek > > > On Jun 16, 2008, at 12:50 PM, Roy Stogner wrote: > >> >> Vikram just ran into this ugly problem while trying to get Ben's code >> up to speed with SVN libMesh. Here's a minimal test case: >> >> >> test.C: >> >> extern "C" { >> #include "petscoptions.h" >> } >> #include <tr1/unordered_map> >> >> >> >> That's it. Trying to compile this breaks in the CFDLab in all sorts >> of fun ways. We can work around it for now by turning off >> TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems >> over in ICES too), but I'm curious if anyone else can replicate this. >> Is it a quirk of our particular (somewhat out of date) PETSc and gcc >> versions, or is there some conflict between the PETSc namespace and >> the new C++ hash map standard? >> --- >> Roy >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: John P. <jwp...@gm...> - 2008-06-16 20:35:10
|
On Mon, Jun 16, 2008 at 1:50 PM, Roy Stogner <ro...@st...> wrote: > > Vikram just ran into this ugly problem while trying to get Ben's code > up to speed with SVN libMesh. Here's a minimal test case: > > > test.C: > > extern "C" { > #include "petscoptions.h" > } > #include <tr1/unordered_map> > > > > That's it. Trying to compile this breaks in the CFDLab in all sorts > of fun ways. We can work around it for now by turning off > TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems > over in ICES too), but I'm curious if anyone else can replicate this. > Is it a quirk of our particular (somewhat out of date) PETSc and gcc > versions, or is there some conflict between the PETSc namespace and > the new C++ hash map standard? I think the problem is with Petsc. If you include "petsc.h" before petscoptions.h I think it will go away? -- John |
From: John P. <jwp...@gm...> - 2008-06-16 20:36:00
|
On Mon, Jun 16, 2008 at 3:35 PM, John Peterson <jwp...@gm...> wrote: > On Mon, Jun 16, 2008 at 1:50 PM, Roy Stogner <ro...@st...> wrote: >> >> Vikram just ran into this ugly problem while trying to get Ben's code >> up to speed with SVN libMesh. Here's a minimal test case: >> >> >> test.C: >> >> extern "C" { >> #include "petscoptions.h" >> } >> #include <tr1/unordered_map> >> >> >> >> That's it. Trying to compile this breaks in the CFDLab in all sorts >> of fun ways. We can work around it for now by turning off >> TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems >> over in ICES too), but I'm curious if anyone else can replicate this. >> Is it a quirk of our particular (somewhat out of date) PETSc and gcc >> versions, or is there some conflict between the PETSc namespace and >> the new C++ hash map standard? > > I think the problem is with Petsc. If you include "petsc.h" before > petscoptions.h I think it will go away? Crap, nevermind. If you include tr1/unordered_map *before* petscoptions.h it goes away. -- John |
From: Roy S. <ro...@st...> - 2008-06-16 20:44:03
|
On Mon, 16 Jun 2008, John Peterson wrote: > Crap, nevermind. If you include tr1/unordered_map *before* > petscoptions.h it goes away. Thanks; that's exactly the fix we needed. --- Roy |
From: John P. <jwp...@gm...> - 2008-06-16 20:49:50
|
On Mon, Jun 16, 2008 at 3:35 PM, John Peterson <jwp...@gm...> wrote: > On Mon, Jun 16, 2008 at 3:35 PM, John Peterson <jwp...@gm...> wrote: >> On Mon, Jun 16, 2008 at 1:50 PM, Roy Stogner <ro...@st...> wrote: >>> >>> Vikram just ran into this ugly problem while trying to get Ben's code >>> up to speed with SVN libMesh. Here's a minimal test case: >>> >>> >>> test.C: >>> >>> extern "C" { >>> #include "petscoptions.h" >>> } >>> #include <tr1/unordered_map> >>> >>> >>> >>> That's it. Trying to compile this breaks in the CFDLab in all sorts >>> of fun ways. We can work around it for now by turning off >>> TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems >>> over in ICES too), but I'm curious if anyone else can replicate this. >>> Is it a quirk of our particular (somewhat out of date) PETSc and gcc >>> versions, or is there some conflict between the PETSc namespace and >>> the new C++ hash map standard? >> >> I think the problem is with Petsc. If you include "petsc.h" before >> petscoptions.h I think it will go away? > > Crap, nevermind. If you include tr1/unordered_map *before* > petscoptions.h it goes away. > OK, there's a line in /usr/local/petsc/petsc-2.3.1/include/petscerror.h, line 261 -- extern PetscErrorCode __gierr; the petsc folks define __gierr and then the gcc people are apparently trying to use this same __gierr variable somewhere (I can't see exactly where at the moment but the error message alludes to it). I think this is petsc's fault because you are never supposed to use variables starting with double underscore . By adding this option to the compile line -DPETSC_SKIP_UNDERSCORE_CHKERR the compiler error seems to have gone away. I'm not sure what this does to the behavior of the library, though. -- John |
From: John P. <jwp...@gm...> - 2008-06-16 20:55:55
|
On Mon, Jun 16, 2008 at 3:49 PM, John Peterson <jwp...@gm...> wrote: > On Mon, Jun 16, 2008 at 3:35 PM, John Peterson <jwp...@gm...> wrote: >> On Mon, Jun 16, 2008 at 3:35 PM, John Peterson <jwp...@gm...> wrote: >>> On Mon, Jun 16, 2008 at 1:50 PM, Roy Stogner <ro...@st...> wrote: >>>> >>>> Vikram just ran into this ugly problem while trying to get Ben's code >>>> up to speed with SVN libMesh. Here's a minimal test case: >>>> >>>> >>>> test.C: >>>> >>>> extern "C" { >>>> #include "petscoptions.h" >>>> } >>>> #include <tr1/unordered_map> >>>> >>>> >>>> >>>> That's it. Trying to compile this breaks in the CFDLab in all sorts >>>> of fun ways. We can work around it for now by turning off >>>> TR1_UNORDERED_MAP support (which IIRC was giving Andrea some problems >>>> over in ICES too), but I'm curious if anyone else can replicate this. >>>> Is it a quirk of our particular (somewhat out of date) PETSc and gcc >>>> versions, or is there some conflict between the PETSc namespace and >>>> the new C++ hash map standard? >>> >>> I think the problem is with Petsc. If you include "petsc.h" before >>> petscoptions.h I think it will go away? >> >> Crap, nevermind. If you include tr1/unordered_map *before* >> petscoptions.h it goes away. >> > > OK, there's a line in > /usr/local/petsc/petsc-2.3.1/include/petscerror.h, line 261 -- > > extern PetscErrorCode __gierr; > > the petsc folks define __gierr and then the gcc people are apparently > trying to use this same __gierr variable somewhere (I can't see > exactly where at the moment but the error message alludes to it). I > think this is petsc's fault because you are never supposed to use > variables starting with double underscore . > > By adding this option to the compile line > > -DPETSC_SKIP_UNDERSCORE_CHKERR > > the compiler error seems to have gone away. I'm not sure what this > does to the behavior of the library, though. Oh wait....it's even weirder. Check out /usr/include/c++/4.1.2/tr1/functional_iterate.h, line 398: _Placeholder<_GLIBCXX_NUM_ARGS> _GLIBCXX_JOIN(_,_GLIBCXX_NUM_ARGS); They actually use a single underscore as an argument to _GLIBCXX_JOIN, whatever that is. Now look again at petscerror.h, line 262: #define _ __gierr = They are actually redefining "underscore." I have no clue why but that can't be good programming practice. -- John |
From: Benjamin K. <ben...@na...> - 2008-06-16 21:04:04
|
> They are actually redefining "underscore." I have no clue why but > that can't be good programming practice. This is invigorating me to finish the Trilinos integration. It will be nice to have a functional alternative to solve linear systems on parallel platforms. Along these lines, Derek, any reason we are gonna use Epetra_Vector vs. Epetra_FEVector? Do we want to use the FEVector version instead as it allows inserting into nonlocal entries, something we need to do?? -Ben |
From: Derek G. <fri...@gm...> - 2008-06-16 21:14:26
|
Well... the trouble is that an Epetra_FEVector is _not_ an Epetra_Vector! (in the OO sense... as in it doesn't inherit from Epetra_Vector)... so I'm not sure if we'll run into trouble later on when we try to pass an Epetra_FEVector to something like NOX. One would hope that NOX expects an Epetra_MultiVector (which both Vector and FEVector inherit from) but I don't know for sure. I've personally used Epetra_FEVector in a little test code I wrote... and it works as advertised. It certainly makes things pretty simple for our normal use case. It has some oddities though... like it doesn't have some of the operations on it that Epetra_Vector does... and some that it does have expect the arguments in a different order! Very weird. It seems to me that FEVector is basically mothballed, I can't see that there's been any work on it in a while... so maybe it's even somewhat unsupported. I kind of figured that we would use Epetra_Vector since that kind of matched with Petsc vectors (or does it?) and I was under the impression that we'd already solved the problem of adding into non- local entries for Petsc. If that's not the case (ie, we're relying on Petsc to do off processor adding for us) then by all means let's use FEVector... Hope that helps... Derek On Jun 16, 2008, at 3:03 PM, Benjamin Kirk wrote: >> They are actually redefining "underscore." I have no clue why but >> that can't be good programming practice. > > This is invigorating me to finish the Trilinos integration. It will > be nice > to have a functional alternative to solve linear systems on parallel > platforms. > > Along these lines, Derek, any reason we are gonna use Epetra_Vector > vs. > Epetra_FEVector? Do we want to use the FEVector version instead as it > allows inserting into nonlocal entries, something we need to do?? > > -Ben > |
From: Benjamin K. <ben...@na...> - 2008-06-16 21:24:21
|
> If that's not the case (ie, we're relying on > Petsc to do off processor adding for us) then by all means let's use > FEVector... Yeah, we expect that PETSc does that for us. > Hope that helps... It does. This is a very common usage -- summing local contribution to shared, remote entries, so I am surprised that only Epetra_FEVector supports it. It seems to me Epetra_FEVector would be better derived from Epetra_Vector? Not sure, perhaps I should post the question to the list. I think I've got the matrix interface settled out, and next will be to finish the linear solver and try solving a problem. I am sure the question will pop up at that point. -Ben |
From: Derek G. <fri...@gm...> - 2008-06-16 21:32:39
|
On Jun 16, 2008, at 3:24 PM, Benjamin Kirk wrote: > It does. This is a very common usage -- summing local contribution to > shared, remote entries, so I am surprised that only Epetra_FEVector > supports > it. It seems to me Epetra_FEVector would be better derived from > Epetra_Vector? I absolutely agree... and couldn't believe my eyes when I saw the inheritance chart in their doxygen docs... it doesn't make any sense at all. If you read the docs it even describes FEVector as an extension of Vector! My guess: some intern just hacked it in there... Derek |
From: Derek G. <fri...@gm...> - 2008-09-15 11:15:25
|
On Mon, Jun 16, 2008 at 3:26 PM, Derek Gaston <fri...@gm...> wrote: > On Jun 16, 2008, at 3:24 PM, Benjamin Kirk wrote: > > It does. This is a very common usage -- summing local contribution to > shared, remote entries, so I am surprised that only Epetra_FEVector > supports > it. It seems to me Epetra_FEVector would be better derived from > Epetra_Vector? > > > I absolutely agree... and couldn't believe my eyes when I saw the > inheritance chart in their doxygen docs... it doesn't make any sense at all. > If you read the docs it even describes FEVector as an extension of Vector! > My guess: some intern just hacked it in there... > Ben... so this whole Epetra_FEVector / Epetra_Vector junk _did_ end up coming back around to bite us in the ass. It turns out that the interface for NOX expects Epetra_Vectors... not Epetra_MultiVectors nor Epetra_FEVectors... but specifically Epetra_Vectors. What a pain in the ass. Over the last couple of weeks I tried a couple of different ideas to get around this... multiple-inheritance, whole-sale copying of FEVector into libMesh and make it inherit from the right place, etc... but it turns out that the specific way that the NOX interface uses Epetra_Vectors absolutely _requires_ that your own code uses Epetra_Vector. The reason is that it doesn't pass you back your original Epetra_Vector... instead it passes you a "new" one that has a "view" into your original data (so no data copying is going on but it's not physically this same object). This behavior means that you can't dynamically cast the Epetra_Vectors that NOX gives you back into something that looks like an Epetra_FEVector... even if you went through all the work to make the inheritance tree look right.... sigh. So... what to do? Well, I looked at the functionality that Epetra_FEVector was giving us over just a regular Epetra_Vector... and it's really not much... mostly just a little bit of book-keeping for the parallel summing. So I decided to lift all of that functionality and just place it into the libMesh::EpetraVector object directly... and instead of working with an Epetra_FEVector... we would work with an Epetra_Vector and just do all the manipulations for the parallel summing ourselves... external to the Epetra_Vector object. I just checked in my first go at making this work. I haven't completely tested it yet though... I'll do more of that over the next couple of days as I'm finishing up fleshing out the NOX interface. Really though... what the hell is the point of doing an "object-oriented" C++ numerical library if you don't use polymorphism correctly? I mean, just take a look through Epetra objects... notice anything missing from a polymorphism standpoint? Yep... there's absolutely _no_ virtual functions!!!!!! _This_ is why every object that inherits from something has to re-expose it's own functions with slightly different signatures to do (almost) the same thing as it's base class! _This_ is also why Epetra_FEVector is pretty screwed up. In reality they should have just been able to override the virtuals in MultiVector in order to handle the off-processor elements... but instead they had to hack around it... sigh. My guess for this rediculousness: optimization. My bet is that back when they started the OO version of Epetra everyone was still scared about how much time virtual table lookups cost... and so they decreed that there will be no virtuals. I'd really like to see the timing studies on a modern computer that would justify this kind of optimization.... Ok - Rant-off. Derek |
From: Derek G. <fri...@gm...> - 2008-09-16 09:11:05
|
Ok - so I've fixed up EpetraVector... and all is well again. You can now once again use Trilinos to solve linear problems in both serial and parallel... and now it'll be using pure Epetra_Vectors under the hood instead of FEVectors. Now to finish up that NOX integration... Derek On Mon, Sep 15, 2008 at 12:15 PM, Derek Gaston <fri...@gm...> wrote: > On Mon, Jun 16, 2008 at 3:26 PM, Derek Gaston <fri...@gm...> wrote: > >> On Jun 16, 2008, at 3:24 PM, Benjamin Kirk wrote: >> >> It does. This is a very common usage -- summing local contribution to >> shared, remote entries, so I am surprised that only Epetra_FEVector >> supports >> it. It seems to me Epetra_FEVector would be better derived from >> Epetra_Vector? >> >> >> I absolutely agree... and couldn't believe my eyes when I saw the >> inheritance chart in their doxygen docs... it doesn't make any sense at all. >> If you read the docs it even describes FEVector as an extension of Vector! >> My guess: some intern just hacked it in there... >> > > Ben... so this whole Epetra_FEVector / Epetra_Vector junk _did_ end up > coming back around to bite us in the ass. > > It turns out that the interface for NOX expects Epetra_Vectors... not > Epetra_MultiVectors nor Epetra_FEVectors... but specifically > Epetra_Vectors. What a pain in the ass. > > Over the last couple of weeks I tried a couple of different ideas to get > around this... multiple-inheritance, whole-sale copying of FEVector into > libMesh and make it inherit from the right place, etc... but it turns out > that the specific way that the NOX interface uses Epetra_Vectors absolutely > _requires_ that your own code uses Epetra_Vector. The reason is that it > doesn't pass you back your original Epetra_Vector... instead it passes you a > "new" one that has a "view" into your original data (so no data copying is > going on but it's not physically this same object). This behavior means > that you can't dynamically cast the Epetra_Vectors that NOX gives you back > into something that looks like an Epetra_FEVector... even if you went > through all the work to make the inheritance tree look right.... sigh. > > So... what to do? Well, I looked at the functionality that Epetra_FEVector > was giving us over just a regular Epetra_Vector... and it's really not > much... mostly just a little bit of book-keeping for the parallel summing. > So I decided to lift all of that functionality and just place it into the > libMesh::EpetraVector object directly... and instead of working with an > Epetra_FEVector... we would work with an Epetra_Vector and just do all the > manipulations for the parallel summing ourselves... external to the > Epetra_Vector object. > > I just checked in my first go at making this work. I haven't completely > tested it yet though... I'll do more of that over the next couple of days as > I'm finishing up fleshing out the NOX interface. > > Really though... what the hell is the point of doing an "object-oriented" > C++ numerical library if you don't use polymorphism correctly? I mean, just > take a look through Epetra objects... notice anything missing from a > polymorphism standpoint? Yep... there's absolutely _no_ virtual > functions!!!!!! _This_ is why every object that inherits from something has > to re-expose it's own functions with slightly different signatures to do > (almost) the same thing as it's base class! _This_ is also why > Epetra_FEVector is pretty screwed up. In reality they should have just been > able to override the virtuals in MultiVector in order to handle the > off-processor elements... but instead they had to hack around it... sigh. > > My guess for this rediculousness: optimization. My bet is that back when > they started the OO version of Epetra everyone was still scared about how > much time virtual table lookups cost... and so they decreed that there will > be no virtuals. I'd really like to see the timing studies on a modern > computer that would justify this kind of optimization.... > > Ok - Rant-off. > > Derek > |
From: Roy S. <ro...@st...> - 2008-06-16 21:10:24
|
On Mon, 16 Jun 2008, John Peterson wrote: >> the petsc folks define __gierr and then the gcc people are apparently >> trying to use this same __gierr variable somewhere (I can't see >> exactly where at the moment but the error message alludes to it). I >> think this is petsc's fault because you are never supposed to use >> variables starting with double underscore . Yes; I think it's actually in the C and C++ standards that variables beginning with __ are reserved for the compiler/implementation. Your "include the C++ headers before PETSc headers" workaround seems to be good enough for us for now, but I'll point the problem out to the PETSc bug report address. It shouldn't be too hard for them to switch to "petsc_gierr" or some such symbol with less potential for naming conflicts. > /usr/include/c++/4.1.2/tr1/functional_iterate.h, line 398: > > _Placeholder<_GLIBCXX_NUM_ARGS> _GLIBCXX_JOIN(_,_GLIBCXX_NUM_ARGS); > > They actually use a single underscore as an argument to _GLIBCXX_JOIN, > whatever that is. Now look again at petscerror.h, line 262: > > #define _ __gierr = > > They are actually redefining "underscore." I have no clue why but > that can't be good programming practice. I don't think this one is actually prohibited by the language standards, but that's probably just because they didn't want to tie the hands of the International Obfuscated C Code Contest. --- Roy |