dolfin team mailing list archive

[Johannes Ring <johannr@xxxxxxxxx>]

On Tue, Feb 16, 2010 at 4:44 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>
>
> Anders Logg wrote:
>> On Tue, Feb 16, 2010 at 03:38:18PM +0000, Garth N. Wells wrote:
>>>
>>> Anders Logg wrote:
>>>> On Tue, Feb 16, 2010 at 04:29:24PM +0100, Anders Logg wrote:
>>>>> On Tue, Feb 16, 2010 at 01:23:33PM +0100, Johannes Ring wrote:
>>>>>> On Tue, Feb 16, 2010 at 12:49 PM, Harish Narayanan
>>>>>> <harish.mlists@xxxxxxxxx> wrote:
>>>>>>> On 2/16/10 10:27 AM, Johannes Ring wrote:
>>>>>>>> On Tue, Feb 16, 2010 at 10:37 AM, Harish Narayanan
>>>>>>>> <harish.mlists@xxxxxxxxx> wrote:
>>>>>>>>> On 2/16/10 9:06 AM, Garth N. Wells wrote:
>>>>>>>>>> Anders Logg wrote:
>>>>>>>>>>> On Tue, Feb 16, 2010 at 08:42:55AM +0000, Garth N. Wells wrote:
>>>>>>>>>>>> Anders Logg wrote:
>>>>>>>>>>>>> On Tue, Feb 16, 2010 at 09:09:31AM +0100, Johannes Ring wrote:
>>>>>>>>>>>>>> On Mon, Feb 15, 2010 at 6:06 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>> On Mon, Feb 15, 2010 at 03:49:05PM +0100, Anders Logg wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   UFL    0.5.2
>>>>>>>>>>>>>>>>>>>>>>   FErari 0.2.0
>>>>>>>>>>>>>>>>>>>>>>   FFC    0.9.1
>>>>>>>>>>>>>>> Now released.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   Instant 0.9.8: Why is the buildbot failing?
>>>>>>>>>>>>>>> Now released.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>   DOLFIN  0.9.7: SCOTCH problems
>>>>>>>>>>>>>>> Remains to fix:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  - Drop Hardy support (upgrade buildbots)
>>>>>>>>>>>>>> This might take some time, at least for linux64-exp since I have no
>>>>>>>>>>>>>> control over this. I guess it will be upgraded when Lucid is out.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What should we install on hardy-i386? Karmic or perhaps Lucid?
>>>>>>>>>>>>> I think we should choose the simplest option. I don't know what is
>>>>>>>>>>>>> easiest and fastest, either dropping Hardy support (which requires
>>>>>>>>>>>>> upgrades of buildbots and some extra administration) or adding the
>>>>>>>>>>>>> required #ifdefs for unordered_set/set. Garth?
>>>>>>>>>>>>>
>>>>>>>>>>>> I don't want to add ifdefs (it actually involves more than just that).
>>>>>>>>>>>> Harish told me yesterday that he wasn't using the standard OSX gcc (his
>>>>>>>>>>>> old version didn't support tr1 well), which means we could probably
>>>>>>>>>>>> switch back to using the tr1 unordered containers and not break Hardy or
>>>>>>>>>>>> standard standard OSX installations.
>>>>>>>>>>>>
>>>>>>>>>>>> I would still suggest that we drop Hardy in the near future, perhaps
>>>>>>>>>>>> once Lucid is out.
>>>>>>>>>>> That seems like a good plan since Lucid is the next LTS release.
>>>>>>>>>>>
>>>>>>>>>>> Do you know which #ifdefs to add so we can get the buildbot green?
>>>>>>>>>>>
>>>>>>>>>> No ifdefs. Just change
>>>>>>>>>>
>>>>>>>>>>   boost::unordered_set -> std::tr1::unordered_set
>>>>>>>>>>   boost::unordered_map -> std::tr1::unordered_map
>>>>>>>>>>
>>>>>>>>>> and the relevant includes.
>>>>>>>>> This should work, except it might break the mac buildbot. While I wasn't
>>>>>>>>> using the most recent OS X or gcc, I think I was in line with the mac
>>>>>>>>> buildbot.
>>>>>>>>>
>>>>>>>>> Johannes, what does the buildbot run? Leopard or Snow Leopard, and what
>>>>>>>>> gcc does it use?
>>>>>>>> I think it was Leopard and gcc 4.3 from fink. However, the mac
>>>>>>>> buildbot has been offline for some weeks now. We have bought a new
>>>>>>>> imac to be used as a dedicated mac buildbot but I haven't started to
>>>>>>>> install anything on it yet. I'm not sure if we should go for fink or
>>>>>>>> macports. Any recommendations?
>>>>>>> I suggest MacPorts. It is a bit more unstable than fink, but it allows
>>>>>>> for greater control and has a very recent collection of packages.
>>>>>> Thanks, I will look at MacPorts when I setup the new buildbot.
>>>>>>
>>>>>> Johannes
>>>>> So is the conclusion that std::tr1::unordered_set will work with
>>>>>
>>>>>   1. Modern operating systems
>>>>>   2. Ubuntu Hardy
>>>>>   3. New Mac versions (which is what we will run on the buildbot)
>>>>>
>>>>> ?
>>>>>
>>>>> If so I (or someone else) can switch to std::tr1::unordered_set.
>>>> And the scotch/parmetis include thing needs to be fixed. Garth?
>>>>
>>> I can take a look tonight, although I haven't followed closely what the
>>> problem is.
>>
>> Great. There seems to be a conflict between two versions of
>> parmetis.h, the ParMETIS one and another installed by SCOTCH.
>>
>> I think the solution is to add a scotch/ prefix in the #include
>> and modify the include path accordingly so it doesn't pick up
>> parmetis.h from SCOTCH when the real one is needed.
>>
>
> How can I reproduce the problem? I don't see it on my machine. Sounds
> strange that SCOTCH includes parmetis.h. Is it the compatibility
> functions that SCOTCH provides that cause the problem?

This is how I build SCOTCH and PT-SCOTCH on the buildbot:

  wget http://gforge.inria.fr/frs/download.php/23390/scotch_5.1.7.tar.gz
  tar zxf scotch_5.1.7.tar.gz
  cd scotch_5.1/src
  ln -s Make.inc/Makefile.inc.i686_pc_linux2 Makefile.inc
  sed -i "/^CCD/s/gcc/mpicc/g" Makefile.in
  sed -i "/^CFLAGS/s/= /= -fPIC /g" Makefile.inc
  make
  make ptscotch
  cd ..
  export SCOTCH_DIR=$PWD

Then I have

  ls $SCOTCH_DIR/include
  metis.h  parmetis.h  ptscotchf.h  ptscotch.h  scotchf.h  scotch.h

But it seems that if I do "make install" it won't copy metis.h and
parmetis.h to $prefix/include so I guess that is the solution.

Johannes