problem with new installation

On Thu, Nov 24, 2011 at 09:11:04AM -0000, Mikael Mortensen wrote:
> New question #179849 on DOLFIN:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Hi,
>
> Today I made a fresh unstable installation of fenics using dorsal. I cleaned out all the old garbage like I use to and typed dorsal.sh in the terminal. It ran through the entire installation with no problems. However, no my dolfin seems to be broken? Could anyone else with a newly installed dolfin from trunk try the following code and see if there's weirdness?
>
> from dolfin import *
>
> mesh = UnitSquare(4, 4)
> V = VectorFunctionSpace(mesh, 'CG', 1)
> Q = FunctionSpace(mesh, 'CG', 1)
> bc1 = DirichletBC(V, (1., 0.), "std::abs(x[1] - 1.) < DOLFIN_EPS && on_boundary")
> bc2 = DirichletBC(Q, (1.), "std::abs(x[1] - 1.) < DOLFIN_EPS && on_boundary")
> u_ = Function(V)
> p_ = Function(Q)
> bc1.apply(u_.vector())
> bc2.apply(p_.vector())
> plot(u_)
> plot(p_)
> interactive()
>
> The dirichlet condition is not applied only to the dofs on the top at x[1] = 1. The condition is actually applied to 6 dofs, not 4, and not only on the top. Does anyone else get this? I've really made an effort to clean out all previous stuff, even in .bashrc, before making the new install.
>
> Mikael

Works fine or me.

instant-clean?

--
Anders

Brief update. Reverting dolfin to -r 6450 and the error is still there,
reverting to 6430 and the problem goes away. Seems to me like a bug?

Mikael

On 24 November 2011 10:11, Mikael Mortensen <
<email address hidden>> wrote:

