dolfin team mailing list archive

[Kent-Andre Mardal <kent-and@xxxxxxxxx>]

On 3 February 2011 18:42, Johannes Ring <johannr@xxxxxxxxx> 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.
>
> Johannes
>
> _


 I mostly use Trilinos ...

Kent