Hi all,
I am once again installing deal.II on unusual systems and am running
into unexpected difficulties.
When compiling on a cluster that offers pathscale compilers (which use
a GCC 3.3.3 front end) I run into an error:
In file included from source/fe/fe_system.cc:21:
/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II/include/fe/fe_system.h:85:
error: syntax error before `{' token
/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II/include/fe/fe_system.h:692:
error: use of enum `enum dealii::CellSimilarity::Similarity' without
previous declaration
/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II/include/fe/fe_system.h:692:
error: template declaration of `enum
dealii::/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II/include/fe/fe_update_flags.h'
I have looked for where 'enum dealii::CellSimilarity::Similarity' is
defined but cannot find it. Doxygen is however able to find it and
provide a reference to the possible values that it can take on. Do
some compilers allow enums to be used without been declared or am I
missing something?
On another system which uses gcc 4.1.2 and mpich2 the above problem
does not occur, however the Epetra_MpiComm.h header file is needed for
liblac.so and it does not seem to be copied to the trilinos install
path by default. I have copied it to the trilinos install directory by
hand (along with the other Epetra_Mpi... header files which it
references) and the library then compiles. This doesn't seem to be a
good solution however, it has worked previously for me, but on the
most recent compile the linking even step-1 fails with an error
related to liblac and the constructors in Epetra_MpiComm.h. (I am
currently recompiling the library with static linking so can't get the
exact error message right now.) I see that other Epetra headers are
copied by the trilinos install (for example Epetra_Map.h) and are
tested for by the deal.II configure script.
Final comment on compiling the library, when using mpich2 I need to
set my CXXFLAGS=-DMPICH_IGNORE_CXX_SEEK to avoid a bug in the MPI 2
standard (SEEK_SET, SEEK_END and SEEK_CUR defined in two places).
Off the topic of compiler issues all together, I have written a class
called MonitorNode which I find useful and I am wondering if it would
be more widely useful in the library. I haven't seen any classes which
do something similar. Basically the idea is to provide a time plot of
specific points in the mesh. The constructor takes the dof_handler and
FiniteElement as parameters. The user specifies a number of Point
<dim> in mesh that they want to plot and the class finds the closest
actual mesh nodes to the requested Point and works out its global dof
index. For each time step the user passes the class as many solution
and post processed VECTORS as they want to store and the class saves
data from the VECTORS at the desired grid locations. Once the
simulation is complete the user can export the plots to gnuplot
(currently).
This is important functionality for me because the time plot of
variables at specific points is very similar to the physical readings
I will compare to. I am doing a large number of time steps and putting
out a full .vtk solution for each time step is not possible, but I do
still need to be able to see the time function at important points. As
I say, I have code that does this but it will probably need some
touching up to get it in a form to include in the library.
Any ideas about the compilation problems are most appreciated.
Thanks,
Michael
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
