On Friday October 28 2011 10:00:15 Martin Sandve Alnæs wrote:
> Just a few quick comments here:
> 
> cmath is fully standard, which makes it not comparable to boost math for
> these issues.

Ok.
 
> The issue is mainly from python because from C++ there will be a build
> system to handle libraries.

But who tells the build system to provide the library? Should that be a user 
tweaking the local CMakeList.txt. I think it would be nice if UFC provided a 
generic FindUFC.cmake including all dependencies by default, or FFC provided 
such a file (FindSomething.cmake), which then could be problem dependent.

> I think boost math is comparable to boost shared_ptr, in fact they are both
> tr1 and light weight. Configuring one more boost library in ufc would not
> be so bad.

Ok.

> But it is more robust if it is optional and not linked with unless
> needed.

Sure but then we rely on user interaction, and we need to provide a consistant 
and robust interface for that. If I have not missed anything I see two ideal 
solutions:

  1) UFC provides everything for us:

       Python : Everything just works
       C++    : We include all flags in FindUFC.cmake

  2) FFC provides optional dependecies for us. For this to be automated FFC
     need to scan a form for the use of non standard functions this
     information is then propagated:

       Python : to the ufc provided JIT compilation
       C++    : to a local CMakeFile (not sure what name we should have),
                which a user manually should include in the local CMakeFile,
                or (optimally) is already included in the local CMakeFiles.txt
                through some fancy include path.

Other suggestions? I am open for both solutions. 1) is the easiest to 
implement and is the least disruptive to the present functionality.

Johan

