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.
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.
This approach will work well with Python but is more troublesome to
integrate with C++ and compiling a header file against DOLFIN.

>> 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.

>  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.

> 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).


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/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
>
> --
> 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/d003d0ea29ed9346265963000f1a90648953f6a6/_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
>