Re: [Libmesh-users] Wrong implementation of n_dofs() used

[Roy S. <roy...@ic...>]

Copying this to libmesh-devel and libmesh-users; I don't think I see
the answer (or even any productive way to debug such a problem)
myself, I'm afraid...

On Mon, 28 Feb 2011, Andreas Günther wrote:

> the Libmesh problem I observe reminds me of the problem described in
>
> http://www.mail-archive.com/lib...@li.../msg02728.html
>
> but I'm not sure about if its caused by the same thing.
>
> For test purposes I check, if a point in 3D is inside a certain hexahedron. 
> For certain points I get wrong results. Debugging my program reveals that
>
> const unsigned int n_sf = FE<Dim,LAGRANGE>::n_shape_functions(type, order);
>
> in line 538 of fe-map.cpp is 4 instead of 8 (for HEX8, FIRST). This is

fe_map.C, I assume?

> because the later called n_dofs-function jumps into the implementation of 
> fe_xyz.cpp instead of fe_lagrange.cpp although the template parameters are 3, 
> LAGRANGE. The compiler doesn't complain. It seams to be a linkage problem for 
> the several implemented n_dofs-functions.
>
> The strange thing is, that this problem is not observed in a 
> libmesh-stand-alone-testprogram (statically linked).

How about in the libMesh test programs when dynamically linked?  We
don't run any 3D examples by default but there are several that can be
switched to use HEX8 by tweaking a config file.

> I'd like to use libmesh inside another software, so I recompiled the
> whole library and load the shared objected whenever needed. Under a
> Windows machine even this worked fine. But under Linux I get this
> run-time garbage.
>
> I am using gcc version 4.3.2 within an AMD64-machine.
>
> Investigating the shared objects
>
> nm liblibmesh.so (library for other software)
>
> and
>
> nm libmesh.so (stand-alone)
>
> provide the same "Weak-Symbols" for n_dofs:
>
> 000000000040d046 W libMesh::FE<0u, 
> (libMeshEnums::FEFamily)0>::n_dofs(libMeshEnums::ElemType, 
> libMeshEnums::Order)
>
> 00000000004392f4 W libMesh::FE<0u, 
> (libMeshEnums::FEFamily)1>::n_dofs(libMeshEnums::ElemType, 
> libMeshEnums::Order)
>
> ....
>
> in the same order. So maybe (since the compiler doesn't complain) the 
> so-files are okay and its truely a linkage problem.(?)

Just to double-check, that "...." includes the FE<3u,etcetera>::n_dofs
versions too, right?

> Could it be a compiler flag-issue, since our software tells Libmesh how to 
> build (and not the configure-script)?

Try building libMesh in devel mode and see if the problem still occurs
there too?  If it does then at least it might be easier to see the
intermediate stages of what's going wrong.

Otherwise I'm not sure what's to be done short of running the object
files through a disassembler and seeing whether the compiler or the
linker has messed up.

> Does my observed problem reminds you of a certain flag, I have
> missed out?

I'm afraid not.  We hardcode the values of the FEFamily enums to the
same numbers regardless of configure options, so even if you had
different object files being compiled with different flags, it still
shouldn't have effected how n_dofs gets dispatched.

I guess that's a virtual function call, though... so perhaps if the
FE headers got compiled with completely different options in different
object files, the vtable usage might be completely screwed up?  I'd
still think that as long as everything was using the same
libmesh_config.h then you'd be fine.

...

Whatever build system you've replaced our configure script with, it
does generate a valid libmesh_config.h?
---
Roy