> New question #179849 on DOLFIN:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Hi,
>
> Today I made a fresh unstable installation of fenics using dorsal. I
> cleaned out all the old garbage like I use to and typed dorsal.sh in the
> terminal. It ran through the entire installation with no problems. However,
> no my dolfin seems to be broken? Could anyone else with a newly installed
> dolfin from trunk try the following code and see if there's weirdness?
>
> from dolfin import *
>
> mesh = UnitSquare(4, 4)
> V = VectorFunctionSpace(mesh, 'CG', 1)
> Q = FunctionSpace(mesh, 'CG', 1)
> bc1 = DirichletBC(V, (1., 0.), "std::abs(x[1] - 1.) < DOLFIN_EPS &&
> on_boundary")
> bc2 = DirichletBC(Q, (1.), "std::abs(x[1] - 1.) < DOLFIN_EPS &&
> on_boundary")
> u_ = Function(V)
> p_ = Function(Q)
> bc1.apply(u_.vector())
> bc2.apply(p_.vector())
> plot(u_)
> plot(p_)
> interactive()
>
> The dirichlet condition is not applied only to the dofs on the top at x[1]
> = 1. The condition is actually applied to 6 dofs, not 4, and not only on
> the top. Does anyone else get this? I've really made an effort to clean out
> all previous stuff, even in .bashrc, before making the new install.
>
> Mikael
>
>
>
>
>
> --
> You received this question notification because you asked the question.
>

I'm not sure what to look for but this is what I get with DOLFIN revision 6466 (from the fenics-dev PPA):

  http://vefur.simula.no/~johannr/tmp/tmp1.png
  http://vefur.simula.no/~johannr/tmp/tmp2.png

On Thu, Nov 24, 2011 at 10:41:11AM -0000, Johannes Ring wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Johannes Ring posted a new comment:
> I'm not sure what to look for but this is what I get with DOLFIN
> revision 6466 (from the fenics-dev PPA):
>
> http://vefur.simula.no/~johannr/tmp/tmp1.png
> http://vefur.simula.no/~johannr/tmp/tmp2.png

Same as I get.

--
Anders

That's exactly the plots I get with dolfin revision 6430. Here are the
plots I get from 6450 though. And I've done instant-clean. But if I'm the
only one with this problem I'll investigate some more before filing a bug
report. Has anyone tried a completely fresh install of everything?

M

On 24 November 2011 12:15, Anders Logg <<email address hidden>
> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Open => Answered
>
> Anders Logg proposed the following answer:
> On Thu, Nov 24, 2011 at 10:41:11AM -0000, Johannes Ring wrote:
> > Question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Johannes Ring posted a new comment:
> > I'm not sure what to look for but this is what I get with DOLFIN
> > revision 6466 (from the fenics-dev PPA):
> >
> > http://vefur.simula.no/~johannr/tmp/tmp1.png
> > http://vefur.simula.no/~johannr/tmp/tmp2.png
>
> Same as I get.
>
> --
> Anders
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/dolfin/+question/179849/+confirm?answer_id=3
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/dolfin/+question/179849
>
> You received this question notification because you asked the question.
>

Does it work for you with revision 6449? Try to figure out in which revision this fails and run bzr diff to see the difference between this and the working revision (for instance bzr diff -r 6449..6450).

It works for me both on Ubuntu 10.04 and 11.10 but that is with the binary packages built from trunk, not by Dorsal.

I'll look into it, but it will probably take some time.

M

On 24 November 2011 14:35, Johannes Ring <
<email address hidden>> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Johannes Ring posted a new comment:
> Does it work for you with revision 6449? Try to figure out in which
> revision this fails and run bzr diff to see the difference between this
> and the working revision (for instance bzr diff -r 6449..6450).
>
> It works for me both on Ubuntu 10.04 and 11.10 but that is with the
> binary packages built from trunk, not by Dorsal.
>
> --
> You received this question notification because you asked the question.
>

Last revision that works for me is 6446. It looks from the diff between
6446 and 6447 that mainly assert is changed to dolfin_assert. Could that be
significant here?

M

On 24 November 2011 15:01, Mikael Mortensen <
<email address hidden>> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> You gave more information on the question:
> I'll look into it, but it will probably take some time.
>
> M
>
> On 24 November 2011 14:35, Johannes Ring <
> <email address hidden>> wrote:
>
> > Your question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Johannes Ring posted a new comment:
> > Does it work for you with revision 6449? Try to figure out in which
> > revision this fails and run bzr diff to see the difference between this
> > and the working revision (for instance bzr diff -r 6449..6450).
> >
> > It works for me both on Ubuntu 10.04 and 11.10 but that is with the
> > binary packages built from trunk, not by Dorsal.
> >
> > --
> > You received this question notification because you asked the question.
> >
>
> --
> You received this question notification because you asked the question.
>

Ideas:

Try building dolfin with and without whatever flag turns off dolfin_assert.

Look for assert calls with side effects.

On Thu, Nov 24, 2011 at 04:10:57PM -0000, Martin Sandve Alnæs wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Martin Sandve Alnæs posted a new comment:
> Ideas:
>
> Try building dolfin with and without whatever flag turns off
> dolfin_assert.

It's the DEBUG flag.

> Look for assert calls with side effects.

Sounds like a difficult task. My suggestion would be to print stuff
from within dolfin/mesh/SubDomain.cpp and try to figure out what goes
wrong.

--
Anders

Hi,

My problems disappear when I modify log.h like this:

// Assertion, only active if DEBUG is defined
//#ifdef DEBUG
#define dolfin_assert(check) \
  do { \
    if (!(check)) \
    { \
      dolfin::__dolfin_assert(__FILE__, __LINE__, __FUNCTION__, #check);
\
    } \
  } while (false)
//#else
//#define dolfin_assert(check)
//#endif

What's actually the procedure for compiling dolfin with the DEBUG flag?
CMAKE_CXX_FLAGS?

Mikael

On 24 November 2011 18:01, Anders Logg <<email address hidden>
> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Open => Answered
>
> Anders Logg proposed the following answer:
> On Thu, Nov 24, 2011 at 04:10:57PM -0000, Martin Sandve Alnæs wrote:
> > Question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Martin Sandve Alnæs posted a new comment:
> > Ideas:
> >
> > Try building dolfin with and without whatever flag turns off
> > dolfin_assert.
>
> It's the DEBUG flag.
>
> > Look for assert calls with side effects.
>
> Sounds like a difficult task. My suggestion would be to print stuff
> from within dolfin/mesh/SubDomain.cpp and try to figure out what goes
> wrong.
>
> --
> Anders
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/dolfin/+question/179849/+confirm?answer_id=9
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/dolfin/+question/179849
>
> You received this question notification because you asked the question.
>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2011 06:25 PM, Mikael Mortensen wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Answered => Open
>
> Mikael Mortensen is still having a problem: Hi,
>
> My problems disappear when I modify log.h like this:
>
> // Assertion, only active if DEBUG is defined //#ifdef DEBUG
> #define dolfin_assert(check) \ do { \ if (!(check)) \ { \
> dolfin::__dolfin_assert(__FILE__, __LINE__, __FUNCTION__, #check);
> \ } \ } while (false) //#else //#define dolfin_assert(check)
> //#endif
>
> What's actually the procedure for compiling dolfin with the DEBUG
> flag? CMAKE_CXX_FLAGS?

It should be something like
cmake -DCMAKE_BUILD_TYPE=Debug ./
when you run the cmake configuring process. It sets the proper debug
flags among them -DDEBUG.

HTH
- --
Andre

>
> Mikael
>
> On 24 November 2011 18:01, Anders Logg
> <<email address hidden>
>> wrote:
>
>> Your question #179849 on DOLFIN changed:
>> https://answers.launchpad.net/dolfin/+question/179849
>>
>> Status: Open => Answered
>>
>> Anders Logg proposed the following answer: On Thu, Nov 24, 2011
>> at 04:10:57PM -0000, Martin Sandve Alnæs wrote:
>>> Question #179849 on DOLFIN changed:
>>> https://answers.launchpad.net/dolfin/+question/179849
>>>
>>> Martin Sandve Alnæs posted a new comment: Ideas:
>>>
>>> Try building dolfin with and without whatever flag turns off
>>> dolfin_assert.
>>
>> It's the DEBUG flag.
>>
>>> Look for assert calls with side effects.
>>
>> Sounds like a difficult task. My suggestion would be to print
>> stuff from within dolfin/mesh/SubDomain.cpp and try to figure out
>> what goes wrong.
>>
>> -- Anders
>>
>> -- If this answers your question, please go to the following page
>> to let us know that it is solved:
>> https://answers.launchpad.net/dolfin/+question/179849/+confirm?answer_id=9
>>
>>
>>
If you still need help, you can reply to this email or go to the
>> following page to enter your feedback:
>> https://answers.launchpad.net/dolfin/+question/179849
>>
>> You received this question notification because you asked the
>> question.
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOz95lAAoJEA79ggnbq9dmUPkIAPIKrHWaA3R12wOvfxyvUHHB
eR4xYNmaHFFYwnrhjX4VYK0l55yS/m8elz3wY+9V1YbMc0IDNZTqMDNZnJDiOAhC
3xPwAsgL84MLP9APWI7J6jKXlEBWrdVbAbgw/grPTcxknvvvuB3Y7ur4cpRUjov1
6bLfoVpft1cI96DY/N+4gRroW/uPNjPHH59veyNvr8NvwEZ6Crcc9AvCqibyejLO
DJgAm3OZTr8oWge5JnphLdPvqfDEtJOX1pkKrtt2dkYmOopurjKnU9X8EVrRwdiG
cQKOK9sgY1m0N/S6d2pmVZsl3ojatccMUDexZIjjn9rQJnpqA/K1xueZ7UEdNV4=
=71x7
-----END PGP SIGNATURE-----

Then it looks like you are building DOLFIN *without* the DEBUG flag
and the macro is not correctly defined in the #else case.

So something goes wrong with this macro somewhere in the code:

  #define dolfin_assert(check)

Does it help if you change back to how they were and then replace the
above line with

  #define dolfin_assert(check) {}

?

--
Anders

On Fri, Nov 25, 2011 at 05:25:44PM -0000, Mikael Mortensen wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Answered => Open
>
> Mikael Mortensen is still having a problem:
> Hi,
>
> My problems disappear when I modify log.h like this:
>
> // Assertion, only active if DEBUG is defined
> //#ifdef DEBUG
> #define dolfin_assert(check) \
> do { \
> if (!(check)) \
> { \
> dolfin::__dolfin_assert(__FILE__, __LINE__, __FUNCTION__, #check);
> \
> } \
> } while (false)
> //#else
> //#define dolfin_assert(check)
> //#endif
>
> What's actually the procedure for compiling dolfin with the DEBUG flag?
> CMAKE_CXX_FLAGS?
>
> Mikael
>
> On 24 November 2011 18:01, Anders Logg <<email address hidden>
> > wrote:
>
> > Your question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Status: Open => Answered
> >
> > Anders Logg proposed the following answer:
> > On Thu, Nov 24, 2011 at 04:10:57PM -0000, Martin Sandve Alnæs wrote:
> > > Question #179849 on DOLFIN changed:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > Martin Sandve Alnæs posted a new comment:
> > > Ideas:
> > >
> > > Try building dolfin with and without whatever flag turns off
> > > dolfin_assert.
> >
> > It's the DEBUG flag.
> >
> > > Look for assert calls with side effects.
> >
> > Sounds like a difficult task. My suggestion would be to print stuff
> > from within dolfin/mesh/SubDomain.cpp and try to figure out what goes
> > wrong.
> >
> >
> >
> > If you still need help, you can reply to this email or go to the
> > following page to enter your feedback:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > You received this question notification because you asked the question.
> >
>

On 25 November 2011 19:45, Anders Logg <<email address hidden>
> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Anders Logg proposed the following answer:
> Then it looks like you are building DOLFIN *without* the DEBUG flag
> and the macro is not correctly defined in the #else case.
>
> So something goes wrong with this macro somewhere in the code:
>
> #define dolfin_assert(check)
>
> Does it help if you change back to how they were and then replace the
> above line with
>
> #define dolfin_assert(check) {}
>

Nope, this does not help. (Can't believe I'm still the only one with this
problem)

M

>
> ?
>
> --
> Anders
>
>
> On Fri, Nov 25, 2011 at 05:25:44PM -0000, Mikael Mortensen wrote:
> > Question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Status: Answered => Open
> >
> > Mikael Mortensen is still having a problem:
> > Hi,
> >
> > My problems disappear when I modify log.h like this:
> >
> > // Assertion, only active if DEBUG is defined
> > //#ifdef DEBUG
> > #define dolfin_assert(check) \
> > do { \
> > if (!(check)) \
> > { \
> > dolfin::__dolfin_assert(__FILE__, __LINE__, __FUNCTION__, #check);
> > \
> > } \
> > } while (false)
> > //#else
> > //#define dolfin_assert(check)
> > //#endif
> >
> > What's actually the procedure for compiling dolfin with the DEBUG flag?
> > CMAKE_CXX_FLAGS?
> >
> > Mikael
> >
> > On 24 November 2011 18:01, Anders Logg <
> <email address hidden>
> > > wrote:
> >
> > > Your question #179849 on DOLFIN changed:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > Status: Open => Answered
> > >
> > > Anders Logg proposed the following answer:
> > > On Thu, Nov 24, 2011 at 04:10:57PM -0000, Martin Sandve Alnæs wrote:
> > > > Question #179849 on DOLFIN changed:
> > > > https://answers.launchpad.net/dolfin/+question/179849
> > > >
> > > > Martin Sandve Alnæs posted a new comment:
> > > > Ideas:
> > > >
> > > > Try building dolfin with and without whatever flag turns off
> > > > dolfin_assert.
> > >
> > > It's the DEBUG flag.
> > >
> > > > Look for assert calls with side effects.
> > >
> > > Sounds like a difficult task. My suggestion would be to print stuff
> > > from within dolfin/mesh/SubDomain.cpp and try to figure out what goes
> > > wrong.
> > >
> > >
> > >
> > > If you still need help, you can reply to this email or go to the
> > > following page to enter your feedback:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > You received this question notification because you asked the question.
> > >
> >
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/dolfin/+question/179849/+confirm?answer_id=12
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/dolfin/+question/179849
>
> You received this question notification because you asked the question.
>

On Fri, Nov 25, 2011 at 06:45:48PM -0000, Anders Logg wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Anders Logg proposed the following answer:
> Then it looks like you are building DOLFIN *without* the DEBUG flag
> and the macro is not correctly defined in the #else case.
>
> So something goes wrong with this macro somewhere in the code:
>
> #define dolfin_assert(check)
>
> Does it help if you change back to how they were and then replace the
> above line with
>
> #define dolfin_assert(check) {}
>
> ?

Very strange...

I just rebuilt DOLFIN without -DDEBUG (setting CMAKE_BUILD_TYPE to
Release and verifying using make VERBOSE=1 that the -DDEBUG option is
not present) but it still works fine here.

Is anyone else seeing this?

--
Anders

Looks like an optimization error. I reduced the optimization flag to -O1
and the problem is gone, even without the DEBUG flag. With -O2 the problem
returns.

M

On 26 November 2011 10:31, Anders Logg <<email address hidden>
> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Open => Answered
>
> Anders Logg proposed the following answer:
> On Fri, Nov 25, 2011 at 06:45:48PM -0000, Anders Logg wrote:
> > Question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Anders Logg proposed the following answer:
> > Then it looks like you are building DOLFIN *without* the DEBUG flag
> > and the macro is not correctly defined in the #else case.
> >
> > So something goes wrong with this macro somewhere in the code:
> >
> > #define dolfin_assert(check)
> >
> > Does it help if you change back to how they were and then replace the
> > above line with
> >
> > #define dolfin_assert(check) {}
> >
> > ?
>
> Very strange...
>
> I just rebuilt DOLFIN without -DDEBUG (setting CMAKE_BUILD_TYPE to
> Release and verifying using make VERBOSE=1 that the -DDEBUG option is
> not present) but it still works fine here.
>
> Is anyone else seeing this?
>
> --
> Anders
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/dolfin/+question/179849/+confirm?answer_id=14
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/dolfin/+question/179849
>
> You received this question notification because you asked the question.
>

It works fine for me also with optimization. I'm setting the CMake
build type to Release which removes the DEBUG flag and sets -O3.

Here are the flags I'm using:

cd /home/logg/scratch/src/dolfin/1.0.x-logg/build/dolfin &&
/usr/bin/c++ -Ddo\
lfin_EXPORTS -DBOOST_UBLAS_NDEBUG -DHAS_TRILINOS -DHAS_SLEPC
-DHAS_PETSC -DHAS_\
UMFPACK -DHAS_CHOLMOD -DHAS_SCOTCH -DHAS_PARMETIS -DHAS_CGAL
-DHAS_ZLIB -DHAS_C\
PPUNIT -DHAS_MPI -DMPICH_IGNORE_CXX_SEEK -DHAS_OPENMP
-DDOLFIN_VERSION=\"1.0.rc\
1+\" -frounding-math -fopenmp -O3 -DNDEBUG -fPIC
-I/home/logg/scratch/src/dolf\
in/1.0.x-logg -I/usr/include/libxml2
-I/home/logg/scratch/fenics/include -I/hom\
e/logg/scratch/fenics/include/trilinos -I/home/logg/scratch/fenics
-I/usr/lib/o\
penmpi/include -I/usr/lib/openmpi/include/openmpi
-I/usr/include/suitesparse -I\
/usr/include/scotch -I/usr/include/cppunit -o
CMakeFiles/dolfin.dir/adaptivi\
ty/adapt.cpp.o -c
/home/logg/scratch/src/dolfin/1.0.x-logg/dolfin/adaptivity/ad\
apt.cpp

--
Anders

On Sat, Nov 26, 2011 at 12:50:48PM -0000, Mikael Mortensen wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Answered => Open
>
> Mikael Mortensen is still having a problem:
> Looks like an optimization error. I reduced the optimization flag to -O1
> and the problem is gone, even without the DEBUG flag. With -O2 the problem
> returns.
>
> M
>
> On 26 November 2011 10:31, Anders Logg <<email address hidden>
> > wrote:
>
> > Your question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Status: Open => Answered
> >
> > Anders Logg proposed the following answer:
> > On Fri, Nov 25, 2011 at 06:45:48PM -0000, Anders Logg wrote:
> > > Question #179849 on DOLFIN changed:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > Anders Logg proposed the following answer:
> > > Then it looks like you are building DOLFIN *without* the DEBUG flag
> > > and the macro is not correctly defined in the #else case.
> > >
> > > So something goes wrong with this macro somewhere in the code:
> > >
> > > #define dolfin_assert(check)
> > >
> > > Does it help if you change back to how they were and then replace the
> > > above line with
> > >
> > > #define dolfin_assert(check) {}
> > >
> > > ?
> >
> > Very strange...
> >
> > I just rebuilt DOLFIN without -DDEBUG (setting CMAKE_BUILD_TYPE to
> > Release and verifying using make VERBOSE=1 that the -DDEBUG option is
> > not present) but it still works fine here.
> >
> > Is anyone else seeing this?
> >
> >
> >
> > If you still need help, you can reply to this email or go to the
> > following page to enter your feedback:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > You received this question notification because you asked the question.
> >
>

Can you try printing some stuff from within SubDomain.cpp?

Replace apply_markers in SubDomain.cpp with the following code:

void SubDomain::apply_markers(S& sub_domains,
                              T sub_domain,
                              const Mesh& mesh) const
{
  log(TRACE, "Computing sub domain markers for sub domain %d.",
  sub_domain);

  // Get the dimension of the entities we are marking
  const uint dim = sub_domains.dim();

  // Compute facet - cell connectivity if necessary
  const uint D = mesh.topology().dim();
  if (dim == D - 1)
  {
    mesh.init(D - 1);
    mesh.init(D - 1, D);
  }

  // Set geometric dimension (needed for SWIG interface)
  _geometric_dimension = mesh.geometry().dim();

  // Always false when not marking facets
  bool on_boundary = false;

  // Extract exterior (non shared) facets markers
  const MeshFunction<bool>& exterior =
  mesh.parallel_data().exterior_facet();

  // Array for vertex coordinate
  Array<double> x;

  // Compute sub domain markers
  Progress p("Computing sub domain markers", mesh.num_entities(dim));
  for (MeshEntityIterator entity(mesh, dim); !entity.end(); ++entity)
  {
    // Check if entity is on the boundary if entity is a facet
    if (dim == D - 1)
    {
      on_boundary = entity->num_entities(D) == 1 &&
        (exterior.size() == 0 || exterior[*entity]);
    }

    // Start by assuming all points are inside
    bool all_points_inside = true;

    cout << "checking entity " << *entity << endl;

    // Check all incident vertices if dimension is > 0 (not a vertex)
    if (entity->dim() > 0)
    {
      for (VertexIterator vertex(*entity); !vertex.end(); ++vertex)
      {
        x.update(_geometric_dimension,
        const_cast<double*>(vertex->x()));
        if (!inside(x, on_boundary))
        {
          all_points_inside = false;
          break;
        }
      }
    }

    // Check midpoint (works also in the case when we have a single
    vertex)
    if (all_points_inside)
    {
      cout << " yes, now checking midpoint" << endl;

      x.update(_geometric_dimension,
               const_cast<double*>(entity->midpoint().coordinates()));
      if (!inside(x, on_boundary))
        all_points_inside = false;
    }

    // Mark entity with all vertices inside
    if (all_points_inside)
    {
      cout << " yes, marking entity " << entity->index() << " as " <<
      sub_domain << endl;
      sub_domains.set_value(entity->index(), sub_domain, mesh);
    }

    p++;
  }
}

Also try to reduce the test code to the smallest possible problem that
still gives you the error. For a start, only include the scalar case
and just call sub_domain.mark() with a MeshFunction if that is where
it goes wrong.

--
Anders

On Sat, Nov 26, 2011 at 12:50:48PM -0000, Mikael Mortensen wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Answered => Open
>
> Mikael Mortensen is still having a problem:
> Looks like an optimization error. I reduced the optimization flag to -O1
> and the problem is gone, even without the DEBUG flag. With -O2 the problem
> returns.
>
> M
>
> On 26 November 2011 10:31, Anders Logg <<email address hidden>
> > wrote:
>
> > Your question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Status: Open => Answered
> >
> > Anders Logg proposed the following answer:
> > On Fri, Nov 25, 2011 at 06:45:48PM -0000, Anders Logg wrote:
> > > Question #179849 on DOLFIN changed:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > Anders Logg proposed the following answer:
> > > Then it looks like you are building DOLFIN *without* the DEBUG flag
> > > and the macro is not correctly defined in the #else case.
> > >
> > > So something goes wrong with this macro somewhere in the code:
> > >
> > > #define dolfin_assert(check)
> > >
> > > Does it help if you change back to how they were and then replace the
> > > above line with
> > >
> > > #define dolfin_assert(check) {}
> > >
> > > ?
> >
> > Very strange...
> >
> > I just rebuilt DOLFIN without -DDEBUG (setting CMAKE_BUILD_TYPE to
> > Release and verifying using make VERBOSE=1 that the -DDEBUG option is
> > not present) but it still works fine here.
> >
> > Is anyone else seeing this?
> >
> >
> >
> > If you still need help, you can reply to this email or go to the
> > following page to enter your feedback:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > You received this question notification because you asked the question.
> >
>

An annoying thing with optimization errors is that when you start to
sprinkle the code with cout's, the error tends to go away (probably because
the optimizer cannot be as aggressive anymore). There is no problem with
the subdomain marker. Something goes wrong inside the
init_from_meshfunction facet iterator loop, but if I put a cout there, then
it works no matter what. I guess this error is compiler dependent and only
other people using the same compiler as I, c++ (Ubuntu/Linaro
4.5.2-8ubuntu4) 4.5.2, will have the same problems. This is the standard
compiler on ubuntu 11.04, though, so I'm surprised no one else seems to
have this problem?

M

On 26 November 2011 20:25, Anders Logg <<email address hidden>
> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Anders Logg proposed the following answer:
> Can you try printing some stuff from within SubDomain.cpp?
>
> Replace apply_markers in SubDomain.cpp with the following code:
>
> void SubDomain::apply_markers(S& sub_domains,
> T sub_domain,
> const Mesh& mesh) const
> {
> log(TRACE, "Computing sub domain markers for sub domain %d.",
> sub_domain);
>
> // Get the dimension of the entities we are marking
> const uint dim = sub_domains.dim();
>
> // Compute facet - cell connectivity if necessary
> const uint D = mesh.topology().dim();
> if (dim == D - 1)
> {
> mesh.init(D - 1);
> mesh.init(D - 1, D);
> }
>
> // Set geometric dimension (needed for SWIG interface)
> _geometric_dimension = mesh.geometry().dim();
>
> // Always false when not marking facets
> bool on_boundary = false;
>
> // Extract exterior (non shared) facets markers
> const MeshFunction<bool>& exterior =
> mesh.parallel_data().exterior_facet();
>
> // Array for vertex coordinate
> Array<double> x;
>
> // Compute sub domain markers
> Progress p("Computing sub domain markers", mesh.num_entities(dim));
> for (MeshEntityIterator entity(mesh, dim); !entity.end(); ++entity)
> {
> // Check if entity is on the boundary if entity is a facet
> if (dim == D - 1)
> {
> on_boundary = entity->num_entities(D) == 1 &&
> (exterior.size() == 0 || exterior[*entity]);
> }
>
> // Start by assuming all points are inside
> bool all_points_inside = true;
>
> cout << "checking entity " << *entity << endl;
>
> // Check all incident vertices if dimension is > 0 (not a vertex)
> if (entity->dim() > 0)
> {
> for (VertexIterator vertex(*entity); !vertex.end(); ++vertex)
> {
> x.update(_geometric_dimension,
> const_cast<double*>(vertex->x()));
> if (!inside(x, on_boundary))
> {
> all_points_inside = false;
> break;
> }
> }
> }
>
> // Check midpoint (works also in the case when we have a single
> vertex)
> if (all_points_inside)
> {
> cout << " yes, now checking midpoint" << endl;
>
> x.update(_geometric_dimension,
> const_cast<double*>(entity->midpoint().coordinates()));
> if (!inside(x, on_boundary))
> all_points_inside = false;
> }
>
> // Mark entity with all vertices inside
> if (all_points_inside)
> {
> cout << " yes, marking entity " << entity->index() << " as " <<
> sub_domain << endl;
> sub_domains.set_value(entity->index(), sub_domain, mesh);
> }
>
> p++;
> }
> }
>
> Also try to reduce the test code to the smallest possible problem that
> still gives you the error. For a start, only include the scalar case
> and just call sub_domain.mark() with a MeshFunction if that is where
> it goes wrong.
>
> --
> Anders
>
>
> On Sat, Nov 26, 2011 at 12:50:48PM -0000, Mikael Mortensen wrote:
> > Question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Status: Answered => Open
> >
> > Mikael Mortensen is still having a problem:
> > Looks like an optimization error. I reduced the optimization flag to -O1
> > and the problem is gone, even without the DEBUG flag. With -O2 the
> problem
> > returns.
> >
> > M
> >
> > On 26 November 2011 10:31, Anders Logg <
> <email address hidden>
> > > wrote:
> >
> > > Your question #179849 on DOLFIN changed:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > Status: Open => Answered
> > >
> > > Anders Logg proposed the following answer:
> > > On Fri, Nov 25, 2011 at 06:45:48PM -0000, Anders Logg wrote:
> > > > Question #179849 on DOLFIN changed:
> > > > https://answers.launchpad.net/dolfin/+question/179849
> > > >
> > > > Anders Logg proposed the following answer:
> > > > Then it looks like you are building DOLFIN *without* the DEBUG flag
> > > > and the macro is not correctly defined in the #else case.
> > > >
> > > > So something goes wrong with this macro somewhere in the code:
> > > >
> > > > #define dolfin_assert(check)
> > > >
> > > > Does it help if you change back to how they were and then replace the
> > > > above line with
> > > >
> > > > #define dolfin_assert(check) {}
> > > >
> > > > ?
> > >
> > > Very strange...
> > >
> > > I just rebuilt DOLFIN without -DDEBUG (setting CMAKE_BUILD_TYPE to
> > > Release and verifying using make VERBOSE=1 that the -DDEBUG option is
> > > not present) but it still works fine here.
> > >
> > > Is anyone else seeing this?
> > >
> > >
> > >
> > > If you still need help, you can reply to this email or go to the
> > > following page to enter your feedback:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > You received this question notification because you asked the question.
> > >
> >
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/dolfin/+question/179849/+confirm?answer_id=17
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/dolfin/+question/179849
>
> You received this question notification because you asked the question.
>

On Sun, Nov 27, 2011 at 08:30:54PM -0000, Mikael Mortensen wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Answered => Open
>
> Mikael Mortensen is still having a problem:
> An annoying thing with optimization errors is that when you start to
> sprinkle the code with cout's, the error tends to go away (probably
> because the optimizer cannot be as aggressive anymore). There is no
> problem with the subdomain marker. Something goes wrong inside the
> init_from_meshfunction facet iterator loop, but if I put a cout
> there, then it works no matter what. I guess this error is compiler
> dependent and only other people using the same compiler as I, c++
> (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2, will have the same
> problems. This is the standard compiler on ubuntu 11.04, though, so
> I'm surprised no one else seems to have this problem?

Me too.

Anyway, I don't know how to handle this bug if I'm not able to
reproduce it.

Maybe Johannes could try on the buildbot running Ubuntu 11.04?

--
Anders

> M
>
>
> On 26 November 2011 20:25, Anders Logg <<email address hidden>
> > wrote:
>
> > Your question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Anders Logg proposed the following answer:
> > Can you try printing some stuff from within SubDomain.cpp?
> >
> > Replace apply_markers in SubDomain.cpp with the following code:
> >
> > void SubDomain::apply_markers(S& sub_domains,
> > T sub_domain,
> > const Mesh& mesh) const
> > {
> > log(TRACE, "Computing sub domain markers for sub domain %d.",
> > sub_domain);
> >
> > // Get the dimension of the entities we are marking
> > const uint dim = sub_domains.dim();
> >
> > // Compute facet - cell connectivity if necessary
> > const uint D = mesh.topology().dim();
> > if (dim == D - 1)
> > {
> > mesh.init(D - 1);
> > mesh.init(D - 1, D);
> > }
> >
> > // Set geometric dimension (needed for SWIG interface)
> > _geometric_dimension = mesh.geometry().dim();
> >
> > // Always false when not marking facets
> > bool on_boundary = false;
> >
> > // Extract exterior (non shared) facets markers
> > const MeshFunction<bool>& exterior =
> > mesh.parallel_data().exterior_facet();
> >
> > // Array for vertex coordinate
> > Array<double> x;
> >
> > // Compute sub domain markers
> > Progress p("Computing sub domain markers", mesh.num_entities(dim));
> > for (MeshEntityIterator entity(mesh, dim); !entity.end(); ++entity)
> > {
> > // Check if entity is on the boundary if entity is a facet
> > if (dim == D - 1)
> > {
> > on_boundary = entity->num_entities(D) == 1 &&
> > (exterior.size() == 0 || exterior[*entity]);
> > }
> >
> > // Start by assuming all points are inside
> > bool all_points_inside = true;
> >
> > cout << "checking entity " << *entity << endl;
> >
> > // Check all incident vertices if dimension is > 0 (not a vertex)
> > if (entity->dim() > 0)
> > {
> > for (VertexIterator vertex(*entity); !vertex.end(); ++vertex)
> > {
> > x.update(_geometric_dimension,
> > const_cast<double*>(vertex->x()));
> > if (!inside(x, on_boundary))
> > {
> > all_points_inside = false;
> > break;
> > }
> > }
> > }
> >
> > // Check midpoint (works also in the case when we have a single
> > vertex)
> > if (all_points_inside)
> > {
> > cout << " yes, now checking midpoint" << endl;
> >
> > x.update(_geometric_dimension,
> > const_cast<double*>(entity->midpoint().coordinates()));
> > if (!inside(x, on_boundary))
> > all_points_inside = false;
> > }
> >
> > // Mark entity with all vertices inside
> > if (all_points_inside)
> > {
> > cout << " yes, marking entity " << entity->index() << " as " <<
> > sub_domain << endl;
> > sub_domains.set_value(entity->index(), sub_domain, mesh);
> > }
> >
> > p++;
> > }
> > }
> >
> > Also try to reduce the test code to the smallest possible problem that
> > still gives you the error. For a start, only include the scalar case
> > and just call sub_domain.mark() with a MeshFunction if that is where
> > it goes wrong.
> >
> >
> >
> > On Sat, Nov 26, 2011 at 12:50:48PM -0000, Mikael Mortensen wrote:
> > > Question #179849 on DOLFIN changed:
> > > https://answers.launchpad.net/dolfin/+question/179849
> > >
> > > Status: Answered => Open
> > >
> > > Mikael Mortensen is still having a problem:
> > > Looks like an optimization error. I reduced the optimization flag to -O1
> > > and the problem is gone, even without the DEBUG flag. With -O2 the
> > problem
> > > returns.
> > >
> > > M
> > >
> > > On 26 November 2011 10:31, Anders Logg <
> > <email address hidden>
> > > > wrote:
> > >
> > > > Your question #179849 on DOLFIN changed:
> > > > https://answers.launchpad.net/dolfin/+question/179849
> > > >
> > > > Status: Open => Answered
> > > >
> > > > Anders Logg proposed the following answer:
> > > > On Fri, Nov 25, 2011 at 06:45:48PM -0000, Anders Logg wrote:
> > > > > Question #179849 on DOLFIN changed:
> > > > > https://answers.launchpad.net/dolfin/+question/179849
> > > > >
> > > > > Anders Logg proposed the following answer:
> > > > > Then it looks like you are building DOLFIN *without* the DEBUG flag
> > > > > and the macro is not correctly defined in the #else case.
> > > > >
> > > > > So something goes wrong with this macro somewhere in the code:
> > > > >
> > > > > #define dolfin_assert(check)
> > > > >
> > > > > Does it help if you change back to how they were and then replace the
> > > > > above line with
> > > > >
> > > > > #define dolfin_assert(check) {}
> > > > >
> > > > > ?
> > > >
> > > > Very strange...
> > > >
> > > > I just rebuilt DOLFIN without -DDEBUG (setting CMAKE_BUILD_TYPE to
> > > > Release and verifying using make VERBOSE=1 that the -DDEBUG option is
> > > > not present) but it still works fine here.
> > > >
> > > > Is anyone else seeing this?
> > > >
> > > >
> > > >
> > > > If you still need help, you can reply to this email or go to the
> > > > following page to enter your feedback:
> > > > https://answers.launchpad.net/dolfin/+question/179849
> > > >
> > > > You received this question notification because you asked the question.
> > > >
> > >
> >
> >
> > If you still need help, you can reply to this email or go to the
> > following page to enter your feedback:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > You received this question notification because you asked the question.
> >
>

