dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

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.

Johan



> Garth
> 
> > Johan
> > 
> >> Johannes
> >> 
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~dolfin
> >> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~dolfin
> >> More help   : https://help.launchpad.net/ListHelp
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp