← Back to team overview

dolfin team mailing list archive

Re: [Fenics] Ubuntu release schedule

 

On Thu, Jul 01, 2010 at 09:05:21AM +0200, Johannes Ring wrote:
> On Tue, Jun 22, 2010 at 11:04 AM, Johannes Ring <johannr@xxxxxxxxx> wrote:
> > On Mon, Jun 21, 2010 at 11:52 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> On Mon, Jun 21, 2010 at 11:48:09PM +0200, Johannes Ring wrote:
> >>> On Mon, Jun 21, 2010 at 10:52 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >>> > On Mon, Jun 21, 2010 at 10:16:05PM +0200, Johannes Ring wrote:
> >>> >> On Mon, Jun 21, 2010 at 9:12 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >>> >> > On Mon, Jun 21, 2010 at 02:37:26PM +0200, Johannes Ring wrote:
> >>> >> >> On Mon, Jun 21, 2010 at 1:53 PM, Anders Logg <logg@xxxxxxxxx> wrote:
> >>> >> >> > On Wed, Jun 16, 2010 at 11:49:32AM +0200, Johannes Ring wrote:
> >>> >> >> >> On Wed, Jun 16, 2010 at 11:27 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> >>> >> >> >> > When should the deadline be for making the new releases?
> >>> >> >> >> >
> >>> >> >> >> > Is it too later if we finish by June 23rd?
> >>> >> >> >>
> >>> >> >> >> Well, it might be too late for automatic imports from Debian to
> >>> >> >> >> Ubuntu, but I can request manual imports later. It worked out fine the
> >>> >> >> >> last time. So June 23rd sounds good for me.
> >>> >> >> >
> >>> >> >> > ok, let's aim for 23rd (Wednesday this week).
> >>> >> >> >
> >>> >> >> > Anything that we need to fix before the release?
> >>> >> >> >
> >>> >> >> > The buildbot fails with this message when running the extrapolation demo:
> >>> >> >> >
> >>> >> >> >  run-time error: auxlib::solve_od(): need LAPACK
> >>> >> >>
> >>> >> >> I have the same problem on my laptop.
> >>> >> >>
> >>> >> >> > Is there something that needs to be installed on the buildbot?
> >>> >> >>
> >>> >> >> I'm not sure whats wrong but the problem seems to be that I have built
> >>> >> >> Armadillo with debugging turned on (-DCMAKE_BUILD_TYPE:STRING=Debug)
> >>> >> >> on the buildbot (and on my laptop). When I run gdb on
> >>> >> >> demo/adaptivity/extrapolation/cpp I get this:
> >>> >> >>
> >>> >> >> [...]
> >>> >> >> #7  0xb76340b9 in dolfin::Extrapolation::compute_coefficients
> >>> >> >> (coefficients=@0xbfe89fc0, v=@0xbfe8a258, V=@0xbfe8a3b8,
> >>> >> >> W=@0xbfe8a338,
> >>> >> >>     cell0=@0xbfe89f98, c0=@0xbfe89f58, dofs=@0xbfe89fd0, offset=@0xbfe89fcc)
> >>> >> >>     at /home/johannr/src/armadillo-0.6.10/Build/local/include/armadillo_bits/debug.hpp:218
> >>> >> >> #8  0xb7634e5b in dolfin::Extrapolation::extrapolate (w=@0xbfe8a178,
> >>> >> >> v=@0xbfe8a258) at dolfin/adaptivity/Extrapolation.cpp:72
> >>> >> >> #9  0xb740bd54 in dolfin::Function::extrapolate (this=0xbfe8a178,
> >>> >> >> v=@0xbfe8a258) at dolfin/function/Function.cpp:330
> >>> >> >> #10 0x0805c768 in main () at main.cpp:44
> >>> >> >>
> >>> >> >> Should I just rebuild Armadillo with debugging off on the buildbots?
> >>> >> >>
> >>> >> >> Johannes
> >>> >> >
> >>> >> > Could you add some debugging to Extrapolation.cpp to see where things
> >>> >> > go wrong? Find the line that says
> >>> >> >
> >>> >> >  arma::Col<double> x = arma::solve(A, b);
> >>> >> >
> >>> >> > and print something before and after. It would be interesting to see
> >>> >> > if
> >>> >> >
> >>> >> >  1. This is where it breaks
> >>> >> >  2. It breaks already the first time or just for particular input data
> >>> >>
> >>> >> Yes, this is where it breaks and it breaks the first time. Anything
> >>> >> else I should try?
> >>> >>
> >>> >> Johannes
> >>> >
> >>> > Can you check if you are able to run call arma::solve(A, b) at all?
> >>> >
> >>> >  arma::mat A(M, N);
> >>> >  arma::vec b(M);
> >>> >
> >>> >  then set some bogus values in A and b
> >>> >
> >>> >  arma::Col<double> x = arma::solve(A, b);
> >>> >
> >>> > By the way, why is the output arma::Col and not arma::vec? Garth?
> >>> >
> >>> > If this works, then try to print the size of A and b in
> >>> > Extrapolation.cpp and try the same size in your test program.
> >>>
> >>> It doesn't work. I tried this test program
> >>>
> >>>   arma::mat A = arma::rand(4,4);
> >>>   arma::vec b = arma::rand(4);
> >>>   arma::vec x = arma::solve(A, b);
> >>>
> >>> and I got the same problem.
> >>>
> >>> Johannes
> >>
> >> Works for me. I've tried the following test program:
> >>
> >> #include <armadillo>
> >>
> >> int main()
> >> {
> >>  arma::mat A = arma::rand(4,4);
> >>  arma::vec b = arma::rand(4);
> >>  arma::vec x = arma::solve(A, b);
> >>
> >>  return 0;
> >> }
> >
> > Yes, that's what I did. I also tried to build Armadillo (several
> > different versions) without debugging and I still got the same runtime
> > error.
> >
> >> Compiled with
> >>
> >> g++ main.cpp -llapack
> >>
> >> Runs with with and without gdb. Also works fine with valgrind.
> >>
> >> Anyone else has this problem? I'm using the Armadillo Ubuntu package.
> >
> > Maybe you can try to build Armadillo? Here are the steps:
> >
> >  wget http://downloads.sourceforge.net/project/arma/armadillo-0.9.10.tar.gz
> >  tar zxf armadillo-0.9.10.tar.gz
> >  cd armadillo-0.9.10/
> >  mkdir build
> >  cd build
> >  cmake -DCMAKE_INSTALL_PREFIX:PATH=$PWD/local ..
> >  make && make install
> >  g++ -I$PWD/local/include -L$PWD/local/lib64 -larmadillo /path/to/test.cpp
> >  LD_LIBRARY_PATH=$PWD/local/lib64 ./a.out
>
> I found out that this out-of-source build does not work correctly with
> Armadillo. These steps works fine on all my setups:
>
> wget http://downloads.sourceforge.net/project/arma/armadillo-0.9.10.tar.gz
> tar zxf armadillo-0.9.10.tar.gz
> cd armadillo-0.9.10/
> cmake -DCMAKE_INSTALL_PREFIX:PATH=$PWD/local \
>   -D LIB_INSTALL_DIR:STRING=lib .
> make && make install
> g++ -I$PWD/local/include -L$PWD/local/lib -larmadillo /tmp/test.cpp
> LD_LIBRARY_PATH=$PWD/local/lib ./a.out
>
> The buildbot is green now on jaunty-amd64 and will hopefully also be
> green on hardy-i386. The mac-osx buildslave will not be green because
> of some MPI problems (I will try to fix this after the summer).
>
> Johannes

Sounds good. I will start cranking out releases.

--
Anders

Attachment: signature.asc
Description: Digital signature


References