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

OK, can you check in the modification together with a comment like
   // TODO: On Mac OS X, shared libs can only depend on
   // other libs listed later on the command line. This means that
   // libbase can't depend on liblac, and we can't destroy the memory
   // pool here as long as we have separate libraries

The issue is probably rare since it only affects people who are using 
Trilinos and MPI on Macs.


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

Something is calling MPI_Comm_size before MPI_Init. Can you try to find out 
where this is?

That said, I think step-31 wasn't meant to be run with MPI, so we don't 
initialize MPI at all in this program. The question then is why we ever 
call MPI_Comm_size...


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

This is a follow-up error on the previous one. Fix the first one and this 
one will likely go away.

Best
 W.

-------------------------------------------------------------------------
Wolfgang Bangerth                email:            [email protected]
                                 www: http://www.math.tamu.edu/~bangerth/

_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii

Reply via email to