[Dune-devel] dune-common update seems to cause error in my ParMetis routine

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Fri Jan 22 16:20:39 CET 2016 

> Am 22.01.2016 um 15:52 schrieb Aleksejs Fomins <aleksejs.fomins at lspr.ch>:
> 
> Compiler is GCC 5.2. Have been using it for like half a year now
> 
> I suppose that the easiest way to inject would be sth like
> 
> namespace Dune {
>  #include <parmetis.h>
> 
>  …
> }

That cannot work - *never* include a file while a namespace is open. Apart from that, it really doesn’t
make sense because parmetis is a C library and has to be included extern "C“  anyway, which renders
any namespace shenanigans moot…

Did you test whether that commit really introduced the problem? The typename alias real_t already existed
before that commit.

Steffen

> 
> However I have explicitly checked that this is not the case. If anybody has ideas of what else could have gone wrong for this injection to happen, ideas are much appreciated.
> 
> I will search some more and get back to you.
> 
> Aleksejs
> 
> 
> 
> On 22.01.2016 15:14, Christian Engwer wrote:
>> On Fri, Jan 22, 2016 at 02:56:30PM +0100, Aleksejs Fomins wrote:
>>> Dear Christian,
>>> 
>>> Ok, the celebration was a little too soon. Now the previous error is gone and I get the same error in Metis, namely
>>> 
>>> -----------------------------------------------------------------------------------------------------------------------
>>> /opt/extlib/parmetis/4.0.3/openmpi/1.10.0/gcc/5.2.0/include/metis.h:187:34: error: reference to ‘real_t’ is ambiguous
>>>                   idx_t *nparts, real_t *tpwgts, real_t *ubvec, idx_t *options,
>>>                                  ^
>>> /opt/extlib/parmetis/4.0.3/openmpi/1.10.0/gcc/5.2.0/include/metis.h:120:17: note: candidates are: typedef float real_t
>>>   typedef float real_t;
>>>                 ^
>>> In file included from /home/fomins/gitwork/hades-lspr-ag/dune-common/dune/common/fvector.hh:15:0,
>>>                 from /home/fomins/gitwork/hades-lspr-ag/dune-common/dune/common/fmatrix.hh:13,
>>>                 from /home/fomins/gitwork/hades-lspr-ag/hades/stdincl/hadestypes.hh:33,
>>>                 from /home/fomins/gitwork/hades-lspr-ag/hades/hadesx/3d/dg/fd/hades3ddgfdx.hh:39,
>>>                 from /home/fomins/gitwork/hades-lspr-ag/hades/hadesx/3d/dg/fd/hades3ddgfdx.cc:17:
>>> /home/fomins/gitwork/hades-lspr-ag/dune-common/dune/common/typetraits.hh:565:55: note:                 template<class Type> using real_t = typename Dune::FieldTraits::real_type
>>>   using real_t = typename FieldTraits<Type>::real_type;
>>> -----------------------------------------------------------------------------------------------------------------------
>>> 
>>> Any suggestions?
>> 
>> My suggestion is that you either have a broken compiler or broken
>> code. As dune puts the real_t into namespace Dune it should not
>> collide. As it obviously does, either your compiler does something
>> wrong (which one are you using?) or you somehow inject the metis
>> typedef into the Dune namespace.
>> 
>> Christian
>> 
>>> Regards,
>>> Aleksejs
>>> 
>>> On 22.01.2016 13:45, Christian Engwer wrote:
>>>> On Fri, Jan 22, 2016 at 01:41:43PM +0100, Aleksejs Fomins wrote:
>>>>> Dear Christian,
>>>>> 
>>>>> Thank you for your advice. After a brief look at the commit tree, I have found a commit
>>>>> 
>>>>> 93f16b5ecdb60704cc9c369a9ee14f24708c506a
>>>>> 
>>>>> by Lars Lubkoll as of 2015-12-07 16:08:42, which adds the line
>>>>> 
>>>>> using real_t = typename FieldTraits<Type>::real_type;
>>>>> 
>>>>> to namespace Dune.
>>>>> 
>>>>> 
>>>>> Since curvilinear grid is inside namespace Dune, I suppose that including parmetis.h creates a name clash.
>>>>> 
>>>>> 
>>>>> Do you think that
>>>>> 
>>>>> namespace MyParmetis{
>>>>>  #include <parmetis.h>
>>>>> }
>>>>> 
>>>>> would be a good solution?
>>>> 
>>>> No! This will craete completely different names and linking will
>>>> fail. You will have to use proper scoping. ::real_t will refer to the
>>>> global name and not the one in the Dune namespace.
>>>> 
>>>> Christian
>>>> 
>>>>> Best,
>>>>> Aleksejs
>>>>> 
>>>>> 
>>>>> On 22.01.2016 13:14, Christian Engwer wrote:
>>>>>> Easiest wuld be a git bisect to identify te commit that caused the
>>>>>> problems.
>>>>>> 
>>>>>> Alternatively you can look at the preprocessor output.
>>>>>> 
>>>>>> Christian
>>>>>> 
>>>>>> On Fri, Jan 22, 2016 at 12:13:58PM +0100, Aleksejs Fomins wrote:
>>>>>>> Dear Markus,
>>>>>>> 
>>>>>>> real_t is a datatype that is essentially float or double, as defined in <parmetis.h>, which is included in the file in question.
>>>>>>> 
>>>>>>> In fact, the error disappears if I manually type
>>>>>>> 
>>>>>>> typedef float real_t;
>>>>>>> 
>>>>>>> inside of my code. However, this same line is already written in parmetis.h, and the compiler clearly sees this file, because it does not complain about other parmetis functions I use. What puzzles me is that the code compiles no problem with previous version of dune-common.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Aleksejs
>>>>>>> 
>>>>>>> 
>>>>>>> On 22.01.2016 12:07, Markus Blatt wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> On Fri, Jan 22, 2016 at 11:55:31AM +0100, Aleksejs Fomins wrote:
>>>>>>>>> My Parmetis code, which used to compile before, includes the following lines:
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> #if PARMETIS_MAJOR_VERSION < 4
>>>>>>>>>      typedef idxtype idx_t;
>>>>>>>>>      typedef float real_t;
>>>>>>>>> #endif
>>>>>>>>> 
>>>>>>>>> std::vector<real_t> tpwgts(ncon*nparts, 1./nparts);
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> With the latest pull of dune-common, I get the following error
>>>>>>>>> 
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> /home/fomins/gitwork/hades-lspr-ag/dune-curvilineargrid/dune/curvilineargrid/io/file/curvilineargmshreader.hh:1124:25: error: type/value mismatch at argument 1 in template parameter list for ‘template<class _Tp, class _Alloc> class std::vector’
>>>>>>>>>       std::vector<real_t> tpwgts(ncon*nparts, 1./nparts);
>>>>>>>>>                         ^
>>>>>>>>> /home/fomins/gitwork/hades-lspr-ag/dune-curvilineargrid/dune/curvilineargrid/io/file/curvilineargmshreader.hh:1124:25: note:   expected a type, got ‘real_t’
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> 
>>>>>>>>> Would you be so kind as to suggest what caused this error and how to correct it?
>>>>>>>> 
>>>>>>>> The error message is pretty clear: The compiler does not know real_t
>>>>>>>> for whatever reason. What is it supposed to be?
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> 
>>>>>>>> Markus
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Dune-devel mailing list
>>>>>>> Dune-devel at dune-project.org
>>>>>>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20160122/12bcd38f/attachment.sig>

More information about the Dune-devel mailing list