dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 03/02/11 18:13, Johannes Ring wrote:
> On Thu, Feb 3, 2011 at 6:48 PM, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>>
>>
>> On 03/02/11 17:42, Johannes Ring wrote:
>>> On Wed, Feb 2, 2011 at 7:18 PM, Johan Hake <johan.hake@xxxxxxxxx> wrote:
>>>> On Wednesday February 2 2011 07:57:10 Garth N. Wells wrote:
>>>>> On 02/02/11 15:46, Johan Hake wrote:
>>>>>> On Wednesday February 2 2011 02:31:02 Johannes Ring wrote:
>>>>>>> On Wed, Feb 2, 2011 at 12:39 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>>>>>>>> On Tue, Feb 01, 2011 at 11:35:28PM +0000, Garth N. Wells wrote:
>>>>>>>>> On 01/02/11 23:19, Johan Hake wrote:
>>>>>>>>>> On Tuesday February 1 2011 15:14:21 Anders Logg wrote:
>>>>>>>>>>> On Tue, Feb 01, 2011 at 03:12:05PM -0800, Johan Hake wrote:
>>>>>>>>>>>> On Tuesday February 1 2011 14:53:55 Anders Logg wrote:
>>>>>>>>>>>>> Something seems to go wrong with the Hierarchical Python wrappers.
>>>>>>>>>>>>>
>>>>>>>>>>>>> C++ program:
>>>>>>>>>>>>>   UnitSquare mesh(3, 3);
>>>>>>>>>>>>>   mesh._debug();
>>>>>>>>>>>>>
>>>>>>>>>>>>> Output:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Debugging hierarchical object.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   has_parent()    = 0
>>>>>>>>>>>>>   _parent.get()   = 0
>>>>>>>>>>>>>   _parent.count() = 0
>>>>>>>>>>>>>   has_child()     = 0
>>>>>>>>>>>>>   _child.get()    = 0
>>>>>>>>>>>>>   _child.count()  = 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Debugging hierarchical object.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   has_parent()    = 0
>>>>>>>>>>>>>   _parent.get()   = 0
>>>>>>>>>>>>>   _parent.count() = 0
>>>>>>>>>>>>>   has_child()     = 0
>>>>>>>>>>>>>   _child.get()    = 0
>>>>>>>>>>>>>   _child.count()  = 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Python program:
>>>>>>>>>>>>>   mesh = UnitSquare(3, 3)
>>>>>>>>>>>>>   mesh._debug()
>>>>>>>>>>>>>
>>>>>>>>>>>>> Debugging hierarchical object.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   has_parent()    = 0
>>>>>>>>>>>>>   _parent.get()   = 0
>>>>>>>>>>>>>   _parent.count() = 0
>>>>>>>>>>>>>   has_child()     = 0
>>>>>>>>>>>>>   _child.get()    = 0
>>>>>>>>>>>>>   _child.count()  = 0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Debugging hierarchical object.
>>>>>>>>>>>>>
>>>>>>>>>>>>>   has_parent()    = 1
>>>>>>>>>>>>>   _parent.get()   = cbd47290
>>>>>>>>>>>>>   _parent.count() = -878438560
>>>>>>>>>>>>>   has_child()     = 1
>>>>>>>>>>>>>   _child.get()    = cbd47290
>>>>>>>>>>>>>   _child.count()  = -878438560
>>>>>>>>>>>>>
>>>>>>>>>>>>> The first call to Hierarchical::_debug is made from the
>>>>>>>>>>>>> constructor of Hierarchical and is correct in both C++ and
>>>>>>>>>>>>> Python, but then the Python object seems to lose contact with the
>>>>>>>>>>>>> reality.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes quite so...
>>>>>>>>>>>>
>>>>>>>>>>>> I changed locally to swig 2.0 and the problem went away. shared_ptr
>>>>>>>>>>>> support has been rewritten in 2.0. I might be able to hack the
>>>>>>>>>>>> interface of Hierarchical in a similar manner as I did for
>>>>>>>>>>>> Variables. Just implementing the interface again in the C++ layer.
>>>>>>>>>>>>
>>>>>>>>>>>> But I am not sure. The shared_ptr part of the SWIG interface starts
>>>>>>>>>>>> to be quite complex now with supporting SWIG version 1.3.37 to
>>>>>>>>>>>> 1.3.40 and 2.0
>>>>>>>>>>>>
>>>>>>>>>>>> Maybe we should force SWIG 2.0?
>>>>>>>>>>>
>>>>>>>>>>> Is that possible? It's not in Ubuntu yet, or is it?
>>>>>>>>>
>>>>>>>>> It's in 11.04
>>>>>>>>>
>>>>>>>>> Swig is super easy to install.
>>>>>>>>
>>>>>>>> If we can include SWIG installation in Dorsal and Johannes is able to
>>>>>>>> make packages that rely on SWIG 2.0 then we might as well move to 2.0
>>>>>>>> to save us (mainly Johan) a lot of trouble.
>>>>>>>
>>>>>>> I tried to build UFC and DOLFIN in Debian unstable with the swig2.0
>>>>>>> package (same package as in Ubuntu 11.04). One problem is that this
>>>>>>> package does not contain /usr/bin/swig but only /usr/bin/swig2.0. I
>>>>>>> fixed this by setting -DSWIG_EXECUTABLE:FILEPATH=/usr/bin/swig2.0 when
>>>>>>> building UFC and DOLFIN, but running the poisson Python demo failed
>>>>>>> because Instant was unable to find swig. The reason for naming the
>>>>>>> binary "swig2.0" is probably that SWIG 1.3 is still the default in
>>>>>>> Debian (and Ubuntu).
>>>>>>
>>>>>> Ok then it might be difficult. We could maybe add some funcitonality to
>>>>>> instant to define what executable it shold look for?
>>>>>
>>>>> We should definitely have that - DOLFIN should be able to pass the Swig
>>>>> executable name and path. I've already seen that having two versions of
>>>>> Swig installed is problematic.
>>>>
>>>> Ok, then we need some hierachical setting of what swig excecutable it should
>>>> look for. As I am compiling swig from source, which gives me a plain 'swig'
>>>> excecutable I would not like DOLFIN to use this and not swig2.0.
>>>>
>>>> I can see if I can implement this. We can add something like:
>>>>
>>>>  parameters["jit_compilation"]["swig_executable"] = "swig2.0"
>>>>  parameters["jit_compilation"]["swig_version"] = "2.0.0"
>>>>
>>>> If swig2.0 is not found we look for swig. I think we can do this from dolfin
>>>> (using instant). When we have found the correct swig executable we cache it
>>>> and use it when we call instant.
>>>>
>>>> I am not sure how setting the path will work. If we include it I think it
>>>> should be optional. So that just looking in the path after the excecutable
>>>> should be the default option.
>>>
>>> FYI: I just thought of another problem with moving to SWIG 2.0. The
>>> Trilinos package in Debian and Ubuntu is not built with SWIG 2.0. This
>>> means that I must build the DOLFIN package without support for
>>> Trilinos.
>>>
>>
>> I wouldn't bother about this - the Debian/Ubuntu PETSc and Trilinos
>> packages are not great.
> 
> What are the problems with these packages?
> 

They tend to be old and miss a lot of the 3rd party add-ons that are
really good to have in parallel.

The Trilinos package used to built without MPI, but they may have fixed
this.

Garth

>> Also, Trilinos 10.8 will require Swig 2.0.
> 
> OK.
> 
> Johannes