On Thursday November 17 2011 02:24:27 Martin Sandve Alnæs wrote:
> Works for me. I've enabled the bessel function test and pushed it to
> my personal buildbot. If that passes, I will push it to 1.0.x to see
> if the macbot passes too. If it doesn't I'll disable the test again.

Thanks!

Johan
 
> Martin
> 
> On 17 November 2011 07:47, Johan Hake <email address hidden> wrote:
> > I have commited a hack for this in UFC. We need to figure out how to
> > properly fix this. It is related to:
> > 
> >  https://bugs.launchpad.net/dolfin/+bug/887324
> > 
> > Johan
> > 
> > On Saturday October 29 2011 02:11:29 Kristian B. Ølgaard wrote:
> >> On 28 October 2011 23:08, Johan Hake <email address hidden> wrote:
> >> > On Friday October 28 2011 13:02:36 Kristian B. Ølgaard wrote:
> >> >> On 28 October 2011 21:16, Johan Hake <email address hidden> 
wrote:
> >> >> > 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.
> >> >> 
> >> >> If UFC has to provide all possible dependencies for all possible
> >> >> compilers, we end up with an infinite list of libraries which a
> >> >> specific code generated by a specific form compiler might not even
> >> >> need.
> >> > 
> >> > I see that theoretically this might be the case, but in practice?
> >> > 
> >> >> The form compiler e.g., FFC generates the code and therefore knows
> >> >> which special libraries are needed.
> >> >> It would therefore make sense if FFC could provide the flags for all
> >> >> special libraries that it _might_ need, and then only in those cases
> >> >> where it is actually needed should they be added to the standard
> >> >> flags.
> >> > 
> >> > I see this take on it.
> >> > 
> >> >> This approach will work well with Python but is more troublesome to
> >> >> integrate with C++ and compiling a header file against DOLFIN.
> >> > 
> >> > Yes, then FFC need to provide some sort of CMake file to take care of
> >> > the extra flags.
> >> > 
> >> >> >> 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
> >> >> 
> >> >> As I write above, this could easily get out of hand if many compilers
> >> >> start using different libraries.
> >> > 
> >> > Sure.
> >> > 
> >> >> >  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.
> >> >> 
> >> >> Python is easy, C++ is not in this case.
> >> > 
> >> > I think C++ is incorporated into my suggestion. We just need FFC to
> >> > generate some sort of general CMakeFile, which is included in the
> >> > CMakeFile of each poject.
> >> > 
> >> >> > Other suggestions? I am open for both solutions. 1) is the easiest
> >> >> > to implement and is the least disruptive to the present
> >> >> > functionality.
> >> >> 
> >> >> Since we're currently just talking about adding one extra boost
> >> >> dependency in DOLFIN and UFC, I think we should go with option 1).
> >> > 
> >> > If this is what we land on I can try to hack the CMake of UFC and add
> >> > it there. If I fail I might ask some CMake guro to help out. I can
> >> > also add configuration of the libmath from boost to the compilation
> >> > of the python extension module.
> >> 
> >> Yes, let's go with this approach for now and see if we can avoid
> >> making things too general/complex.
> >> 
> >> Kristian
> >> 
> >> > Johan
> >> > 
> >> >> Kristian
> >> >> 
> >> >> > 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/d003d0ea29ed934626596
> >> >> >> > 300 0f1
> >> >> >> > 
> >> >> >> > > >> > 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/+subscripti
> >> >> >> > > >> > ons
> >> >> >> > > > 
> >> >> >> > > > --
> >> >> >> > > > 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/d003d0ea29ed934626596
> >> >> >> > 300 0f1 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/d003d0ea29ed934626596
> >> >> >> > 300 0f1 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/d003d0ea29ed934626596300
> >> >> > 0f1 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/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