Menu
▾
▴
libmesh-users — General information for libmesh users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(27) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(6) |
Feb
(15) |
Mar
(33) |
Apr
(10) |
May
(46) |
Jun
(11) |
Jul
(21) |
Aug
(15) |
Sep
(13) |
Oct
(23) |
Nov
(1) |
Dec
(8) |
| 2005 |
Jan
(27) |
Feb
(57) |
Mar
(86) |
Apr
(23) |
May
(37) |
Jun
(34) |
Jul
(24) |
Aug
(17) |
Sep
(50) |
Oct
(24) |
Nov
(10) |
Dec
(60) |
| 2006 |
Jan
(47) |
Feb
(46) |
Mar
(127) |
Apr
(19) |
May
(26) |
Jun
(62) |
Jul
(47) |
Aug
(51) |
Sep
(61) |
Oct
(42) |
Nov
(50) |
Dec
(33) |
| 2007 |
Jan
(60) |
Feb
(55) |
Mar
(77) |
Apr
(102) |
May
(82) |
Jun
(102) |
Jul
(169) |
Aug
(117) |
Sep
(80) |
Oct
(37) |
Nov
(51) |
Dec
(43) |
| 2008 |
Jan
(71) |
Feb
(94) |
Mar
(98) |
Apr
(125) |
May
(54) |
Jun
(119) |
Jul
(60) |
Aug
(111) |
Sep
(118) |
Oct
(125) |
Nov
(119) |
Dec
(94) |
| 2009 |
Jan
(109) |
Feb
(38) |
Mar
(93) |
Apr
(88) |
May
(29) |
Jun
(57) |
Jul
(53) |
Aug
(48) |
Sep
(68) |
Oct
(151) |
Nov
(23) |
Dec
(35) |
| 2010 |
Jan
(84) |
Feb
(60) |
Mar
(184) |
Apr
(112) |
May
(60) |
Jun
(90) |
Jul
(23) |
Aug
(70) |
Sep
(119) |
Oct
(27) |
Nov
(47) |
Dec
(54) |
| 2011 |
Jan
(22) |
Feb
(19) |
Mar
(92) |
Apr
(93) |
May
(35) |
Jun
(91) |
Jul
(32) |
Aug
(61) |
Sep
(7) |
Oct
(69) |
Nov
(81) |
Dec
(23) |
| 2012 |
Jan
(64) |
Feb
(95) |
Mar
(35) |
Apr
(36) |
May
(63) |
Jun
(98) |
Jul
(70) |
Aug
(171) |
Sep
(149) |
Oct
(64) |
Nov
(67) |
Dec
(126) |
| 2013 |
Jan
(108) |
Feb
(104) |
Mar
(171) |
Apr
(133) |
May
(108) |
Jun
(100) |
Jul
(93) |
Aug
(126) |
Sep
(74) |
Oct
(59) |
Nov
(145) |
Dec
(93) |
| 2014 |
Jan
(38) |
Feb
(45) |
Mar
(26) |
Apr
(41) |
May
(125) |
Jun
(70) |
Jul
(61) |
Aug
(66) |
Sep
(60) |
Oct
(110) |
Nov
(27) |
Dec
(30) |
| 2015 |
Jan
(43) |
Feb
(67) |
Mar
(71) |
Apr
(92) |
May
(39) |
Jun
(15) |
Jul
(46) |
Aug
(63) |
Sep
(84) |
Oct
(82) |
Nov
(69) |
Dec
(45) |
| 2016 |
Jan
(92) |
Feb
(91) |
Mar
(148) |
Apr
(43) |
May
(58) |
Jun
(117) |
Jul
(92) |
Aug
(140) |
Sep
(49) |
Oct
(33) |
Nov
(85) |
Dec
(40) |
| 2017 |
Jan
(41) |
Feb
(36) |
Mar
(49) |
Apr
(41) |
May
(73) |
Jun
(51) |
Jul
(12) |
Aug
(69) |
Sep
(26) |
Oct
(43) |
Nov
(75) |
Dec
(23) |
| 2018 |
Jan
(86) |
Feb
(36) |
Mar
(50) |
Apr
(28) |
May
(53) |
Jun
(65) |
Jul
(26) |
Aug
(43) |
Sep
(32) |
Oct
(28) |
Nov
(52) |
Dec
(17) |
| 2019 |
Jan
(39) |
Feb
(26) |
Mar
(71) |
Apr
(30) |
May
(73) |
Jun
(18) |
Jul
(5) |
Aug
(10) |
Sep
(8) |
Oct
(24) |
Nov
(12) |
Dec
(34) |
| 2020 |
Jan
(17) |
Feb
(10) |
Mar
(6) |
Apr
(4) |
May
(15) |
Jun
(3) |
Jul
(8) |
Aug
(15) |
Sep
(6) |
Oct
(3) |
Nov
|
Dec
(4) |
| 2021 |
Jan
(4) |
Feb
(4) |
Mar
(21) |
Apr
(14) |
May
(13) |
Jun
(18) |
Jul
(1) |
Aug
(39) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
|
From: Benjamin S. K. <be...@cf...> - 2004-03-31 15:59:51
|
Unfortunately the PGI C++ compiler does not properly handle template specialization, so it won't compile libMesh. I've spoken with their support people, but I think C++ is a low priority for them in general. The good news is that g++ for libMesh should work... Which version of g++ are you working with? I bet the undefined references come from linking without proper PGI C/F77 libraries. Please send me the link error to help verify this. Try this: (assuming bash for your shell) CXX=g++ CC=pgcc F77=pgf77 ./configure make make run_examples (or for csh you need to setenv CXX g++ etc... first, then ./configure) Hopefully that should straighten everything out. Let me know. Also, that link you sent me said that your cluster has the Intel compilers available too. Has PETSc been built with those? If so, you can use the Intel compilers (>= v6) for everything. As a last resort, see if your admin will build PETSc with gcc, then it should all work fine. -Ben Linxiang Wang wrote: > Dear Benjamin S. Kirk: > > I got your email for your webpage, I hope this email didn't annoy you! > > I have a problem with compiling libmesh with PGI c++ compiler. I am trying to use libmesh together with PETSC on a cluster in our university (http://www.dcsc.sdu.dk), PETSC is already there and work fine. It was compiled with PGI compiler together with MPICH. So I try to compile libmesh also with PGI c++ compiler , it doesn't work. > > I switch to GNU g++ compiler , the package was successfully compiled, but when i try to build executable file from any examples, it can not be linked with functions from PETSC and LAPACK, the information is there are some undefinied references to some functions. Could you please give me any hints what might be the reason? > > Thanks a lot! > > Linxiang Wang > Mads Clausen Institute, University of Southern Denmark. > Grundtvigs Alle 150, Sonderborg 6400, Denmark. > Tel: 0045 + 6550 1686 Fax: 0045 + 6550 1660 > > |
|
From: <an...@tn...> - 2004-03-30 01:15:54
|
Benjamin From the methods you suggest, the self-contained one looks best to me, i.e. something along the lines of Benjamin S. Kirk writes: > Perhaps a better option is to have the classes do it internally: for > example, GMVIO would include a private member, > > get_connectivity(const Elem*, std::vector<unsigned int>& conn) > > that does a switch on elem->type() and implements the proper > connectivity for each element type. I kinda prefer this approach in the > interest of keeping proper code in its place. It will also encourage > people to add new formats if they don't have to change a lot of other > classes... Exactly, this would simply be a matter of adapting one file. Looks to me like the way to go. Thanks, Martin |
|
From: <an...@tn...> - 2004-03-27 03:00:46
|
Hi all About a week ago I promised to send a patch for the correct export of QUAD8 elements to GMV. Now I was looking into doing that, and noted some problems / inconsistencies: o is mesh_gmv_support.C obsolete? There, the elements are handled differently than in gmv_IO (no calls to tecplot_connectivity) o should there be a gmv_connectivity function, which delegates to tecplot_connectivity if there is a special case? Or would a generic get_connectivity(se, type) make more sense? (where type is one of ["gmv", "tecplot", "diva", "vtk"]) o There seems to be quite some code duplication, especially in the tecplot_connectivity and vtk_connectivity methods of the different geom/cell_*. It seems that the only difference is that gmv needs a 1 based node numbering. o Is there a reason for the different calling sequences of the tecplot_connectivity and vtk_connectivity methods methods (return values vs. return arguments)? To me it seems that the renumbering / splitting could be handled more generically. What are your thoughts? Martin |
|
From: Denis D. <dan...@ya...> - 2004-03-22 10:59:24
|
It does not help... And more, the libmesh-0.4.2-rc1 acts very well with exactly the same configuration. I am considering to install mpich instead of unimpi as suggested by Martin. Denis On Fri, Mar 19, 2004 at 07:10:55AM -0600, Benjamin S. Kirk wrote: > It looks to me like the space in '-L /home/denis/sci/fblaslapack' might > be doing it. It is probably finding that in your > $PETSC_DIR/bmake/$PETSC_ARCH/packages file. > > Let me know if that helps... > > -Ben |
|
From: Benjamin S. K. <be...@cf...> - 2004-03-21 15:07:16
|
Thanks to John, it looks like libMesh might actually be in future releases of NPACI Rocks! At the beginning of the year John's research was mentioned in the lonestar production mode announcement, which you can read here (and other places): http://www.rocksclusters.org/Press/archives/000011.html Since TACC (the supercomputing group at the University of Texas) is an NPACI partner it looks like libMesh might be in future releases of NPACI Rocks (a full cluster management solution). The current stable Rocks release is from December 2003 and thus pre-dates the press release, but John found this page: http://stommel.tamu.edu/~baum/npaci.html which suggests that libMesh will be in the next release of Rocks... Has anybody heard anything about this? I'm all for them including this in their distribution (especially since it means *they* will be building RPMS :-) ), it just seems curious that none of us know anything about it... -Ben John Peterson wrote: >While searching for libmesh on google (egotistical? yes :)) >I found this page entitled: > >What's in NPACI Rocks and How Do I Use It? >http://stommel.tamu.edu/~baum/npaci.html > >from March 8, 2004. Checking out entry 8.31, we find: > >8.31 libMesh >http://libmesh.sourceforge.net/ >A C++ framework for the numerical solution of PDEs on serial and parallel platforms. This requires PETSc. > >So...is libmesh in NPACI Rocks??? I searched around a bit more but >couldn't find any other comprehensive listing of software available from >Rocks without downloading ISOs. Anyway, pretty cool if it's true... > >By the way, WE DON'T REQUIRE PETSC! ;) > >-John > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Libmesh-devel mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
|
From: <an...@tn...> - 2004-03-21 02:41:20
|
Hi all Either I am again missing something obvious (in that case: sorry for the noise), or I feel something is missing: Upon mesh refinement, the mesh.data is not projected on the new mesh. To my understanding this could be accomplished in a similar way as the projection of solution vectors. Indeed the only workaround I could come up with was to add a trivial system, solve it for the nodal data on the RHS, and subsequently use the solution of this system to obtain the data values on a refined mesh. I think that such a routine would be either explicitly called as mesh.data.reinit(), or would automatically be called by mesh_refinement.refine_and_coarsen_elements(); Does this make sense? Best, Martin |
|
From: <an...@tn...> - 2004-03-21 02:20:04
|
Hi In the GMVIO routine, the QUAD8 element is turned into QUAD4 elements with the tecplot_connectivity function. This is not necessary, since GMV supports QUAD8 (its name is '8quad'). Should I submit a patch for it? Best, Martin |
|
From: Benjamin S. K. <be...@cf...> - 2004-03-19 13:17:34
|
John is right. I changed the mpio.h header file in the CFDLab to use=20 long instead of long long. The MPICH ./configure provides=20 --disable-long-long (or something like that) but it does not seem to=20 listen to that flag :-) I don't want to set that flag for libMesh because it is a valid=20 warning. If we set that flag then people developing with gcc could use=20 a lot of 'long long's' and cause a portability problem. You can always do CXXFLAGS=3D-Wno-long-long make ... -Ben John Peterson wrote: >Martin L=FCthi writes: > >=20 > > Just for the records:=20 > >=20 > > in order to compile libmesh in debug mode (make METHOD=3Ddbg) with mp= ich > > on a single processor Linux box (gcc 3.3.3), the linker complains > > about the definition of long long > >=20 > > /home/soft/numeric/mpich/include/mpio.h:34: error: ISO C++ does not s= upport=20 > > `long long' > >=20 > > This error can be avoided using the compiler switch -Wno-long-long in > > Make.common, so that line 145 ff read >Is that only valid for gcc? Probably so... > > > ifeq ($(debug-mode),on) > > CXXFLAGS +=3D -g -ansi -pedantic -W -Wall -Wunused -Wpointer-arith = -Wimplicit -Wformat -Wparentheses -Wno-long-long -O -Wuninitialized -DDEB= UG -fPIC > > CFLAGS +=3D -g -DDEBUG -fPIC > > endif > >=20 > > Should this flag be set as a default? >Probably so. I think we don't notice this warning since we >at some point changed the mpi headers at our site to use >long instead. > >-John > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk >_______________________________________________ >Libmesh-users mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libmesh-users > =20 > |
|
From: Benjamin S. K. <be...@cf...> - 2004-03-19 13:11:14
|
It looks to me like the space in '-L /home/denis/sci/fblaslapack' might be doing it. It is probably finding that in your $PETSC_DIR/bmake/$PETSC_ARCH/packages file. Let me know if that helps... -Ben Denis Danilov wrote: >Hi, > >The theme of compilation and linking is the most popular in the last >month... > >I try to set up libmesh 0.4.2 on the following configuration: >cygwin + gcc3.3 + petsc(mpiuni) >./configure --enable-reference-counting --enable-perflog >--disable-laspack --disable-tecplot --disable-shared > >I can build library, but when i try to compile and run an example >program, an error appears in the form > >(output of make all -n for example 1) >echo "Linking "ex1"..." >g++ -O2 -felide-constructors -DNDEBUG -funroll-loops -fstrict-aliasing >ex1.i686-pc-cygwin.o -o ex1 >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a >/home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libparmetis.a >/home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libmetis.a >/home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libsfcurves.a >/home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libgzstream.a >-lz -L/home/denis/sci/petsc-2.1.6/lib/libO/win32_gnu -lpetscsles -lpetscdm >-lpetscmat -lpetscvec -lpetsc -L /home/denis/sci/fblaslapack -lflapack >-lfblas /home/denis/sci/petsc-2.1.6/lib/libO/win32_gnu/libmpiuni.a >-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1 > -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../.. -lfrtbegin -lg2c >-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 >/home/denis/sci/petsc-2.1.6/lib/libO/win32_gnu/libmpiuni.a > >(and the corresponding error) >make all >Linking ex1... >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(libmesh.i686-pc-cygwin.o)(.text+0x16f8):libmesh.C: undefined reference to `Petsc_MPI_Finalize()' >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(equation_systems.i686-pc-cygwin.o)(.text+0x48ee):equation_systems.C: undefined reference to >`MPIUNI_Memcpy(void*, void*, int)' >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(equation_systems.i686-pc-cygwin.o)(.text+0x4e29):equation_systems.C: undefined reference to >`MPIUNI_Memcpy(void*, void*, int)' >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(parmetis_partitioner.i686-pc-cygwin.o)(.text+0x3f1):parmetis_partitioner.C: undefined reference to >`MPIUNI_Memcpy(void*, void*, int)' >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(petsc_vector.i686-pc-cygwin.o)(.text+0x27a):petsc_vector.C: undefined reference to >`MPIUNI_Memcpy(void*, void*, int)' >/home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(petsc_vector.i686-pc-cygwin.o)(.text+0x6c9):petsc_vector.C: undefined reference to >`MPIUNI_Memcpy(void*, void*, int)' >collect2: ld returned 1 exit status >make: *** [ex1] Error 1 > > >It seems all the necessary libs are included in command line >(particular libmpiuni.a ans petsc), however Petsc_MPI_Finalize() and >MPIUNI_Memcpy() are not found. >Any suggestion how get it working in this configuration (without >laspack)? > > >Best regards >Denis > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Libmesh-users mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libmesh-users > > |
|
From: Denis D. <dan...@ya...> - 2004-03-18 10:41:14
|
Hi, The theme of compilation and linking is the most popular in the last month... I try to set up libmesh 0.4.2 on the following configuration: cygwin + gcc3.3 + petsc(mpiuni) ./configure --enable-reference-counting --enable-perflog --disable-laspack --disable-tecplot --disable-shared I can build library, but when i try to compile and run an example program, an error appears in the form (output of make all -n for example 1) echo "Linking "ex1"..." g++ -O2 -felide-constructors -DNDEBUG -funroll-loops -fstrict-aliasing ex1.i686-pc-cygwin.o -o ex1 /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a /home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libparmetis.a /home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libmetis.a /home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libsfcurves.a /home/denis/sci/libmesh-0.4.2/contrib/lib/i686-pc-cygwin_opt/libgzstream.a -lz -L/home/denis/sci/petsc-2.1.6/lib/libO/win32_gnu -lpetscsles -lpetscdm -lpetscmat -lpetscvec -lpetsc -L /home/denis/sci/fblaslapack -lflapack -lfblas /home/denis/sci/petsc-2.1.6/lib/libO/win32_gnu/libmpiuni.a -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1 -L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../.. -lfrtbegin -lg2c -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 /home/denis/sci/petsc-2.1.6/lib/libO/win32_gnu/libmpiuni.a (and the corresponding error) make all Linking ex1... /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(libmesh.i686-pc-cygwin.o)(.text+0x16f8):libmesh.C: undefined reference to `Petsc_MPI_Finalize()' /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(equation_systems.i686-pc-cygwin.o)(.text+0x48ee):equation_systems.C: undefined reference to `MPIUNI_Memcpy(void*, void*, int)' /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(equation_systems.i686-pc-cygwin.o)(.text+0x4e29):equation_systems.C: undefined reference to `MPIUNI_Memcpy(void*, void*, int)' /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(parmetis_partitioner.i686-pc-cygwin.o)(.text+0x3f1):parmetis_partitioner.C: undefined reference to `MPIUNI_Memcpy(void*, void*, int)' /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(petsc_vector.i686-pc-cygwin.o)(.text+0x27a):petsc_vector.C: undefined reference to `MPIUNI_Memcpy(void*, void*, int)' /home/denis/sci/libmesh-0.4.2/lib/i686-pc-cygwin_opt/libmesh.a(petsc_vector.i686-pc-cygwin.o)(.text+0x6c9):petsc_vector.C: undefined reference to `MPIUNI_Memcpy(void*, void*, int)' collect2: ld returned 1 exit status make: *** [ex1] Error 1 It seems all the necessary libs are included in command line (particular libmpiuni.a ans petsc), however Petsc_MPI_Finalize() and MPIUNI_Memcpy() are not found. Any suggestion how get it working in this configuration (without laspack)? Best regards Denis |
|
From: John P. <pet...@cf...> - 2004-03-17 21:15:41
|
Martin L=FCthi writes: >=20 > Just for the records:=20 >=20 > in order to compile libmesh in debug mode (make METHOD=3Ddbg) with m= pich > on a single processor Linux box (gcc 3.3.3), the linker complains > about the definition of long long >=20 > /home/soft/numeric/mpich/include/mpio.h:34: error: ISO C++ does not = support=20 > `long long' >=20 > This error can be avoided using the compiler switch -Wno-long-long i= n > Make.common, so that line 145 ff read Is that only valid for gcc? Probably so... > ifeq ($(debug-mode),on) > CXXFLAGS +=3D -g -ansi -pedantic -W -Wall -Wunused -Wpointer-arith= -Wimplicit -Wformat -Wparentheses -Wno-long-long -O -Wuninitialized -D= DEBUG -fPIC > CFLAGS +=3D -g -DDEBUG -fPIC > endif >=20 > Should this flag be set as a default? Probably so. I think we don't notice this warning since we at some point changed the mpi headers at our site to use long instead. -John |
|
From: <an...@tn...> - 2004-03-17 20:52:49
|
Just for the records: in order to compile libmesh in debug mode (make METHOD=dbg) with mpich on a single processor Linux box (gcc 3.3.3), the linker complains about the definition of long long /home/soft/numeric/mpich/include/mpio.h:34: error: ISO C++ does not support `long long' This error can be avoided using the compiler switch -Wno-long-long in Make.common, so that line 145 ff read ifeq ($(debug-mode),on) CXXFLAGS += -g -ansi -pedantic -W -Wall -Wunused -Wpointer-arith -Wimplicit -Wformat -Wparentheses -Wno-long-long -O -Wuninitialized -DDEBUG -fPIC CFLAGS += -g -DDEBUG -fPIC endif Should this flag be set as a default? Best, Martin |
|
From: John P. <pet...@cf...> - 2004-03-15 14:53:47
|
Martin L=FCthi writes:
> Hi all
>=20
> I have serious trouble understanding how BoundaryMesh is supposed to=
> work. Example 12 is not enlightening, and the comments in the code
> are quite confusing.
Please note the exact lines which are the most confusing. Then we can
try to fix those...
> Some questions:
>=20
> o how are the mesh and the boundary mesh linked? I found=20
>=20
> mesh.boundary_info.sync(bmesh);
>=20
> Is this the only way to do it?
The mesh knows which elements are on the boundary after find_neighbors(=
)
has been called. To get a list of nodes, elements, and element sides
which are on the boundary, you can do:
// List of node numbers
std::vector<unsigned int> nl;
// List of element numbers
std::vector<unsigned int> el;
// List of side numbers
std::vector<unsigned short int> sl;
// List of ids for nodes and sides
std::vector<short int> nodes;
std::vector<short int> sides;
// Create a list of boundary ids for the nodes.
mesh.boundary_info.build_node_list(nl, nodes);
mesh.boundary_info.build_side_list(el, sl, sides);
> o should the BoundaryMesh be one dimension less than the Mesh?
Yes it is composed of dim-1 dimensional elements which may live in
dimension dim. (Think of the triangulated boundary of a sphere or
something similar with tets inside.
> If yes: this is not enforced. If no: bmesh.write_gmv crashes with
> mesh(2) and bmesh(2).
>=20
> o How are boundary conditions set? (I only found how to assign nodes=
> or element sides to a boundary).
They are typically set by the mesh generator in the form of ids.
> o How are boundary conditions read from xta file?
Ben has created some good general documentation on the XDA/R format
which includes information on the boundary conditions. It should
answer that question.
> Examples on all of the above would be extremely helpful and highly
> appreciated.=20
You should have a copy of meshtool.cc in your src/apps directory.
There is an example of how to write out the boundary there.
-John
|
|
From: Yuna <hy...@CL...> - 2004-03-09 15:07:48
|
Hi Benjamin, I have built the library, but I have some problems when I built examples. The error looks like: **************************************************************************** ** make[1]: Entering directory `/users/hyuna/myResearch/libmesh/examples' make[2]: Entering directory `/users/hyuna/myResearch/libmesh/examples/ex1' Compiling C++ (in debug mode) ex1.C... Linking ex1... Undefined first referenced symbol in file void PetscVector<double>::add_vector(const NumericVector<double>&,SparseMatrix<double>&) /users/hyuna/myResearch/libmesh/lib/sparc-sun-solaris2.8_dbg/libmesh.so ld: fatal: Symbol referencing errors. No output written to ex1 make[2]: *** [ex1] Error 1 make[2]: Leaving directory `/users/hyuna/myResearch/libmesh/examples/ex1' make[1]: *** [run] Error 2 make[1]: Leaving directory `/users/hyuna/myResearch/libmesh/examples' make: *** [run_examples] Error 2 **************************************************************************** **** Could you help me fix it? Thanks a lot. Yuna ----- Original Message ----- From: "John Peterson" <pet...@cf...> To: "Yuna" <hy...@CL...> Cc: "Benjamin S. Kirk" <be...@cf...>; <lib...@li...> Sent: Monday, March 08, 2004 11:23 PM Subject: [Libmesh-users] Call for any support for Strange Linking problem > Yuna writes: > > Hi, > > > > > I just get file like "libmesh.so", So does anyone ever have this problem > > and give me some hints? > libmesh.so is a shared object file. You should be able to use it in the same > way as the libmesh.a file. The .so is the default library to build unless you > use --disable-shared. > > -John |
|
From: Yuna <hy...@CL...> - 2004-03-09 15:03:13
|
Morning Benjamin, I can now bulid library. I found there are some warnings. I wrote them here for your reference: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Compiling C++ (in debug mode) src/base/dof_map.C... ..... Compiling C++ (in debug mode) src/base/libmesh.C... "/users/hyuna/myResearch/libmesh/include/base/getpot.h", line 684: Warning: section hides GetPot::section. 1 Warning(s) detected. Compiling C++ (in debug mode) src/base/node.C... ............................... Compiling C++ (in debug mode) src/fe/fe_xyz.C... "src/fe/fe_xyz.C", line 212: Warning: xyz hides FEBase::xyz. "src/fe/fe_xyz.C", line 212: Warning: xyz hides FEBase::xyz. "src/fe/fe_xyz.C", line 212: Warning: xyz hides FEBase::xyz. 3 Warning(s) detected. Compiling C++ (in debug mode) src/fe/fe_xyz_shape_1D.C... ...................................... Compiling C++ (in debug mode) src/quadrature/quadrature_gauss_2D.C... "src/quadrature/quadrature_gauss_2D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_gauss_3D.C... "src/quadrature/quadrature_gauss_3D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_jacobi.C... ..... Compiling C++ (in debug mode) src/quadrature/quadrature_simpson_2D.C... "src/quadrature/quadrature_simpson_2D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_simpson_3D.C... "src/quadrature/quadrature_simpson_3D.C", line 30: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_trap.C... ................. Compiling C++ (in debug mode) src/quadrature/quadrature_trap_2D.C... "src/quadrature/quadrature_trap_2D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_trap_3D.C... "src/quadrature/quadrature_trap_3D.C", line 30: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/solvers/equation_systems.C... ....... Compiling C++ (in debug mode) src/solvers/newmark_system.C... "src/solvers/newmark_system.C", line 201: Warning: rhs hides ExplicitSystem::rhs. 1 Warning(s) detected. Compiling C++ (in debug mode) src/solvers/steady_system.C... ....................... Linking /users/hyuna/myResearch/libmesh/lib/sparc-sun-solaris2.8_dbg/libmesh.so make[1]: Entering directory `/users/hyuna/myResearch/libmesh/contrib' ---------------------------------------------- ------- Building Contributed Packages -------- ---------------------------------------------- --- Building LASPACK ------------------------- make[2]: Entering directory `/users/hyuna/myResearch/libmesh/contrib/laspack' Compiling C (in debug mode) eigenval.c.. .... Compiling C (in debug mode) rtc.c... Linking ../lib/sparc-sun-solaris2.8_dbg/liblaspack.so make[2]: Leaving directory `/users/hyuna/myResearch/libmesh/contrib/laspack' --- Building Metis --------------------------- make[2]: Entering directory `/users/hyuna/myResearch/libmesh/contrib/metis/Lib' Compiling C (in debug mode) balance.c... ........ Compiling C (in debug mode) checkgraph.c... "checkgraph.c", line 124: warning: implicit function declaration: __GKfree Compiling C (in debug mode) coarsen.c... Compiling C (in debug mode) compress.c... "compress.c", line 151: warning: implicit function declaration: __GKfree Compiling C (in debug mode) debug.c... Compiling C (in debug mode) estmem.c... "estmem.c", line 102: warning: implicit function declaration: __GKfree Compiling C (in debug mode) fm.c... Compiling C (in debug mode) fortran.c... Compiling C (in debug mode) frename.c... Compiling C (in debug mode) graph.c... "graph.c", line 445: warning: implicit function declaration: __GKfree Compiling C (in debug mode) initpart.c... "initpart.c", line 202: warning: implicit function declaration: __GKfree Compiling C (in debug mode) kmetis.c... "kmetis.c", line 124: warning: implicit function declaration: __GKfree Compiling C (in debug mode) kvmetis.c... "kvmetis.c", line 125: warning: implicit function declaration: __GKfree Compiling C (in debug mode) kwayfm.c... Compiling C (in debug mode) kwayrefine.c... "kwayrefine.c", line 74: warning: implicit function declaration: __GKfree Compiling C (in debug mode) kwayvolfm.c... "kwayvolfm.c", line 151: warning: implicit function declaration: __GKfree Compiling C (in debug mode) kwayvolrefine.c... "kwayvolrefine.c", line 76: warning: implicit function declaration: __GKfree Compiling C (in debug mode) match.c... Compiling C (in debug mode) mbalance.c... Compiling C (in debug mode) mbalance2.c... Compiling C (in debug mode) mcoarsen.c... Compiling C (in debug mode) memory.c... "memory.c", line 89: warning: implicit function declaration: __GKfree Compiling C (in debug mode) mesh.c... Compiling C (in debug mode) meshpart.c... "meshpart.c", line 101: warning: implicit function declaration: __GKfree Compiling C (in debug mode) mfm.c... Compiling C (in debug mode) mfm2.c... Compiling C (in debug mode) mincover.c... "mincover.c", line 118: warning: implicit function declaration: __GKfree Compiling C (in debug mode) minitpart.c... "minitpart.c", line 98: warning: implicit function declaration: __GKfree "minitpart.c", line 251: warning: implicit function declaration: SelectQueueOneWay Compiling C (in debug mode) minitpart2.c... "minitpart2.c", line 95: warning: implicit function declaration: __GKfree Compiling C (in debug mode) mkmetis.c... "mkmetis.c", line 119: warning: implicit function declaration: __GKfree Compiling C (in debug mode) mkwayfmh.c... Compiling C (in debug mode) mkwayrefine.c... Compiling C (in debug mode) mmatch.c... Compiling C (in debug mode) mmd.c... Compiling C (in debug mode) mpmetis.c... "mpmetis.c", line 125: warning: implicit function declaration: __GKfree Compiling C (in debug mode) mrefine.c... Compiling C (in debug mode) mrefine2.c... Compiling C (in debug mode) mutil.c... Compiling C (in debug mode) myqsort.c... Compiling C (in debug mode) ometis.c... "ometis.c", line 138: warning: implicit function declaration: __GKfree Compiling C (in debug mode) parmetis.c... "parmetis.c", line 143: warning: implicit function declaration: __GKfree Compiling C (in debug mode) pmetis.c... "pmetis.c", line 138: warning: implicit function declaration: __GKfree Compiling C (in debug mode) pqueue.c... "pqueue.c", line 110: warning: implicit function declaration: __GKfree Compiling C (in debug mode) refine.c... Compiling C (in debug mode) separator.c... "separator.c", line 40: warning: implicit function declaration: __GKfree Compiling C (in debug mode) sfm.c... Compiling C (in debug mode) srefine.c... Compiling C (in debug mode) stat.c... "stat.c", line 123: warning: implicit function declaration: __GKfree Compiling C (in debug mode) subdomains.c... "subdomains.c", line 885: warning: implicit function declaration: __GKfree Compiling C (in debug mode) timing.c... Compiling C (in debug mode) util.c... Linking ../../lib/sparc-sun-solaris2.8_dbg/libmetis.so make[2]: Leaving directory `/users/hyuna/myResearch/libmesh/contrib/metis/Lib' --- Building Parmetis ------------------------ make[2]: Entering directory `/users/hyuna/myResearch/libmesh/contrib/parmetis/Lib' Compiling C (in debug mode) akwayfm.c... "akwayfm.c", line 621: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) ametis.c... "ametis.c", line 158: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) backcompat.c... Compiling C (in debug mode) balancemylink.c... "balancemylink.c", line 339: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) coarsen.c... "coarsen.c", line 481: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) comm.c... Compiling C (in debug mode) csrmatch.c... "csrmatch.c", line 86: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) debug.c... Compiling C (in debug mode) diffutil.c... "diffutil.c", line 125: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) fpqueue.c... Compiling C (in debug mode) frename.c... Compiling C (in debug mode) gkmetis.c... "gkmetis.c", line 75: warning: implicit function declaration: METIS_WPartGraphKway "gkmetis.c", line 250: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) grsetup.c... "grsetup.c", line 273: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) iidxsort.c... Compiling C (in debug mode) iintsort.c... Compiling C (in debug mode) ikeysort.c... Compiling C (in debug mode) ikeyvalsort.c... Compiling C (in debug mode) initbalance.c... "initbalance.c", line 91: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) initmsection.c... "initmsection.c", line 139: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) initpart.c... "initpart.c", line 191: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) kmetis.c... "kmetis.c", line 71: warning: implicit function declaration: METIS_WPartGraphKway "kmetis.c", line 166: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) kwaybalance.c... "kwaybalance.c", line 449: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) kwayfm.c... "kwayfm.c", line 591: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) kwayrefine.c... Compiling C (in debug mode) lmatch.c... "lmatch.c", line 122: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) match.c... "match.c", line 308: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) mdiffusion.c... "mdiffusion.c", line 248: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) memory.c... "memory.c", line 50: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) mesh.c... "mesh.c", line 327: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) mmetis.c... "mmetis.c", line 90: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) move.c... Compiling C (in debug mode) node_refine.c... "node_refine.c", line 355: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) ometis.c... Compiling C (in debug mode) order.c... "order.c", line 93: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) pspases.c... "pspases.c", line 98: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) redomylink.c... "redomylink.c", line 172: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) remap.c... "remap.c", line 159: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) rmetis.c... "rmetis.c", line 152: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) selectq.c... Compiling C (in debug mode) serial.c... "serial.c", line 223: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) setup.c... Compiling C (in debug mode) stat.c... "stat.c", line 52: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) timer.c... Compiling C (in debug mode) util.c... Compiling C (in debug mode) wave.c... "wave.c", line 237: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) weird.c... "weird.c", line 95: warning: implicit function declaration: GKfree__ Compiling C (in debug mode) xyzpart.c... "xyzpart.c", line 252: warning: implicit function declaration: GKfree__ Linking ../../lib/sparc-sun-solaris2.8_dbg/libparmetis.so make[2]: Leaving directory `/users/hyuna/myResearch/libmesh/contrib/parmetis/Lib' --- Building sfcurves ------------------------ make[2]: Entering directory `/users/hyuna/myResearch/libmesh/contrib/sfcurves' Compiling C (in debug mode) cmp.c... Compiling C (in debug mode) hilbert.c... Compiling C (in debug mode) morton.c... Linking ../lib/sparc-sun-solaris2.8_dbg/libsfcurves.so make[2]: Leaving directory `/users/hyuna/myResearch/libmesh/contrib/sfcurves' --- Building libgzstream --------------------- make[2]: Entering directory `/users/hyuna/myResearch/libmesh/contrib/gzstream' Compiling C++ (in debug mode) gzstream.C... Linking ../lib/sparc-sun-solaris2.8_dbg/libgzstream.so make[2]: Leaving directory `/users/hyuna/myResearch/libmesh/contrib/gzstream' ---------------------------------------------- ----- Done Building Contributed Packages ----- ---------------------------------------------- make[1]: Leaving directory `/users/hyuna/myResearch/libmesh/contrib' Best yuna |
|
From: John P. <pet...@cf...> - 2004-03-09 04:40:21
|
Yuna writes: > Hi, > > I just get file like "libmesh.so", So does anyone ever have this problem > and give me some hints? libmesh.so is a shared object file. You should be able to use it in the same way as the libmesh.a file. The .so is the default library to build unless you use --disable-shared. -John |
|
From: Yuna <hy...@CL...> - 2004-03-09 00:35:17
|
Hi, I am working on Sun unix system, and compiler is CC: sun C++ compiler. And Benjamin has helped me fix some problem so I can run configure in my system. But after I try to make the library, it seemed work, but I can't get any library files such as "libmesh.a". Also I cannot run any examples. Please see the following compilinginformation: **************************************************************************** ************** Compiling C++ (in debug mode) src/base/dof_map.C... Compiling C++ (in debug mode) src/base/dof_map_constraints.C... Compiling C++ (in debug mode) src/base/dof_object.C... Compiling C++ (in debug mode) src/base/libmesh.C... "/users/hyuna/myResearch/libmesh-0.4.2/include/base/getpot.h", line 684: Warning: section hides GetPot::section. 1 Warning(s) detected. Compiling C++ (in debug mode) src/base/node.C... Compiling C++ (in debug mode) src/base/reference_counted_object.C... Compiling C++ (in debug mode) src/base/reference_counter.C... Compiling C++ (in debug mode) src/fe/fe.C... Compiling C++ (in debug mode) src/fe/fe_base.C... Compiling C++ (in debug mode) src/fe/fe_boundary.C... Compiling C++ (in debug mode) src/fe/fe_hierarchic.C... Compiling C++ (in debug mode) src/fe/fe_hierarchic_shape_1D.C... Compiling C++ (in debug mode) src/fe/fe_hierarchic_shape_2D.C... Compiling C++ (in debug mode) src/fe/fe_hierarchic_shape_3D.C... Compiling C++ (in debug mode) src/fe/fe_interface.C... Compiling C++ (in debug mode) src/fe/fe_interface_inf_fe.C... Compiling C++ (in debug mode) src/fe/fe_lagrange.C... Compiling C++ (in debug mode) src/fe/fe_lagrange_shape_1D.C... Compiling C++ (in debug mode) src/fe/fe_lagrange_shape_2D.C... Compiling C++ (in debug mode) src/fe/fe_lagrange_shape_3D.C... Compiling C++ (in debug mode) src/fe/fe_map.C... Compiling C++ (in debug mode) src/fe/fe_monomial.C... Compiling C++ (in debug mode) src/fe/fe_monomial_shape_1D.C... Compiling C++ (in debug mode) src/fe/fe_monomial_shape_2D.C... Compiling C++ (in debug mode) src/fe/fe_monomial_shape_3D.C... Compiling C++ (in debug mode) src/fe/fe_szabab.C... Compiling C++ (in debug mode) src/fe/fe_szabab_shape_1D.C... Compiling C++ (in debug mode) src/fe/fe_szabab_shape_2D.C... Compiling C++ (in debug mode) src/fe/fe_szabab_shape_3D.C... Compiling C++ (in debug mode) src/fe/inf_fe.C... Compiling C++ (in debug mode) src/fe/inf_fe_base_radial.C... Compiling C++ (in debug mode) src/fe/inf_fe_boundary.C... Compiling C++ (in debug mode) src/fe/inf_fe_jacobi_20_00_eval.C... Compiling C++ (in debug mode) src/fe/inf_fe_jacobi_30_00_eval.C... Compiling C++ (in debug mode) src/fe/inf_fe_lagrange_eval.C... Compiling C++ (in debug mode) src/fe/inf_fe_legendre_eval.C... Compiling C++ (in debug mode) src/fe/inf_fe_map.C... Compiling C++ (in debug mode) src/fe/inf_fe_map_eval.C... Compiling C++ (in debug mode) src/fe/inf_fe_static.C... Compiling C++ (in debug mode) src/geom/cell.C... Compiling C++ (in debug mode) src/geom/cell_hex.C... Compiling C++ (in debug mode) src/geom/cell_hex20.C... Compiling C++ (in debug mode) src/geom/cell_hex27.C... Compiling C++ (in debug mode) src/geom/cell_hex8.C... Compiling C++ (in debug mode) src/geom/cell_inf.C... Compiling C++ (in debug mode) src/geom/cell_inf_hex.C... Compiling C++ (in debug mode) src/geom/cell_inf_hex16.C... Compiling C++ (in debug mode) src/geom/cell_inf_hex18.C... Compiling C++ (in debug mode) src/geom/cell_inf_hex8.C... Compiling C++ (in debug mode) src/geom/cell_inf_prism.C... Compiling C++ (in debug mode) src/geom/cell_inf_prism12.C... Compiling C++ (in debug mode) src/geom/cell_inf_prism6.C... Compiling C++ (in debug mode) src/geom/cell_prism.C... Compiling C++ (in debug mode) src/geom/cell_prism15.C... Compiling C++ (in debug mode) src/geom/cell_prism18.C... Compiling C++ (in debug mode) src/geom/cell_prism6.C... Compiling C++ (in debug mode) src/geom/cell_pyramid.C... Compiling C++ (in debug mode) src/geom/cell_pyramid5.C... Compiling C++ (in debug mode) src/geom/cell_tet.C... Compiling C++ (in debug mode) src/geom/cell_tet10.C... Compiling C++ (in debug mode) src/geom/cell_tet4.C... Compiling C++ (in debug mode) src/geom/edge.C... Compiling C++ (in debug mode) src/geom/edge_edge2.C... Compiling C++ (in debug mode) src/geom/edge_edge3.C... Compiling C++ (in debug mode) src/geom/edge_inf_edge2.C... Compiling C++ (in debug mode) src/geom/elem.C... Compiling C++ (in debug mode) src/geom/elem_quality.C... Compiling C++ (in debug mode) src/geom/elem_refinement.C... Compiling C++ (in debug mode) src/geom/elem_type.C... Compiling C++ (in debug mode) src/geom/face.C... Compiling C++ (in debug mode) src/geom/face_inf_quad.C... Compiling C++ (in debug mode) src/geom/face_inf_quad4.C... Compiling C++ (in debug mode) src/geom/face_inf_quad6.C... Compiling C++ (in debug mode) src/geom/face_quad.C... Compiling C++ (in debug mode) src/geom/face_quad4.C... Compiling C++ (in debug mode) src/geom/face_quad8.C... Compiling C++ (in debug mode) src/geom/face_quad9.C... Compiling C++ (in debug mode) src/geom/face_tri.C... Compiling C++ (in debug mode) src/geom/face_tri3.C... Compiling C++ (in debug mode) src/geom/face_tri6.C... Compiling C++ (in debug mode) src/geom/plane.C... Compiling C++ (in debug mode) src/geom/point.C... Compiling C++ (in debug mode) src/geom/sphere.C... Compiling C++ (in debug mode) src/geom/surface.C... Compiling C++ (in debug mode) src/mesh/boundary_info.C... Compiling C++ (in debug mode) src/mesh/boundary_mesh.C... Compiling C++ (in debug mode) src/mesh/mesh.C... Compiling C++ (in debug mode) src/mesh/mesh_base.C... Compiling C++ (in debug mode) src/mesh/mesh_base_modification.C... Compiling C++ (in debug mode) src/mesh/mesh_communication.C... Compiling C++ (in debug mode) src/mesh/mesh_data.C... Compiling C++ (in debug mode) src/mesh/mesh_data_tetgen_support.C... Compiling C++ (in debug mode) src/mesh/mesh_data_unv_support.C... Compiling C++ (in debug mode) src/mesh/mesh_data_xdr_support.C... Compiling C++ (in debug mode) src/mesh/mesh_diva_support.C... Compiling C++ (in debug mode) src/mesh/mesh_exodus_support.C... Compiling C++ (in debug mode) src/mesh/mesh_generation.C... Compiling C++ (in debug mode) src/mesh/mesh_misc_support.C... Compiling C++ (in debug mode) src/mesh/mesh_modification.C... Compiling C++ (in debug mode) src/mesh/mesh_refinement.C... Compiling C++ (in debug mode) src/mesh/mesh_refinement_flagging.C... Compiling C++ (in debug mode) src/mesh/mesh_refinement_smoothing.C... Compiling C++ (in debug mode) src/mesh/mesh_smoother.C... Compiling C++ (in debug mode) src/mesh/mesh_smoother_laplace.C... Compiling C++ (in debug mode) src/mesh/mesh_tecplot_support.C... Compiling C++ (in debug mode) src/mesh/mesh_tetgen_support.C... Compiling C++ (in debug mode) src/mesh/mesh_ucd_support.C... Compiling C++ (in debug mode) src/mesh/mesh_unv_support.C... Compiling C++ (in debug mode) src/mesh/mesh_xdr_support.C... Compiling C++ (in debug mode) src/numerics/analytic_function.C... Compiling C++ (in debug mode) src/numerics/coupling_matrix.C... Compiling C++ (in debug mode) src/numerics/dense_matrix.C... Compiling C++ (in debug mode) src/numerics/dense_matrix_base.C... Compiling C++ (in debug mode) src/numerics/dense_submatrix.C... Compiling C++ (in debug mode) src/numerics/dense_subvector.C... Compiling C++ (in debug mode) src/numerics/dense_vector.C... Compiling C++ (in debug mode) src/numerics/dense_vector_base.C... Compiling C++ (in debug mode) src/numerics/distributed_vector.C... Compiling C++ (in debug mode) src/numerics/error_estimator.C... Compiling C++ (in debug mode) src/numerics/function_base.C... Compiling C++ (in debug mode) src/numerics/laspack_interface.C... Compiling C++ (in debug mode) src/numerics/laspack_matrix.C... Compiling C++ (in debug mode) src/numerics/laspack_vector.C... Compiling C++ (in debug mode) src/numerics/linear_solver_interface.C... Compiling C++ (in debug mode) src/numerics/mesh_function.C... Compiling C++ (in debug mode) src/numerics/numeric_vector.C... Compiling C++ (in debug mode) src/numerics/petsc_interface.C... Compiling C++ (in debug mode) src/numerics/petsc_matrix.C... Compiling C++ (in debug mode) src/numerics/petsc_vector.C... Compiling C++ (in debug mode) src/numerics/sparse_matrix.C... Compiling C++ (in debug mode) src/numerics/type_vector.C... Compiling C++ (in debug mode) src/partitioning/centroid_partitioner.C... Compiling C++ (in debug mode) src/partitioning/linear_partitioner.C... Compiling C++ (in debug mode) src/partitioning/metis_partitioner.C... Compiling C++ (in debug mode) src/partitioning/parmetis_partitioner.C... Compiling C++ (in debug mode) src/partitioning/partitioner.C... Compiling C++ (in debug mode) src/partitioning/partitioner_factory.C... Compiling C++ (in debug mode) src/partitioning/sfc_partitioner.C... Compiling C++ (in debug mode) src/quadrature/quadrature.C... Compiling C++ (in debug mode) src/quadrature/quadrature_build.C... Compiling C++ (in debug mode) src/quadrature/quadrature_gauss.C... Compiling C++ (in debug mode) src/quadrature/quadrature_gauss_1D.C... Compiling C++ (in debug mode) src/quadrature/quadrature_gauss_2D.C... "src/quadrature/quadrature_gauss_2D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_gauss_3D.C... "src/quadrature/quadrature_gauss_3D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_jacobi.C... Compiling C++ (in debug mode) src/quadrature/quadrature_jacobi_1D.C... Compiling C++ (in debug mode) src/quadrature/quadrature_rules.C... Compiling C++ (in debug mode) src/quadrature/quadrature_simpson.C... Compiling C++ (in debug mode) src/quadrature/quadrature_simpson_1D.C... Compiling C++ (in debug mode) src/quadrature/quadrature_simpson_2D.C... "src/quadrature/quadrature_simpson_2D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_simpson_3D.C... "src/quadrature/quadrature_simpson_3D.C", line 30: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_trap.C... Compiling C++ (in debug mode) src/quadrature/quadrature_trap_1D.C... Compiling C++ (in debug mode) src/quadrature/quadrature_trap_2D.C... "src/quadrature/quadrature_trap_2D.C", line 28: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/quadrature/quadrature_trap_3D.C... "src/quadrature/quadrature_trap_3D.C", line 30: Warning: _type hides QBase::_type. 1 Warning(s) detected. Compiling C++ (in debug mode) src/solvers/equation_systems.C... Compiling C++ (in debug mode) src/solvers/equation_systems_io.C... Compiling C++ (in debug mode) src/solvers/explicit_system.C... Compiling C++ (in debug mode) src/solvers/frequency_system.C... Compiling C++ (in debug mode) src/solvers/implicit_system.C... Compiling C++ (in debug mode) src/solvers/newmark_system.C... "src/solvers/newmark_system.C", line 201: Warning: rhs hides ImplicitSystem::rhs. 1 Warning(s) detected. Compiling C++ (in debug mode) src/solvers/steady_system.C... Compiling C++ (in debug mode) src/solvers/system.C... Compiling C++ (in debug mode) src/solvers/system_io.C... Compiling C++ (in debug mode) src/solvers/system_projection.C... Compiling C++ (in debug mode) src/solvers/transient_system.C... Compiling C++ (in debug mode) src/utils/data_map.C... Compiling C++ (in debug mode) src/utils/error_vector.C... Compiling C++ (in debug mode) src/utils/o_f_stream.C... Compiling C++ (in debug mode) src/utils/perf_log.C... Compiling C++ (in debug mode) src/utils/point_locator_base.C... Compiling C++ (in debug mode) src/utils/point_locator_list.C... Compiling C++ (in debug mode) src/utils/point_locator_tree.C... Compiling C++ (in debug mode) src/utils/statistics.C... Compiling C++ (in debug mode) src/utils/tree.C... Compiling C++ (in debug mode) src/utils/tree_base.C... Compiling C++ (in debug mode) src/utils/tree_node.C... Compiling C++ (in debug mode) src/utils/utility.C... Compiling C++ (in debug mode) src/utils/xdrIO.C... Compiling C++ (in debug mode) src/utils/xdr_cxx.C... Linking /users/hyuna/myResearch/libmesh-0.4.2/lib/sparc-sun-solaris2.8_dbg/libmesh.s o make[1]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib' ---------------------------------------------- ------- Building Contributed Packages -------- ---------------------------------------------- --- Building LASPACK ------------------------- make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/laspack' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/laspack' --- Building Metis --------------------------- make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/metis/Lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/metis/Lib' --- Building Parmetis ------------------------ make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/parmetis/Lib' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/parmetis/Lib' --- Building sfcurves ------------------------ make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/sfcurves' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/sfcurves' --- Building libgzstream --------------------- make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/gzstream' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib/gzstream' ---------------------------------------------- ----- Done Building Contributed Packages ----- ---------------------------------------------- make[1]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/contrib' **************************************************************************** *********** I just get file like "libmesh.so", So does anyone ever have this problem and give me some hints? Thanks a lot. Yuna |
|
From: Benjamin S. K. <be...@cf...> - 2004-03-08 00:26:11
|
I have found a Solaris 2.9 machine (thanks Sourceforge!) that should be similar to yours. I was able to get the default ./configure to work... You will need to change two lines in the Make.common file after running configure: change RPATHFLAG = -Wl,-rpath, to RPATHFLAG = -Wl,-R, and LIBS = to LIBS = -lrpcsvc This is due to differences in the Linux and Sun linkers. I have checked these changes in to the CVS repository. If you follow the anonymous CVS access instructions (http://libmesh.sourceforge.net/installation.php) and download what is currently in the CVS repository you should be able to just ./configure and go. It does seem to take a long time to link the libraries, but all the tests seem to run fine. A few notes on the output from configure that you sent me: -------------- - configure is a GNU tool, and as such looks for GNU compilers first. In your case it found gcc-3.3 and is using it to build the library instead of the Sun Forte compiler. This shouldn't be a problem (indeed, I have never built libMesh with the Forte compiler, so this might be good). However, problems *may* arise if PETSc is built with the Forte compiler and libMesh is not. You should be able to figure out which compiler PETSc was built with by looking in the file $PETSC_DIR/bmake/$PETSC_ARCH/variables To specify which compiler you want to use instead of letting configure detect it automatically you have to use environment variables. For instance, under bash or sh this should work: CXX=CC CC=cc F77=f77 ./configure .... (For other shells you might need to export the environment variables before running configure). After you have configured the library you don't need to worry about the compiler, the right one will be specified in the Make.common file. -------------- - As for the MPI stuff: libMesh will use MPI if it is available, although it is not required. If PETSc is found then MPI is definintely available, and the file $PETSC_DIR/bmake/$PETSC_ARCH/packages is queried to find it. This could pose a problem if your PETSc has been provided as binaries and not built from source. In this case I would be interested in hearing about it and improving the configuration. If PETSc is not there, then a number of other tests are conducted to find a valid MPI implementation. First mpi libraries and header files are looked for in /usr/lib & /usr/include (you can specify a directory with --with-mpi=/path/to/mpi). If nothing is found there then we do a final test to see if the compiler supports MPI directly. This is the case with the AIX compilers or the mpiCC provided by MPICH, for example. There was a bug in the Parmetis configuration that tried to build parmetis even if no valid MPI installation was found. I have fixed that in the CVS branch. |
|
From: Daniel D. <d.d...@tu...> - 2004-03-07 20:08:36
|
On Sun, 7 Mar 2004, Yuna wrote: > Hi Ahmed, > > Thanks for your advise. > > I set the environment variables in my .cshrc file, now PETSC directory has > been found by the configure. Good! > > I am now try to run Make again! I still have several things I can's get > clearly: > > 1). What is the different when running make on "OPTIMAL MODE" and "DEBUG > MODE"? Which one is better? And generally what method should we use? That's what i suggest: - 95% of your time spending on libmesh/coding, use debug mode, and use small-sized problems that still reflect everything you want to do later. The neat thing with METHOD=dbg, you can use debuggers to trace what happened, and also get some more hints from libmesh itself... - Only when you are perfectly sure that your code is debugged and gives correct answers, use optimized mode. _Very_ seldom it may happen that you get an error when using opt mode (which didn't occur in dbg), but it's generally harder to track down. I also heavily recommend to consult the PETSc documentation. > > 2). I remember the input file can be IDEAS .unv file? Am I right? How do I > use it? Use some common FE preprocessor. the Universal format is, as the name says, pretty universal. ;) libmesh has both .unv input and output, and also offers some mesh -generation and -modification tools. With this you can also play around with .unv-files: create some mesh in libmesh, write to .unv, edit the .unv-file, read back to libmesh, see whether mesh is ok using the gmv viewer, etc... Rather recently, there is also an interface for tetgen-produced files (.node and .ele). Tetgen is freely available (tetgen.berlios.de or so). > > 3). I have a project for finite element analysis for heterogenous material > objects. So I have to include material information in both of my element and > node classes. Isn't that a good or bad way to modify the origianl libmesh > library or can I extend the original mesh and node classes, or do you have With the MeshData class, you already have full support of arbitrary nodal data: You can associate a std::vector<Number> with any node in the mesh, this should be sufficient... Consult the documentation in there, and also the example dwelling on the MeshData class: http://libmesh.sourceforge.net/ex12.php Prior to modifying libmesh, i'd suggest to go and test out this class. I'd say it already offers everything you need. However to be honest, file I/O in .unv format currently only supports nodal data. Coding the I/O of element-associated data is straightforward, but not yet done (no need for it). compare mesh_data_unv_support.C. File I/O in tetgen format currently supports only read method, but for _both_ nodes and elements, i think. -Daniel > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users > |
|
From: Benjamin S. K. <be...@cf...> - 2004-03-07 19:28:57
|
Yuna wrote:
>Hi Ahmed,
>
> Thanks for your advise.
>
> I set the environment variables in my .cshrc file, now PETSC directory has
>been found by the configure. Good!
>
> I am now try to run Make again! I still have several things I can's get
>clearly:
>
>1). What is the different when running make on "OPTIMAL MODE" and "DEBUG
>MODE"? Which one is better? And generally what method should we use?
>
>
OPT mode tells the compiler to generate optimized code, and it also
turns off a lot of debugging checks (like making sure you don't divide
by zero, etc...). Optimized code is therefore a lot faster, but if you
have a problem it will be very hard to track down.
DBG mode on the other hand generates much slower code with a lot of
extra safety checks in it. This code also contains debugging symbols,
so you can track down problems with a debugger.
In general I'd say always develop your stuff in debug mode, and when you
have it working right and want to run some real problems switch to
optimized mode. If you run in to problems you should switch back to
debug mode to find it.
>2). I remember the input file can be IDEAS .unv file? Am I right? How do I
>use it?
>
>
Sure. If you look in example 1, for instance, you will see something like
mesh.read("mesh.xda");
All you need to do is call mesh.read("mesh.unv"); When the file
extension is .ucd then the appropriate reader will be used.
>3). I have a project for finite element analysis for heterogenous material
>objects. So I have to include material information in both of my element and
>node classes. Isn't that a good or bad way to modify the origianl libmesh
>library or can I extend the original mesh and node classes, or do you have
>any other better way? I am original a fortran programmer, not C++. The
>reason I hope to switch to C++ is because I like the style of its thingking
>way, besides I need to link other optimization library which written in C++.
>So I hope to hear some expert advise of how should I develop my C++ FE
>application codes?
>
>
Probably all you need to do is use the subdomain id provided in the Elem
class.
You can do
elem->set_subdomain_id() = 10; // or whatever...
You can then use
elem->subdomain_id()
to define your material properties. For instance, you could associate
ID 10 with copper, 20 with aluminum, or whatever... Then create a
function that defines material properties based on these ids.
You probably don't want to associate the nodes with materials since they
can live on material interfaces and thus don't belong to a specific
material.
> I will report other progress I made later.
>
Good.
> Thanks for everyone.
>
>Yuna
>----- Original Message -----
>From: "Ahmed Elsheikh" <els...@mc...>
>To: "Yuna" <hy...@CL...>
>Cc: <lib...@li...>
>Sent: Saturday, March 06, 2004 11:10 PM
>Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias
>
>
>
>
>>Hi,
>>
>>As in the source code documentation, XDR is a platform-independent
>>binary I/O system. You have to check the linker options, but it is
>>tricky :)
>>
>>As a temporary solution till you get a complete answer, add
>>
>>--disable-xdr to the arguments of configure file !
>>
>>You can use the matlab format for mesh input and gmv or tecplot format
>>to read the output.
>>
>>Regarding PETSC, check if you have the environment variables $PETSC_ARCH
>>and $PETSC_DIR properly defined.
>>
>>Ahmed
>>
>>
>>On Sat, 2004-03-06 at 21:10, Yuna wrote:
>>
>>
>>>Yes, I use the Unix Sun compiler. When I run make METHOD=dbg, it will
>>>create some files like xdrIO.C, xdr_cxx.C,
>>>
>>>
>xdrIO.sparc-sun-solaris2.9.g.o...
>
>
>>>in the src/util directory. Do you have any other ways to link the
>>>
>>>
>library.
>
>
>>>Others, PETSc is installed in my unix system, how can I make configure
>>>
>>>
>to
>
>
>>>find it?
>>>
>>>Thanks a lot.
>>>
>>>----- Original Message -----
>>>From: "John Peterson" <pet...@cf...>
>>>To: "Yuna" <hy...@CL...>
>>>Cc: "Ahmed EL-Sheikh" <els...@mc...>;
>>><lib...@li...>
>>>Sent: Saturday, March 06, 2004 8:57 PM
>>>Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias
>>>
>>>
>>>
>>>
>>>>Yuna writes:
>>>> > Hi,
>>>> >
>>>> > I try to run example again. I go to the directory /examples, and
>>>> > run "make METHOD=dbg", all of examples can be compied, but no any
>>>> > executable files were created. Look the compile informations: So
>>>> > what does this mean?
>>>>For some reason it's not linking correctly. All the error messages
>>>>
>>>>
>are
>
>
>>>>coming from the xdr libraries, which is strange since xdr came from
>>>>
>>>>
>Sun!
>
>
>>>>-John
>>>>
>>>>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Libmesh-users mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-users
>
>
|
|
From: Yuna <hy...@CL...> - 2004-03-07 19:14:59
|
Hi, I just run the "make METHOD=dbg run_examples", and I made the example 1 complied ok. But I got errors for the example2. See the following information: **************************************************************************** ************ make[1]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/examples' make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/examples/ex1' *************************************************************** * Running Example ./ex1 *************************************************************** Mesh Information: mesh_dimension()=3 spatial_dimension()=3 n_nodes()=27 n_elem()=1 n_local_elem()=1 n_active_elem()=1 n_subdomains()=1 n_processors()=1 processor_id()=0 --------------------------------------------------------------------------- - | Reference count information | --------------------------------------------------------------------------- - | 4Elem reference count information: | Creations: 7 | Destructions: 7 | 4Node reference count information: | Creations: 27 | Destructions: 27 --------------------------------------------------------------------------- - *************************************************************** * Done Running Example ./ex1 *************************************************************** make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/examples/ex1' make[2]: Entering directory `/users/hyuna/myResearch/libmesh-0.4.2/examples/ex2' Compiling C++ (in debug mode) ex2.C... Linking ex2... collect2: ld terminated with signal 11 [Segmentation Fault] make[2]: *** [ex2] Error 1 make[2]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/examples/ex2' make[1]: *** [run] Error 2 make[1]: Leaving directory `/users/hyuna/myResearch/libmesh-0.4.2/examples' make: *** [run_examples] Error 2 **************************************************************************** **************** So do you please help me look at what wrong with it? In addition, when I go directly into examples and run " make", it always compiles the code and give me some .o files, but don't build and create any execute files. What the reason is? Yuna ----- Original Message ----- From: "Ahmed Elsheikh" <els...@mc...> To: "Yuna" <hy...@CL...> Cc: <lib...@li...> Sent: Saturday, March 06, 2004 11:10 PM Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias > Hi, > > As in the source code documentation, XDR is a platform-independent > binary I/O system. You have to check the linker options, but it is > tricky :) > > As a temporary solution till you get a complete answer, add > > --disable-xdr to the arguments of configure file ! > > You can use the matlab format for mesh input and gmv or tecplot format > to read the output. > > Regarding PETSC, check if you have the environment variables $PETSC_ARCH > and $PETSC_DIR properly defined. > > Ahmed > > > On Sat, 2004-03-06 at 21:10, Yuna wrote: > > Yes, I use the Unix Sun compiler. When I run make METHOD=dbg, it will > > create some files like xdrIO.C, xdr_cxx.C, xdrIO.sparc-sun-solaris2.9.g.o... > > in the src/util directory. Do you have any other ways to link the library. > > > > Others, PETSc is installed in my unix system, how can I make configure to > > find it? > > > > Thanks a lot. > > > > ----- Original Message ----- > > From: "John Peterson" <pet...@cf...> > > To: "Yuna" <hy...@CL...> > > Cc: "Ahmed EL-Sheikh" <els...@mc...>; > > <lib...@li...> > > Sent: Saturday, March 06, 2004 8:57 PM > > Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias > > > > > > > Yuna writes: > > > > Hi, > > > > > > > > I try to run example again. I go to the directory /examples, and > > > > run "make METHOD=dbg", all of examples can be compied, but no any > > > > executable files were created. Look the compile informations: So > > > > what does this mean? > > > For some reason it's not linking correctly. All the error messages are > > > coming from the xdr libraries, which is strange since xdr came from Sun! > > > > > > -John > |
|
From: Yuna <hy...@CL...> - 2004-03-07 15:56:48
|
Hi Ahmed, Thanks for your advise. I set the environment variables in my .cshrc file, now PETSC directory has been found by the configure. Good! I am now try to run Make again! I still have several things I can's get clearly: 1). What is the different when running make on "OPTIMAL MODE" and "DEBUG MODE"? Which one is better? And generally what method should we use? 2). I remember the input file can be IDEAS .unv file? Am I right? How do I use it? 3). I have a project for finite element analysis for heterogenous material objects. So I have to include material information in both of my element and node classes. Isn't that a good or bad way to modify the origianl libmesh library or can I extend the original mesh and node classes, or do you have any other better way? I am original a fortran programmer, not C++. The reason I hope to switch to C++ is because I like the style of its thingking way, besides I need to link other optimization library which written in C++. So I hope to hear some expert advise of how should I develop my C++ FE application codes? I will report other progress I made later. Thanks for everyone. Yuna ----- Original Message ----- From: "Ahmed Elsheikh" <els...@mc...> To: "Yuna" <hy...@CL...> Cc: <lib...@li...> Sent: Saturday, March 06, 2004 11:10 PM Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias > Hi, > > As in the source code documentation, XDR is a platform-independent > binary I/O system. You have to check the linker options, but it is > tricky :) > > As a temporary solution till you get a complete answer, add > > --disable-xdr to the arguments of configure file ! > > You can use the matlab format for mesh input and gmv or tecplot format > to read the output. > > Regarding PETSC, check if you have the environment variables $PETSC_ARCH > and $PETSC_DIR properly defined. > > Ahmed > > > On Sat, 2004-03-06 at 21:10, Yuna wrote: > > Yes, I use the Unix Sun compiler. When I run make METHOD=dbg, it will > > create some files like xdrIO.C, xdr_cxx.C, xdrIO.sparc-sun-solaris2.9.g.o... > > in the src/util directory. Do you have any other ways to link the library. > > > > Others, PETSc is installed in my unix system, how can I make configure to > > find it? > > > > Thanks a lot. > > > > ----- Original Message ----- > > From: "John Peterson" <pet...@cf...> > > To: "Yuna" <hy...@CL...> > > Cc: "Ahmed EL-Sheikh" <els...@mc...>; > > <lib...@li...> > > Sent: Saturday, March 06, 2004 8:57 PM > > Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias > > > > > > > Yuna writes: > > > > Hi, > > > > > > > > I try to run example again. I go to the directory /examples, and > > > > run "make METHOD=dbg", all of examples can be compied, but no any > > > > executable files were created. Look the compile informations: So > > > > what does this mean? > > > For some reason it's not linking correctly. All the error messages are > > > coming from the xdr libraries, which is strange since xdr came from Sun! > > > > > > -John > |
|
From: Ahmed E. <els...@mc...> - 2004-03-07 04:27:11
|
Hi, As in the source code documentation, XDR is a platform-independent binary I/O system. You have to check the linker options, but it is tricky :) As a temporary solution till you get a complete answer, add --disable-xdr to the arguments of configure file ! You can use the matlab format for mesh input and gmv or tecplot format to read the output. Regarding PETSC, check if you have the environment variables $PETSC_ARCH and $PETSC_DIR properly defined. Ahmed On Sat, 2004-03-06 at 21:10, Yuna wrote: > Yes, I use the Unix Sun compiler. When I run make METHOD=dbg, it will > create some files like xdrIO.C, xdr_cxx.C, xdrIO.sparc-sun-solaris2.9.g.o... > in the src/util directory. Do you have any other ways to link the library. > > Others, PETSc is installed in my unix system, how can I make configure to > find it? > > Thanks a lot. > > ----- Original Message ----- > From: "John Peterson" <pet...@cf...> > To: "Yuna" <hy...@CL...> > Cc: "Ahmed EL-Sheikh" <els...@mc...>; > <lib...@li...> > Sent: Saturday, March 06, 2004 8:57 PM > Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias > > > > Yuna writes: > > > Hi, > > > > > > I try to run example again. I go to the directory /examples, and > > > run "make METHOD=dbg", all of examples can be compied, but no any > > > executable files were created. Look the compile informations: So > > > what does this mean? > > For some reason it's not linking correctly. All the error messages are > > coming from the xdr libraries, which is strange since xdr came from Sun! > > > > -John |
|
From: Yuna <hy...@CL...> - 2004-03-07 02:26:04
|
Yes, I use the Unix Sun compiler. When I run make METHOD=dbg, it will create some files like xdrIO.C, xdr_cxx.C, xdrIO.sparc-sun-solaris2.9.g.o... in the src/util directory. Do you have any other ways to link the library. Others, PETSc is installed in my unix system, how can I make configure to find it? Thanks a lot. ----- Original Message ----- From: "John Peterson" <pet...@cf...> To: "Yuna" <hy...@CL...> Cc: "Ahmed EL-Sheikh" <els...@mc...>; <lib...@li...> Sent: Saturday, March 06, 2004 8:57 PM Subject: Re: [Libmesh-users] Libmesh0.4.2 compiling problem in Solorias > Yuna writes: > > Hi, > > > > I try to run example again. I go to the directory /examples, and > > run "make METHOD=dbg", all of examples can be compied, but no any > > executable files were created. Look the compile informations: So > > what does this mean? > For some reason it's not linking correctly. All the error messages are > coming from the xdr libraries, which is strange since xdr came from Sun! > > -John |
|
From: John P. <pet...@cf...> - 2004-03-07 02:12:38
|
Yuna writes: > Hi, > > I try to run example again. I go to the directory /examples, and > run "make METHOD=dbg", all of examples can be compied, but no any > executable files were created. Look the compile informations: So > what does this mean? For some reason it's not linking correctly. All the error messages are coming from the xdr libraries, which is strange since xdr came from Sun! -John |
197 messages has been excluded from this view by a project administrator.
