On 03/02/11 18:13, Johannes Ring wrote: > On Thu, Feb 3, 2011 at 6:48 PM, Garth N. Wells <[email protected]> wrote: >> >> >> On 03/02/11 17:42, Johannes Ring 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. >>> >> >> 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
