dorsal team mailing list archive

[Johannes Ring <johannr@xxxxxxxxx>]

On Wed, Sep 8, 2010 at 11:28 PM, Paul Barbone <barbone@xxxxxx> wrote:
>  On 9/8/10 4:06 PM, Anders Logg wrote:
>>
>> On Wed, Sep 08, 2010 at 04:01:12PM -0400, Paul Barbone wrote:
>>>
>>>  On 9/8/10 2:58 PM, Anders Logg wrote:
>>>>
>>>> On Wed, Sep 08, 2010 at 02:49:01PM -0400, Paul Barbone wrote:
>>>>>
>>>>>  On 9/7/10 2:15 AM, Anders Logg wrote:
>>>>>>
>>>>>> On Mon, Sep 06, 2010 at 07:14:21PM -0400, Paul Barbone wrote:
>>>>>>>
>>>>>>>  On 9/6/10 6:32 PM, Anders Logg wrote:
>>>>>>>>
>>>>>>>> Did you install PETSc and SLEPc yourself or did you let Dorsal build
>>>>>>>> them?
>>>>>>>
>>>>>>> I let dorsal build them.
>>>>>>>>
>>>>>>>> Did you have any old versions of any of the libraries on your
>>>>>>>> system?
>>>>>>>
>>>>>>> Yes, but these were in different directories, and incidentally
>>>>>>> installed from an older dorsal build.   I tried to keep things
>>>>>>> separate, but there is some overlap between the installations.
>>>>>>> They use the same python, for example, but the PETSc and SLEPc are
>>>>>>> distinct.
>>>>>>
>>>>>> Could you try locating all those libraries and (at least temporarily)
>>>>>> rename or move them to a location where they can't be found?
>>>>>>
>>>>>> Then clean out the Dorsal build and start with a clean installation.
>>>>>>
>>>>>> Our scripts should be able to find the correct versions but the
>>>>>> configure scripts need some more work.
>>>>>>
>>>>> Ok.  I reinstalled python, etc, via macports, deleted the old FEniCS
>>>>> directory, and installed completely new.  I eventually got precisely
>>>>> the same behavior.
>>>>
>>>> Very strange. It works fine on my Snow Leopard (including SCOTCH). I
>>>> haven't done anything special. Your hope is that either someone else
>>>> has the same problem and knows how to fix it, or you find out what the
>>>> problem is yourself.
>>>>
>>>> It is not that difficult to add some debugging to the DOLFIN CMake
>>>> configure scripts. They are located in the cmake/modules/ directory
>>>> and named FindPETSc.cmake etc. Let us what you find out.
>>>>
>>> Thanks.  That's helpful.  Where is PETSC_ARCH specified?  It changes
>>> from its definition in the  foo.platform file.
>>
>> It shouldn't be changed by Dorsal anywhere along the way. There is
>> some code in FindPETSc.cmake that tries to figure out PETSC_DIR. Look
>> for this passage:
>>
>>   # Try to figure out PETSC_ARCH if not set
>>   if (PETSC_DIR AND NOT PETSC_ARCH)
>>
>> You can start by printing out the value of PETSC_ARCH prior to this
>> and see if it looks ok:
>>
>>   message("DEBUG PETSC_ARCH = ${PETSC_ARCH}")
>>
>> --
>> Anders
>
> It gives PETSC_ARCH=darwin10.0.0-cxx-opt at this point, regardless of what
> this variable is set to in the *.platform file.   In my older installation,
> this variable was darwin9.2.0...  This is a difference, but I doubt,
> frankly, that it's important.
>
> What I really don't understand and what I think is important is this:
>
> Linking CXX shared library libdolfin.dylib
> Undefined symbols:
>  "_METIS_mCPartGraphRecursive2", referenced from:
>      _ParMETIS_V3_PartKway in libparmetis.a(kmetis.o)
>      _PartitionSmallGraph__ in libparmetis.a(weird.o)
>      _Mc_InitPartition_RB__ in libparmetis.a(initpart.o)
>      _Mc_InitPartition_RB__ in libparmetis.a(initpart.o)
>      _Balance_Partition__ in libparmetis.a(initbalance.o)
>      _Balance_Partition__ in libparmetis.a(initbalance.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
> This is extracted from the dolfin build_log file, and also prints to the
> screen just before death.

The problem is probably that DOLFIN picks up the METIS library that
comes with MacPorts (/opt/local/lib/libmetis.dylib) instead of the one
from ParMETIS that Dorsal installs and PETSc is built with
($INSTALL_PATH/lib/libmetis.a). I have solved this on the buildbot by
specifying -DMETIS_LIBRARY=$INSTALL_PATH/lib/libmetis.a when
configuring DOLFIN.

Johannes