Hi Wolfgang
Thanks for explaining the issue.
I have made the modifications to "base/source/utilites.cc" that you suggested.
Deal now compiles without problem. The code in the examples run to just before
the point of completion and then crash as you would now expect. So the second
suggestion you made does indeed work.
I'm having a problem now running step 31 that needs trilinos. The problem
appears to be a trilinos one however as 16 out of the 124 standard trilinos
tests fail. I'll keep digging around and see what I can find. This appeared to
work fine prior to upgrading to snow leopard. I'm running trilinos 9.03
compiled with openmpi 1.3.4. The error that deal throws (for interests sake) is
============================ Remaking Makefile.dep
==============debug========= step-31.cc
============================ Linking step-31
============================ Running step-31
*** An error occurred in MPI_comm_size
*** before MPI was initialized
*** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)
[macs-mac.local:12076] Abort before MPI_INIT completed successfully; not able
to guarantee that all other processes were killed!
--------------------------------------------------------
An error occurred in line <103> of file <source/subscriptor.cc> in function
virtual dealii::Subscriptor::~Subscriptor()
The violated condition was:
counter == 0
The name and call sequence of the exception was:
ExcInUse (counter, object_info->name(), infostring)
Additional Information:
Object of class N6dealii16StraightBoundaryILi2ELi2EEE is still used by 255
other objects.
from Subscriber N6dealii13TriangulationILi2ELi2EEE
Stacktrace:
-----------
#0 3 libbase.g.6.3.pre.dylib 0x00000001062b9d4c
_ZN6dealii11SubscriptorD2Ev + 686: 3 libbase.g.6.3.pre.dylib
0x00000001062b9d4c _ZN6dealii11SubscriptorD2Ev
#1 4 libdeal_II_2d.g.6.3.pre.dylib 0x00000001006669a6
_ZN6dealii8BoundaryILi2ELi2EED2Ev + 42: 4 libdeal_II_2d.g.6.3.pre.dylib
0x00000001006669a6 _ZN6dealii8BoundaryILi2ELi2EED2Ev
#2 5 libdeal_II_2d.g.6.3.pre.dylib 0x000000010055f724
_ZN6dealii16StraightBoundaryILi2ELi2EED1Ev + 42: 5
libdeal_II_2d.g.6.3.pre.dylib 0x000000010055f724
_ZN6dealii16StraightBoundaryILi2ELi2EED1Ev
#3 6 libSystem.B.dylib 0x00007fff81da5334 __cxa_finalize +
203: 6 libSystem.B.dylib 0x00007fff81da5334 __cxa_finalize
#4 7 libSystem.B.dylib 0x00007fff81da524c exit + 18: 7
libSystem.B.dylib 0x00007fff81da524c exit
#5 8 libmpi.0.dylib 0x0000000107d3aa97 ompi_mpi_abort +
407: 8 libmpi.0.dylib 0x0000000107d3aa97 ompi_mpi_abort
#6 9 libmpi.0.dylib 0x0000000107d2819f
ompi_mpi_errors_are_fatal_comm_handler + 351: 9 libmpi.0.dylib
0x0000000107d2819f ompi_mpi_errors_are_fatal_comm_handler
#7 10 libmpi.0.dylib 0x0000000107d561a6 MPI_Comm_size +
246: 10 libmpi.0.dylib 0x0000000107d561a6 MPI_Comm_size
#8 11 libepetra.dylib 0x0000000107680304
_ZN18Epetra_MpiCommDataC1ERP19ompi_communicator_t + 68: 11 libepetra.dylib
0x0000000107680304
_ZN18Epetra_MpiCommDataC1ERP19ompi_communicator_t
thanks
Andrew
On 02 Dec 2009, at 4:28 AM, Wolfgang Bangerth wrote:
>
> Andrew,
>
>> I've been using the svn version of deal for a while now and have had
>> no problems compiling. About a week or two ago I did an svn update and
>> now I get the linking error below. I have not changed anything in my
>> Trilinos library. I have done a clean install from todays svn release
>> and still get the message.
>>
>> [...]
>>
>>
>> =====base=============debug======MT== Linking library: libbase.g.dylib
>> Undefined symbols: "dealii
>> ::GrowingVectorMemory<dealii::TrilinosWrappers::MPI::Vector>::pool",
>> [...]
>
> Despite pondering about this for some time, I can't really think of a
> good solution for this. The short version of the story is this:
>
> - in lac/vector_memory.cc, we generate a memory pool for vectors
> that may be used in linear solvers, etc.
> - if we configure with Trilinos, such a memory pool is also generated
> for Trilinos vectors
>
> - in base/utilities.cc we initialize and finalize MPI. One thing we have
> noticed is that if one uses the vector memory pool with parallel (MPI)
> Trilinos vectors, then like any of the other memory pools the vectors
> will be de-allocated at the end of the program. However, since at the
> point these de-allocation functions run, MPI has already been terminated,
> the Trilinos vector destructors throw an exception. That's not terrible,
> after all the program is already winding down, but it's at best unpleasant
> to see the same error messages over and over again at the end of each
> program run. So what we do in base/utilities.cc is to de-allocate these
> variables by hand, before we terminate MPI.
>
> This strategy works just fine, but it introduces a dependency of
> libbase.so/dylib on liblac.so/dylib. On linux, this doesn't appear to be
> much of a problem, but it seems to be on mac os x, which only wants
> backward dependencies of all shared libraries on ones that come later
> on the command line -- this is one of the points where it shows that
> darwin is not a modern operating system :-(
>
> I can see two solutions that you may want to try: first, in your
> Makefile you probably current link with libdeal_II_Xd.dylib, liblac.dylib
> and libbase.dylib (in this order). Try linking with libdeal_II_Xd.dylib,
> liblac.dylib, libbase.dylib, liblac.dylib and libbase.dylib and see whether
> that helps. Alternatively, and this would be my preference, we may
> just skip the de-allocation on Mac OS X. To this end, what happens
> if you change line 585 in base/source/utilites.cc to read
> # if defined(DEAL_II_USE_TRILINOS) && !defined(__APPLE__)
> ? Does the linker error go away? If this works, let me know and
> I'll check that in with a comment.
>
> Best
> W.
>
> -------------------------------------------------------------------------
> Wolfgang Bangerth email: [email protected]
> www: http://www.math.tamu.edu/~bangerth/
>
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
