Hi Wolfgang, Thank you for that response. I have followed up on the CellSimilarity compile error and just to confirm the syntax error you refer to was due to my earlier debugging attempts (I had tried to declare a CellSimilarity enum for it to find in the fe_system.h file). The true error that I am seeing is:
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:688: 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:688: error: template declaration of `enum dealii::/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II/include/fe/fe_update_flags.h' /CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II/include/fe/fe_system.h:688: confused by earlier errors, bailing out make[1]: *** [/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/lib/2d/fe_fe_system_2d.g.o] Error 1 make[1]: Leaving directory `/CHPC/home/mrapson/lib/gcc/deal.II-6.2.1/deal.II' make: *** [2dg] Error 2 I found the CellSimilarity enum defined in fe_update_flags.h as you suggested and have verified that the relevant .dep includes both fe_update_flags.h and fe_system.h so the declarations should be visible. I see that CellSimilarity is used in an earlier function and the only difference in how functions are setup is that fill_fe_values does not have a dim_1 template parameter, and has an & before cell_similarity where as compute_fill has dim_1 template parameter and no &. The & difference shouldn't matter because the underlying type is an int right? This leaves the template parameter to investigate? Concerning the trilinos. Both deal.II and trilinos were installed with mpi, but trilinos I used the --with-mpi-incdir=/... --with-mpi-libdir=/... rather than --with-mpi. I am now testing building trilinos with openmpi and with the --with-mpi switch as well, in case it is important for installing the mpi headers. I will send you my code for MonitorNode and a test case in a separate email. Thanks, Michael On Thu, Jun 11, 2009 at 6:05 PM, Michael Rapson<[email protected]> wrote: > 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
