On 3 February 2011 18:42, Johannes Ring <[email protected]> wrote: > On Wed, Feb 2, 2011 at 7:18 PM, Johan Hake <[email protected]> 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 <[email protected]> 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
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