> Martin
> Den 28. okt. 2011 17.41 skrev "Johan Hake" <email address hidden>
> 
> følgende:
> > On Friday October 28 2011 02:37:34 Kristian B. Ølgaard wrote:
> > > On 28 October 2011 01:03, Johan Hake <email address hidden> wrote:
> > > > On Thursday October 27 2011 12:02:35 Kristian B. Ølgaard wrote:
> > > >> On 27 October 2011 19:38, Johan Hake <email address hidden>
> > 
> > wrote:
> > > >> > On Thursday October 27 2011 10:25:22 Garth Wells wrote:
> > > >> >> I don't think that it's a fix. We need to search for right
> > > >> >> library. It may be in a non-standard location, and in my case it
> > > >> >> should link to
> > > >> 
> > > >> It was just meant as a pointer to where the problem lies, not a
> > > >> proper fix.
> > > >> 
> > > >> >>     libboost_math_tr1-mt.so
> > > >> >> 
> > > >> >> and not
> > > >> >> 
> > > >> >>     libboost_math_tr1.so
> > > >> >> 
> > > >> >> Perhaps UFC should supply the build flags?
> > > >> 
> > > >> That could work for this case, but since UFC is not concerned about
> > > >> how the functions are implemented it seems more natural that the
> > > >> form compiler supplies the additional flags needed for the
> > > >> generated code.
> > > > 
> > > > Sure, but we actually moved from a situation where the actuall
> > > > compilation were done in FFC to UFC. It simplified the interface to
> > > > the JIT compilations alot.
> > > > 
> > > >> > There are already logic in the building of extension modules to
> > > >> > find the boost libraries, or more precise the boost header for
> > 
> > shared_ptr.
> > 
> > > >> > So it is not unatural to add logic for finding the correct boost
> > 
> > math
> > 
> > > >> > library.
> > > >> 
> > > >> But should it be? shared_ptr is not used in native UFC AFAIK, it is
> > > >> used for the DOLFIN wrapper code generated by FFC which again
> > > >> suggests that FFC supplies the additional flags.
> > > > 
> > > > Well, it provides a shared_ptr interface of UFC objects. DOLFIN
> > > > depends on this but it is not tied to DOLFIN per se. Other programs
> > > > can use
> > 
> > this
> > 
> > > > wrapper to include UFC modules.
> > > 
> > > There are no shared_ptr in ufc.h, but I guess you're talking about the
> > > swig generated modules?
> > 
> > Yes, and the decission of letting ufc handle its own JIT compilation made
> > it
> > important to have a configure step where we found boost.
> > 
> > > >> So with this argument, FFC could use the DOLFIN configuration to get
> > > >> the correct include dirs and libraries?
> > > > 
> > > > I think FFC generated UFC code should not have to depend on DOLFIN
> > 
> > flags.
> > 
> > > > The most natural thing is to include the flags in a
> > > > UFCCmake/pkg-config file I guess. Unfortunatly this will give us the
> > > > libs each time also when we do not use them. Not sure this is a
> > > > problem though.
> > > 
> > > No, but what should happen when 'ffc -l dolfin foo.ufl' is used? Then
> > > the output is wrapped for DOLFIN and it would be natural to use the
> > > DOLFIN flags. If, on the other hand, pure UFC is generated and the
> > > presence of bessel functions demand the boost_math_tr library, we
> > > should get the flags directly from FFC. We can't get the flags from
> > > UFC, as UFC cannot know which libraries the form compilers might need
> > > for their code.
> > 
> > Sure, but my point is that ufc should provide all possible libraries a
> > form compiler can use.
> > 
> > > But for now, it will be simpler to require users to supply a list of
> > > libraries, when needed, using the parameter system in FFC.
> > > This will only be needed for the Python interface, and users can
> > > decide for themselves if they will use 'libboost_math_tr1-mt.so' or
> > > 
> > >  'libboost_math_tr1.so'.
> > 
> > Why is this only needed for the Python compilation? If nost_math is
> > included
> > in DOLFIN now we have to include any "exotic" libraries in the future to
> > DOLFIN too.
> > 
> > > >> If FFC is used from the command line to generate a header file which
> > > >> is included in a DOLFIN program, I would expect Garth's fix to work
> > > >> for the C++ version.
> > > > 
> > > > That is true. But ufc code should be able to be integrated with any
> > > > software, and optimally it should be self contained. But introducing
> > > > boost dependencies we drop that.
> > > > 
> > > > For a cleaner dependency chain I suggest UFC provide everything it
> > 
> > needs
> > 
> > > > to compile UFC code (and python extensions) and then form compilers
> > 
> > have
> > 
> > > > to limit them self to what UFC provides. Whenever a formcompiler want
> > > > something new and fancy we need to update UFC to make that happen.
> > > 
> > > Yes, this will be the simplest solution, but it means that whenever a
> > > random form compiler decides to implement e.g., the dof evaluation by
> > > calling some exotic library, we have to update UFC to use that
> > > library, while most other form compilers will generate code which
> > > doesn't need it.
> > 
> > Would this be a problem? In a way this is what we do in
> > compile_expressions.
> > Here we make cmath functions and also complex expression available. I see
> > that
> > this might constrain the user.
> > 
> > Johan
> > 
> > > Kristian
> > > 
> > > > Johan
> > > > 
> > > >> Kristian
> > > >> 
> > > >> > What do you mean with UFC supply build flags?
> > > >> > 
> > > >> > Johan
> > > >> > 
> > > >> >> Garth
> > > >> > 
> > > >> > --
> > > >> > You received this bug notification because you are a member of
> > 
> > DOLFIN
> > 
> > > >> > Core Team, which is subscribed to DOLFIN.
> > > >> > https://bugs.launchpad.net/bugs/882560
> > > >> > 
> > > >> > Title:
> > > >> >  tr1::cyl_bessel_* functions are not found at linking stage of jit
> > > >> > 
> > > >> > Status in DOLFIN:
> > > >> >  Confirmed
> > > >> > 
> > > >> > Bug description:
> > > >> >  When a jit compiled module using bessel functions is imported
> > > >> >  into python, it fails with an undefined symbol error. Probably
> > > >> >  because
> > 
> > the
> > 
> > > >> >  boost math tr1 library is not linked in.
> >  
> >  ImportError:/home/martinal/.instant/cache/d003d0ea29ed9346265963000f1
> >  
> > > >> > a90 648953f6a6/_d003d0ea29ed9346265963000f1a90648953f6a6.so:
> > undefined
> > 
> > > >> > symbol: boost_cyl_bessel_j;
> > > >> > 
> > > >> >  Code to reproduce:
> > > >> >  
> > > >> >  from dolfin import *
> > > >> >  mesh = Interval(10, 0.1, 2.0)
> > > >> >  V = FunctionSpace(mesh, "CG", 1)
> > > >> >  x = interval.x
> > > >> >  f = bessel_J(0, x)
> > > >> >  g = project(f, V)
> > > >> >  plot(g, mesh=mesh)
> > > >> >  interactive()
> > > >> > 
> > > >> > To manage notifications about this bug go to:
> > > >> > https://bugs.launchpad.net/dolfin/+bug/882560/+subscriptions
> > > > 
> > > > --
> > > > You received this bug notification because you are a member of DOLFIN
> > > > Core Team, which is subscribed to DOLFIN.
> > > > https://bugs.launchpad.net/bugs/882560
> > > > 
> > > > Title:
> > > >  tr1::cyl_bessel_* functions are not found at linking stage of jit
> > > > 
> > > > Status in DOLFIN:
> > > >  Confirmed
> > > > 
> > > > Bug description:
> > > >  When a jit compiled module using bessel functions is imported into
> > > >  python, it fails with an undefined symbol error. Probably because
> > > >  the boost math tr1 library is not linked in.
> >  
> >  ImportError:/home/martinal/.instant/cache/d003d0ea29ed9346265963000f1a90
> >  
> > > > 648953f6a6/_d003d0ea29ed9346265963000f1a90648953f6a6.so: undefined
> > > > symbol: boost_cyl_bessel_j;
> > > > 
> > > >  Code to reproduce:
> > > >  
> > > >  from dolfin import *
> > > >  mesh = Interval(10, 0.1, 2.0)
> > > >  V = FunctionSpace(mesh, "CG", 1)
> > > >  x = interval.x
> > > >  f = bessel_J(0, x)
> > > >  g = project(f, V)
> > > >  plot(g, mesh=mesh)
> > > >  interactive()
> > > > 
> > > > To manage notifications about this bug go to:
> > > > https://bugs.launchpad.net/dolfin/+bug/882560/+subscriptions
> > 
> > --
> > You received this bug notification because you are a member of DOLFIN
> > Core Team, which is subscribed to DOLFIN.
> > https://bugs.launchpad.net/bugs/882560
> > 
> > Title:
> >  tr1::cyl_bessel_* functions are not found at linking stage of jit
> > 
> > Status in DOLFIN:
> >  Confirmed
> > 
> > Bug description:
> >  When a jit compiled module using bessel functions is imported into
> >  python, it fails with an undefined symbol error. Probably because the
> >  boost math tr1 library is not linked in.
> >  
> >  
> >  ImportError:/home/martinal/.instant/cache/d003d0ea29ed9346265963000f1a90
> >  648953f6a6/_d003d0ea29ed9346265963000f1a90648953f6a6.so: undefined
> >  symbol: boost_cyl_bessel_j;
> >  
> >  
> >  Code to reproduce:
> >  
> >  from dolfin import *
> >  mesh = Interval(10, 0.1, 2.0)
> >  V = FunctionSpace(mesh, "CG", 1)
> >  x = interval.x
> >  f = bessel_J(0, x)
> >  g = project(f, V)
> >  plot(g, mesh=mesh)
> >  interactive()
> > 
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/dolfin/+bug/882560/+subscriptions