There is no buildbot running 11.04 (only 10.04 and 11.10), but I have some other environments with 11.04 where I can try to reproduce the bug. It will take some time to install everything. I will let you know when it's done.

On Mon, Nov 28, 2011 at 12:55:45PM -0000, Johannes Ring wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Johannes Ring posted a new comment:
> There is no buildbot running 11.04 (only 10.04 and 11.10), but I
> have some other environments with 11.04 where I can try to reproduce
> the bug. It will take some time to install everything. I will let
> you know when it's done.

ok thanks!

--
Anders

I could not reproduce this in Ubuntu 11.04 (either 32 or 64 bits) with the exact same compiler as reported by Mikael (c++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2). The testing was done in a clean (pbuilder) build environment with a minimal set of packages installed before following the instructions for Dorsal/natty.platform to build DOLFIN from trunk.

Then I guess my computer is ill and you should simply forget about this. I
will replace my computer in two weeks time anyway. Thanks for all the help.

M

On 28 November 2011 16:45, Johannes Ring <
<email address hidden>> wrote:

> Your question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Johannes Ring posted a new comment:
> I could not reproduce this in Ubuntu 11.04 (either 32 or 64 bits) with
> the exact same compiler as reported by Mikael (c++ (Ubuntu/Linaro
> 4.5.2-8ubuntu4) 4.5.2). The testing was done in a clean (pbuilder) build
> environment with a minimal set of packages installed before following
> the instructions for Dorsal/natty.platform to build DOLFIN from trunk.
>
> --
> You received this question notification because you asked the question.
>

ok! Then I'm closing this bug report. Open it again if the problem
should appear on your new machine.

--
Anders

On Mon, Nov 28, 2011 at 03:55:47PM -0000, Mikael Mortensen wrote:
> Question #179849 on DOLFIN changed:
> https://answers.launchpad.net/dolfin/+question/179849
>
> Status: Answered => Open
>
> Mikael Mortensen is still having a problem:
> Then I guess my computer is ill and you should simply forget about this. I
> will replace my computer in two weeks time anyway. Thanks for all the help.
>
> M
>
> On 28 November 2011 16:45, Johannes Ring <
> <email address hidden>> wrote:
>
> > Your question #179849 on DOLFIN changed:
> > https://answers.launchpad.net/dolfin/+question/179849
> >
> > Johannes Ring posted a new comment:
> > I could not reproduce this in Ubuntu 11.04 (either 32 or 64 bits) with
> > the exact same compiler as reported by Mikael (c++ (Ubuntu/Linaro
> > 4.5.2-8ubuntu4) 4.5.2). The testing was done in a clean (pbuilder) build
> > environment with a minimal set of packages installed before following
> > the instructions for Dorsal/natty.platform to build DOLFIN from trunk.
> >
> >
>