From: Mladen J. <ju...@ma...> - 2010-05-25 17:56:29
|
Dear Libmesh team, I cannot build the library from the SVN repository on Debian system. File "include/base/libmesh_config.h" contains special characters after each "LIBMESH_" identifier, which prevents the compilation. Any ideas what might be the problem? Thanks, Mladen JURAK |
From: John P. <pet...@cf...> - 2010-05-25 18:03:32
|
On Tue, May 25, 2010 at 12:34 PM, Mladen Jurak <ju...@ma...> wrote: > Dear Libmesh team, > > I cannot build the library from the SVN repository on Debian system. > File "include/base/libmesh_config.h" contains special characters after > each "LIBMESH_" identifier, which prevents the compilation. > Any ideas what might be the problem? What special characters? You did run configure, right? -- John |
From: Mladen J. <ju...@ma...> - 2010-05-25 18:30:43
|
On 25.05.2010 20:03, John Peterson wrote: > On Tue, May 25, 2010 at 12:34 PM, Mladen Jurak<ju...@ma...> wrote: > >> Dear Libmesh team, >> >> I cannot build the library from the SVN repository on Debian system. >> File "include/base/libmesh_config.h" contains special characters after >> each "LIBMESH_" identifier, which prevents the compilation. >> Any ideas what might be the problem? >> > What special characters? > > You did run configure, right? > > Yes, I did. As I understand it is configure that generates the file. In libmesh_config.h I get something like this: #ifndef LIBMESH_^A #define LIBMESH_^A ^B Regards, Mladen |
From: Zeljka <ze...@ge...> - 2010-05-26 08:55:10
|
> In libmesh_config.h I get something like this: > #ifndef LIBMESH_^A > #define LIBMESH_^A ^B What does comment before these to lines say? I've compiled libmesh from trunk right now without any problems. Zeljka |
From: Mladen J. <ju...@ma...> - 2010-05-26 12:02:36
|
On 25.05.2010 20:03, John Peterson wrote: > On Tue, May 25, 2010 at 12:34 PM, Mladen Jurak<ju...@ma...> wrote: > >> Dear Libmesh team, >> >> I cannot build the library from the SVN repository on Debian system. >> File "include/base/libmesh_config.h" contains special characters after >> each "LIBMESH_" identifier, which prevents the compilation. >> Any ideas what might be the problem? >> > What special characters? > > You did run configure, right? > > Dear Libmesh team. I located the problem that I have in compiling the library. It is in configure file. The line echo "s/#undef *\\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]\\)/#undef $ac_prefix_conf_UPP""_\\1/" > conftest.prefix and the following similar lines (form the line 15838 in configure file) are executed under /bin/sh instead of /bin/bash, and /bin/sh does not interprete \\1 correctly. That is the reason why I have "include/base/libmesh_config.h" file corrupted. I have no idea why this is happening. Regards, Mladen |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2010-05-26 13:47:52
|
On 5/26/10 7:02 AM, "Mladen Jurak" <ju...@ma...> wrote: > On 25.05.2010 20:03, John Peterson wrote: >> On Tue, May 25, 2010 at 12:34 PM, Mladen Jurak<ju...@ma...> wrote: >> >>> Dear Libmesh team, >>> >>> I cannot build the library from the SVN repository on Debian system. >>> File "include/base/libmesh_config.h" contains special characters after >>> each "LIBMESH_" identifier, which prevents the compilation. >>> Any ideas what might be the problem? >>> >> What special characters? >> >> You did run configure, right? >> >> > Dear Libmesh team. > > I located the problem that I have in compiling the library. > It is in configure file. The line > echo "s/#undef *\\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]\\)/#undef > $ac_prefix_conf_UPP""_\\1/" > conftest.prefix > and the following similar lines (form the line 15838 in configure file) > are executed under /bin/sh instead of /bin/bash, and /bin/sh does not > interprete \\1 correctly. > That is the reason why I have "include/base/libmesh_config.h" file > corrupted. Can you regenerate the configure sccript on your platform? $ autoconf $ autoheader in the top-level source? I have no idea why this is happening either, but it *may* be that rebuilding the script with the autotools on your platform will fix the issue. -Ben |
From: John P. <pet...@cf...> - 2010-05-26 14:34:43
|
On Wed, May 26, 2010 at 8:47 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > On 5/26/10 7:02 AM, "Mladen Jurak" <ju...@ma...> wrote: > >> On 25.05.2010 20:03, John Peterson wrote: >>> On Tue, May 25, 2010 at 12:34 PM, Mladen Jurak<ju...@ma...> wrote: >>> >>>> Dear Libmesh team, >>>> >>>> I cannot build the library from the SVN repository on Debian system. >>>> File "include/base/libmesh_config.h" contains special characters after >>>> each "LIBMESH_" identifier, which prevents the compilation. >>>> Any ideas what might be the problem? >>>> >>> What special characters? >>> >>> You did run configure, right? >>> >>> >> Dear Libmesh team. >> >> I located the problem that I have in compiling the library. >> It is in configure file. The line >> echo "s/#undef *\\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]\\)/#undef >> $ac_prefix_conf_UPP""_\\1/" > conftest.prefix >> and the following similar lines (form the line 15838 in configure file) >> are executed under /bin/sh instead of /bin/bash, and /bin/sh does not >> interprete \\1 correctly. >> That is the reason why I have "include/base/libmesh_config.h" file >> corrupted. > > Can you regenerate the configure sccript on your platform? > > $ autoconf > $ autoheader > > in the top-level source? > > I have no idea why this is happening either, but it *may* be that rebuilding > the script with the autotools on your platform will fix the issue. Actually if you try this, better run the "bootstrap" script in the top-level libmesh directory. -- John |
From: Mladen J. <ju...@ma...> - 2010-05-26 15:52:23
|
On 26.05.2010 16:33, John Peterson wrote: > On Wed, May 26, 2010 at 8:47 AM, Kirk, Benjamin (JSC-EG311) > <ben...@na...> wrote: > >> On 5/26/10 7:02 AM, "Mladen Jurak"<ju...@ma...> wrote: >> >> >>> On 25.05.2010 20:03, John Peterson wrote: >>> >>>> On Tue, May 25, 2010 at 12:34 PM, Mladen Jurak<ju...@ma...> wrote: >>>> >>>> >>>>> Dear Libmesh team, >>>>> >>>>> I cannot build the library from the SVN repository on Debian system. >>>>> File "include/base/libmesh_config.h" contains special characters after >>>>> each "LIBMESH_" identifier, which prevents the compilation. >>>>> Any ideas what might be the problem? >>>>> >>>>> >>>> What special characters? >>>> >>>> You did run configure, right? >>>> >>>> >>>> >>> Dear Libmesh team. >>> >>> I located the problem that I have in compiling the library. >>> It is in configure file. The line >>> echo "s/#undef *\\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]\\)/#undef >>> $ac_prefix_conf_UPP""_\\1/"> conftest.prefix >>> and the following similar lines (form the line 15838 in configure file) >>> are executed under /bin/sh instead of /bin/bash, and /bin/sh does not >>> interprete \\1 correctly. >>> That is the reason why I have "include/base/libmesh_config.h" file >>> corrupted. >>> >> Can you regenerate the configure sccript on your platform? >> >> $ autoconf >> $ autoheader >> >> in the top-level source? >> >> I have no idea why this is happening either, but it *may* be that rebuilding >> the script with the autotools on your platform will fix the issue. >> > Actually if you try this, better run the "bootstrap" script in the > top-level libmesh directory. > > Running bootstrap didn't help. The problem is that configure file takes the first existing shell from the sequence "sh bash ksh sh5", so it usually takes sh. On my system (Debian/squeeze) sh=dash and this is an inadequate choice. I solved it by changing the order of the shell sequence to "bash ksh sh5 sh". Regards, Mladen |
From: John P. <pet...@cf...> - 2010-05-26 15:55:24
|
On Wed, May 26, 2010 at 10:52 AM, Mladen Jurak <ju...@ma...> wrote: > > Running bootstrap didn't help. > > The problem is that configure file takes the first existing shell > from the sequence "sh bash ksh sh5", so it usually takes sh. On my > system (Debian/squeeze) sh=dash and this is an inadequate choice. I solved > it by changing the order of the shell sequence to "bash ksh sh5 sh". Very interesting! So is the dash shell (I've never heard of it) not sh-compatible, or is our configure script generating a bash-specific script? -- John |
From: Mladen J. <ju...@ma...> - 2010-05-26 16:04:54
|
On 26.05.2010 17:54, John Peterson wrote: > On Wed, May 26, 2010 at 10:52 AM, Mladen Jurak<ju...@ma...> wrote: > >> Running bootstrap didn't help. >> >> The problem is that configure file takes the first existing shell >> from the sequence "sh bash ksh sh5", so it usually takes sh. On my >> system (Debian/squeeze) sh=dash and this is an inadequate choice. I solved >> it by changing the order of the shell sequence to "bash ksh sh5 sh". >> > Very interesting! So is the dash shell (I've never heard of it) not > sh-compatible, or is our configure script generating a bash-specific > script? > > Dash is something new for me too. The man page says: dash is the standard command interpreter for the system. The current version of dash is in the process of being changed to conform with the POSIX 1003.2 and 1003.2a specifications for the shell. This version has many features which make it appear similar in some respects to the Korn shell, but it is not a Korn shell clone (see ksh(1)). Only features designated by POSIX, plus a few Berkeley extensions, are being incorporated into this shell. |
From: John P. <pet...@cf...> - 2010-05-26 16:09:17
|
On Wed, May 26, 2010 at 11:04 AM, Mladen Jurak <ju...@ma...> wrote: > On 26.05.2010 17:54, John Peterson wrote: >> On Wed, May 26, 2010 at 10:52 AM, Mladen Jurak<ju...@ma...> wrote: >> >>> Running bootstrap didn't help. >>> >>> The problem is that configure file takes the first existing shell >>> from the sequence "sh bash ksh sh5", so it usually takes sh. On my >>> system (Debian/squeeze) sh=dash and this is an inadequate choice. I solved >>> it by changing the order of the shell sequence to "bash ksh sh5 sh". >>> >> Very interesting! So is the dash shell (I've never heard of it) not >> sh-compatible, or is our configure script generating a bash-specific >> script? >> >> > Dash is something new for me too. The man page says: > > dash is the standard command interpreter for the system. > The current version of dash is in the process of being changed to conform > with the POSIX 1003.2 and 1003.2a specifications for the shell. This > version Hrm... sounds like it might not be 100% perfect yet but 1003.2 -> 1003.2a seems like it should be a pretty small change?! In any case, I'm glad you were able to find the workaround, hopefully this thread will pop up for anyone searching about this issue in the future... -- John |
From: Liang C. <goe...@gm...> - 2010-05-28 16:30:22
|
Hi Developers, Questions again, I made a small deformation elastic problem with Great libmesh, then extended it to the Large Deformation. A couple of arrays are introduced to accommodate the deformation gradient, elastic module and so on, which are defined as following, std::vector<Real> F; // deformation gradient //spatial elastic modulus c_ijkl 6x6 = aa[][] std::vector<std::vector<Real> > aa; aa.resize(6); for (int i = 0; i < 6; ++i) aa[i].resize(6); for(int i=0;i<6;i++){ for (int j=0;j<6;j++){ aa[j][i] = 0.0; } } Now the errors below bother me, which looks like container problem. did I make mistake on declaring the container? My data structure background is pretty weak. Thanks for any gives. Bests, Liang ++++++++++++++++ output in screen +++++++++++++++++ liang@liang-laptop:~/lib/libmesh/libmesh_liang/ldm3d_v7$ mpirun -np 2 ./ldm3d_v7-dbg Running ./ldm3d_v7-dbg Mesh Information: mesh_dimension()=3 spatial_dimension()=3 n_nodes()=1331 n_local_nodes()=735 n_elem()=1000 n_local_elem()=500 n_active_elem()=1000 n_subdomains()=1 n_processors()=2 processor_id()=0 EquationSystems n_systems()=1 System "largeDeform_disp_3d" Type "TransientLinearImplicit" Variables="u0" "u1" "u2" "v0" "v1" "v2" Finite Element Types="LAGRANGE" "LAGRANGE" "LAGRANGE" "LAGRANGE" "LAGRANGE" "LAGRANGE" Approximation Orders="FIRST" "FIRST" "FIRST" "FIRST" "FIRST" "FIRST" n_dofs()=7986 n_local_dofs()=4410 n_constrained_dofs()=0 n_vectors()=3 Solving time step 0, time=0.00100... /usr/include/c++/4.4/debug/vector:265:error: attempt to subscript /usr/include/c++/4.4/debug/vector:265:error: attempt to subscript container with out-of-bounds index 0, but container only holds 0 elements. Objects involved in the operation: sequence "this" @ 0x0xbfc77c88 { type = NSt7__debug6vectorIdSaIdEEE; } container with out-of-bounds index 0, but container only holds 0 elements. Objects involved in the operation: sequence "this" @ 0x0xbfe1ccd8 { type = NSt7__debug6vectorIdSaIdEEE; } rank 1 in job 4 liang-laptop_34550 caused collective abort of all ranks exit status of rank 1: killed by signal 9 |
From: Liang C. <goe...@gm...> - 2010-05-28 19:12:43
|
This problem lies in the user-defined array "dphi_fwd[][]", which is set as std::vector<std::vector<RealGradient> >. Because the program is able to run when I drop off all "dphi_fwd" arrays. This dphi_fwd[][] is updated in different quadrature points and varied with time. So my question is setting up this sort of RealGradient array to take part in the computation. I suppose the system given dphi[][] comes from the reference of fe->get_dphi(), this is should be unchanged. Is any ideal way to build up this array, which could be updated and memory-saving? Thanks in advance. Bests, Liang |
From: Shiyuan Gu <sg...@an...> - 2012-09-14 22:49:00
|
Hi all, I tried to build libmesh but failed with the following error. Compiling C++ (in debug mode) src/solvers/petsc_linear_solver.C... src/solvers/petsc_linear_solver.C: In member function ‘void libMesh::PetscLinearSolver<T>::set_petsc_solver_type()’: src/solvers/petsc_linear_solver.C:1757: error: ‘KSPCHEBYCHEV’ was not declared in this scope Compiling C++ (in debug mode) src/solvers/petsc_nonlinear_solver.C... make: *** [src/solvers/petsc_linear_solver.x86_64-apple-darwin10.8.0.dbg.o] Error 1 make: *** Waiting for unfinished jobs.... What might go wrong? The config.log is attached. Thanks. Shiyuan |
From: Roy S. <roy...@ic...> - 2012-09-14 23:01:00
|
On Fri, 14 Sep 2012, Shiyuan Gu wrote: > I tried to build libmesh but failed with the following error. > > Compiling C++ (in debug mode) src/solvers/petsc_linear_solver.C... > src/solvers/petsc_linear_solver.C: In member function ‘void > libMesh::PetscLinearSolver<T>::set_petsc_solver_type()’: > src/solvers/petsc_linear_solver.C:1757: error: ‘KSPCHEBYCHEV’ was not > declared in this scope > Compiling C++ (in debug mode) src/solvers/petsc_nonlinear_solver.C... This looks like what happens when trying to use older libMesh versions with PETSc 3.3, but the problem should be fixed in the svn head and backported into libMesh 0.7.3.2. What libMesh and what PETSc versions are you using? --- Roy |