libmesh-users — General information for libmesh users

Re: [Libmesh-users] Configure questions

[danilovdenis <dan...@ya...>]

>Let me know if you have any more trouble.  I know of another user 
>(right, Denis?) who has exactly your configuration working, so it is 
>certainly possible.  I personally don't have access to a Debian machine 
>with the PETSc packages installed, so my troubleshooting is a little 
>limited...

Hi,
Yes, I have libmesh working on debian--woody. There are two things
related to petsc. First you have to set environment variables 
PETSC_DIR and PETSC_ARCH. As Jens said 
PETSC_DIR="/usr/lib/petsc" and PETSC_ARCH="linux". 
Second, the petsc in debian package is *dynamically* linked with
mpi libraries and I had to add them manually to FLIBS in Make.common
after configuration. Ben, would be variables LIBS or LDFLAGS 
the better place for this? I thought, that "F" means fortran in FLIBS.

Denis

Re: [Libmesh-users] Configure questions

[Leopold P. A. <le...@wo...>]

A Dijous 06 Novembre 2003 17:23, Jens Oeser va escriure:
> Hi,
>
> I am running exactly the same installation (woody with petsc) and I set
> PETSC_DIR and PETSC_ARCH in my .bashrc to:
>
> export PETSC_DIR="/usr/lib/petsc"
> export PETSC_ARCH="linux"
>
> I also made a backport from petsc in Debian unstable (version 2.1.6) to
> woody, which is not very difficult. Let me know if there are any
> problems.
>
> Regards
> Jens.

Hi,

thank's.

I have tried it and not it works. How about to put it in a FAQ, README, etc.  
Howeber I have found a new error now. 

lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ make
Makefile:71: warning: overriding commands for target `/rhome/lepalom/Finite'
Makefile:62: warning: ignoring old commands for target `/rhome/lepalom/Finite'
Compiling C++ (in optimized mode) src/base/dof_map.C...
g++: cannot specify -o with -c or -S and multiple compilations
make: *** [src/base/dof_map.i686-pc-linux-gnu.o] Error 1

I have found that it's not a problem with the compiler. It's about some empty 
var in the Makefiles, so the compiler had an error. The complete configure 
output is:


epalom@e01:~/Finite element/libmesh-0.4.1-rc2$ export PETSC_DIR="/usr/lib/
petsc"
lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ export PETSC_ARCH="linux"
lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ ./configure --enable-mpi 
--enable-petsc --enable-laspack
---------------------------------------------
----------- Configuring libMesh -------------
---------------------------------------------
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for g++... g++
checking for C++ compiler default output... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
<<< C++ compiler is gcc-2.95 >>>
<<< Configuring library for broken iostream >>>
checking how to run the C++ preprocessor... g++ -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for short int... yes
checking size of short int... 2
checking for int... yes
checking size of int... 4
checking for long int... yes
checking size of long int... 4
checking for float... yes
checking size of float... 4
checking for double... yes
checking size of double... 8
checking for void *... yes
checking size of void *... 4
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking whether the compiler implements namespaces... yes
checking whether the compiler has locale... no
checking whether the compiler has stringstream... yes
checking hash_map usability... yes
checking hash_map presence... yes
checking for hash_map... yes
checking hash_set usability... yes
checking hash_set presence... yes
checking for hash_set... yes
checking zlib.h usability... no
checking zlib.h presence... no
checking for zlib.h... no
<<< Configuring library with AMR support >>>
<<< Configuring library with expensive data structures enabled >>>
checking rpc/rpc.h usability... yes
checking rpc/rpc.h presence... yes
checking for rpc/rpc.h... yes
<<< Configuring library with XDR support >>>
<<< Configuring library with real number support >>>
<<< Configuring library with reference counting support >>>
checking for ./contrib/netcdf/lib/i686-pc-linux-gnu/libnetcdf.a... no
checking for ./contrib/netcdf/include/netcdf.h... no
---------------------------------------------
----- Configuring for optional packages -----
---------------------------------------------
checking for ./contrib/sfcurves/sfcurves.h... yes
./configure: line 7513: test: /rhome/lepalom/Finite: binary operator expected
checking for ./contrib/gzstream/gzstream.h... yes
./configure: line 7564: test: /rhome/lepalom/Finite: binary operator expected
checking for ./contrib/tecplot/lib/i686-pc-linux-gnu/tecio.a... yes
checking for ./contrib/tecplot/include/TECIO.h... yes
./configure: line 7693: test: too many arguments
checking for ./contrib/laspack/lastypes.h... yes
./configure: line 7746: test: /rhome/lepalom/Finite: binary operator expected
checking for /usr/lib/petsc/include/petsc.h... yes
checking for g77... g77
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether g77 accepts -g... yes
checking how to get verbose linking output from g77... -v
checking for Fortran 77 libraries...  -L/usr/lib/gcc-lib/i386-linux/2.95.4 
-lg2c -lm
<<< Configuring library with PETSc version 2.1.3 support >>>
checking for ./contrib/metis/Lib/metis.h... yes
./configure: line 8530: test: /rhome/lepalom/Finite: binary operator expected
checking for ./contrib/parmetis/Lib/parmetis.h... yes
./configure: line 8581: test: /rhome/lepalom/Finite: binary operator expected
checking for doxygen... /usr/bin/doxygen
checking for dot... no
----------------------------------------------
--- Done configuring for optional packages ---
----------------------------------------------
checking for perl... /usr/bin/perl
configure: creating ./config.status
config.status: creating Make.common
config.status: creating include/mesh_config.h
configure: creating ./config.status
config.status: creating Make.common
config.status: creating doc/Doxyfile
config.status: creating include/mesh_config.h
config.status: include/mesh_config.h is unchanged
---------------------------------------------
--------- Done Configuring libMesh ----------
---------------------------------------------


Leo

Re: [Libmesh-users] Configure questions

[Jens O. <oe...@st...>]

Hi,

I am running exactly the same installation (woody with petsc) and I set
PETSC_DIR and PETSC_ARCH in my .bashrc to:

export PETSC_DIR="/usr/lib/petsc"
export PETSC_ARCH="linux"

I also made a backport from petsc in Debian unstable (version 2.1.6) to
woody, which is not very difficult. Let me know if there are any
problems.

Regards
Jens.

On Thu, 6 Nov 2003 13:15:11 +0100
Leopold Palomo Avellaneda <le...@wo...> wrote:

> Hi,
> 
> I'm new in libmesh and I'm having a problem trying to compile it. I'm
> trying to compile libmesh libmesh-0.4.1-rc2 in a debian woody system.
> I have installed petsc, mpi. Howeber whe I run configure with:
> 
> ./configure --prefix=/usr --enable-mpi --enable-petsc --enable-laspack
> 
> I have this message:
> [...]
> checking for /include/petsc.h... no
> checking for /include/mpi.h... no
> checking for /lib/libmpich.a... no
> [...]
> 
> In general, in a debian system this files are in:
> /usr/include/petsc/petsc.h
> /usr/include/mpi/mpi.h
> /usr/lib/mpich/lib/libmpich.a
> 
> How I can to tell to configure that look in that places? 
> 
> Best regards,
> 
> Leo
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users


-- 
Clothes make the man.  Naked people have little or no influence on
society.
		-- Mark Twain

Re: [Libmesh-users] Configure questions

[Leopold P. A. <le...@wo...>]

A Dijous 06 Novembre 2003 16:51, Benjamin S. Kirk va escriure:
> On most systems where PETSc is installed from source the environment
> variables PETSC_DIR and PETSC_ARCH are used to describe the
> installation.   For example, on my machine, the values for these
> variables are:
>
> hactar(4)$ echo $PETSC_DIR
> /usr/local/petsc/petsc-2.1.5
> hactar(5)$ echo $PETSC_ARCH
> linux
>
>
> so, for your system I think this should work:
>
> export PETSC_DIR=/usr
> export PETSC_ARCH=linux
>
> and re-run configure.
>
> We currently do not support a 'make install' target, so at the moment
> the --prefix=/usr command line argument will have no effect and may be
> omitted.
>
> Let me know if you have any more trouble.  I know of another user
> (right, Denis?) who has exactly your configuration working, so it is
> certainly possible.  I personally don't have access to a Debian machine
> with the PETSc packages installed, so my troubleshooting is a little
> limited...
>
> -Ben

Hi Ben,

thank's for the answer. Sadly I say htat I have some trouble.... :-(
lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ export PETSC_DIR=/usr
lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ export PETSC_ARCH=linux
lepalom@e01:~/Finite element/libmesh-0.4.1-rc2$ ./configure --enable-mpi 
--enable-petsc --enable-laspack

.....
checking for /usr/include/petsc.h... no
checking for /include/mpi.h... no
checking for /lib/libmpich.a... no
.....

The question is the configure checks for include/petsch.h, and no, in a debian 
system in general in the /usr/include/ there are the directories with the 
name of the directory and inside the headers, so your /usr/include/ has some 
kind or ordre. I think that it's necessary to change the aclocal.m4 in the 
line 505:

......
AC_DEFUN(CONFIGURE_PETSC,
[
  AC_CHECK_FILE($PETSC_DIR/include/petsc.h,
                PETSC_H_PATH=$PETSC_DIR/include/petsc.h)

  if (test -r $PETSC_DIR/include/petsc.h) ; then

... I think that this macro is not good. You think that all the tditributions 
of petsc put the petsc.h header in a include directory, and for example 
debian doens't.

So, probably is necessary to change this macro, and re-run autoconf to create 
the configure file. IMO. But I have tried to modify it and I have lost :-(

Leo



Leo

Re: [Libmesh-users] Configure questions

[Benjamin S. K. <be...@cf...>]

On most systems where PETSc is installed from source the environment 
variables PETSC_DIR and PETSC_ARCH are used to describe the 
installation.   For example, on my machine, the values for these 
variables are:

hactar(4)$ echo $PETSC_DIR
/usr/local/petsc/petsc-2.1.5
hactar(5)$ echo $PETSC_ARCH
linux


so, for your system I think this should work:

export PETSC_DIR=/usr
export PETSC_ARCH=linux

and re-run configure.

We currently do not support a 'make install' target, so at the moment 
the --prefix=/usr command line argument will have no effect and may be 
omitted.

Let me know if you have any more trouble.  I know of another user 
(right, Denis?) who has exactly your configuration working, so it is 
certainly possible.  I personally don't have access to a Debian machine 
with the PETSc packages installed, so my troubleshooting is a little 
limited...

-Ben

[Libmesh-users] Configure questions

[Leopold P. A. <le...@wo...>]

Hi,

I'm new in libmesh and I'm having a problem trying to compile it. I'm trying 
to compile libmesh libmesh-0.4.1-rc2 in a debian woody system. I have 
installed petsc, mpi. Howeber whe I run configure with:

./configure --prefix=/usr --enable-mpi --enable-petsc --enable-laspack

I have this message:
[...]
checking for /include/petsc.h... no
checking for /include/mpi.h... no
checking for /lib/libmpich.a... no
[...]

In general, in a debian system this files are in:
/usr/include/petsc/petsc.h
/usr/include/mpi/mpi.h
/usr/lib/mpich/lib/libmpich.a

How I can to tell to configure that look in that places? 

Best regards,

Leo

Re: [Libmesh-users] May be a simple problem?!?

[Benjamin S. K. <be...@cf...>]

The problem is that there is no default constructor for Node objects. 
The reason for this is that the Mesh creates nodes, you probably just 
want to use the ones in the Mesh.

The code you have written might have unexpected consequences.  You are 
in effect copying the Nodes and all their associated data into your 
ElectrPos vector.  The library may, at some later time, decide to change 
the Node-DOF association, and you would be stuck with old values in your 
vector that don't apply to the modified mesh.  This could occur as a 
consequence of mesh refinement, for example.

I suggest that instead of copying the nodes outright you get pointers to 
them.  This will have two beneficial consequences:

1.) You avoid the "stale information" problem I describe above
2.) It saves space.  A pointer is much smaller than a Node.

I would change the code to this:

     const Mesh& mesh = nonconst_mesh;
		
     std::vector<const Node*> ElectrPos;

     unsigned int n_nodes = mesh.n_nodes();

     for (unsigned int n_cnt=0; n_cnt<n_nodes; n_cnt++)
       {
	const Node* curr_node_ptr = mesh.node_ptr(n_cnt);
	
	if (mesh.data.has_data (curr_node_ptr))
	  {
	    const std::vector<Number>& node_data =
	      mesh.data.get_data (curr_node_ptr);
	
	    if (node_data[0]==-99)
	      ElectrPos.push_back(curr_node_ptr);
	  }
       }

Note that std::vector<>::resize() handles the sizing issues for you, so 
there is no need to have the ElectrCount variable.  Of course, after the 
loop ElectrPos.size() will give you exactly the same information.

Since ElectrPos now contains pointers the syntax of how you use it will 
be changed, but everything else should be fine...  For example,

ElectrPos[num].dof_number(...)

becomes

ElectrPos[num]->dof_number(...)

Hope this helps.

-Ben



Jens Oeser wrote:
> Hi,
> 
> I've written a direct current modelling program for geophysical purposes
> with libmesh. Till now every thing seems to work quit proper. So far so
> good.
> 
> But now to my problem, which is quit simple so I think, but I could not
> solve it. I have data associated to each node. Now I would like to
> create a vector of nodes, in which the nodes marked as a electrode
> position are stored (the marker is -99). To solve this I've done the
> following:
> 
> const Mesh& const_mesh = mesh;
> 		
> std::vector<Number> node_data;
> std::vector<Node> ElectrPos;
> unsigned int ElectrCount=1;
> 
> unsigned int n_nodes = mesh.n_nodes();
> 		
> for (unsigned int n_cnt=0; n_cnt<n_nodes; n_cnt++)
> {
> 	const Node& curr_node = const_mesh.node(n_cnt);
> 	const Node* curr_node_ptr = const_mesh.node_ptr(n_cnt);
> 
> 	if (mesh.data.has_data (curr_node_ptr))
> 	{
> 		node_data = mesh.data.get_data (curr_node_ptr);
> 		if (node_data[0]==-99)
> 		{
> 			ElectrPos.resize(ElectrCount);
> 			ElectrPos.push_back(curr_node);
> 			ElectrCount++;
> 		}
> 	}
> }
> 
> The problem is, that it's not possible to resize the vector ElectrPos.
> The compiler complains:
> /usr/include/c++/3.3/bits/stl_vector.h: In member function `void 
>    std::vector<_Tp, _Alloc>::resize(unsigned int) [with _Tp = Node,
> _Alloc =    std::allocator<Node>]':
> InOut.C:163:   instantiated from here
> /usr/include/c++/3.3/bits/stl_vector.h:452: error: no matching function
> for    call to `Node::Node()'
> /home/oeser/DA/libmesh/include/node.h:150: error: candidates are: 
>    Node::Node(const Point&, unsigned int = DofObject::invalid_id)
> /home/oeser/DA/libmesh/include/node.h:139: error:                 
>    Node::Node(const Node&)
> /home/oeser/DA/libmesh/include/node.h:130: error:                 
>    Node::Node(double, double, double, unsigned int)
> 
> If I change ElectrPos.resize(ElectrCount) to
> ElectrPos.resize(curr_node) as the compiler mentioned (with absence of
> understanding why I should do this), the compiler complains:
> InOut.C:163: error: no matching function for call to `std::vector<Node, 
>    std::allocator<Node> >::resize(const Node&)'
> /usr/include/c++/3.3/bits/stl_vector.h:434: error: candidates are: void 
>    std::vector<_Tp, _Alloc>::resize(unsigned int, const _Tp&) [with _Tp
> = Node,    _Alloc = std::allocator<Node>]
> /usr/include/c++/3.3/bits/stl_vector.h:452: error:                 void 
>    std::vector<_Tp, _Alloc>::resize(unsigned int) [with _Tp = Node,
> _Alloc =    std::allocator<Node>]
> 
> What's going on, where is the problem? Because I'm currently new to OOP
> and C++ I could not solve the problem. But I hope you can give me some
> hints or a other way to solve the problem.
> 
> I think I need to store the reference, because I need to call
> DofObject::dof_number for these nodes.
> 
> Best regards.
> Jens.
> 

[Libmesh-users] May be a simple problem?!?

[Jens O. <oe...@st...>]

Hi,

I've written a direct current modelling program for geophysical purposes
with libmesh. Till now every thing seems to work quit proper. So far so
good.

But now to my problem, which is quit simple so I think, but I could not
solve it. I have data associated to each node. Now I would like to
create a vector of nodes, in which the nodes marked as a electrode
position are stored (the marker is -99). To solve this I've done the
following:

const Mesh& const_mesh = mesh;
		
std::vector<Number> node_data;
std::vector<Node> ElectrPos;
unsigned int ElectrCount=1;

unsigned int n_nodes = mesh.n_nodes();
		
for (unsigned int n_cnt=0; n_cnt<n_nodes; n_cnt++)
{
	const Node& curr_node = const_mesh.node(n_cnt);
	const Node* curr_node_ptr = const_mesh.node_ptr(n_cnt);

	if (mesh.data.has_data (curr_node_ptr))
	{
		node_data = mesh.data.get_data (curr_node_ptr);
		if (node_data[0]==-99)
		{
			ElectrPos.resize(ElectrCount);
			ElectrPos.push_back(curr_node);
			ElectrCount++;
		}
	}
}

The problem is, that it's not possible to resize the vector ElectrPos.
The compiler complains:
/usr/include/c++/3.3/bits/stl_vector.h: In member function `void 
   std::vector<_Tp, _Alloc>::resize(unsigned int) [with _Tp = Node,
_Alloc =    std::allocator<Node>]':
InOut.C:163:   instantiated from here
/usr/include/c++/3.3/bits/stl_vector.h:452: error: no matching function
for    call to `Node::Node()'
/home/oeser/DA/libmesh/include/node.h:150: error: candidates are: 
   Node::Node(const Point&, unsigned int = DofObject::invalid_id)
/home/oeser/DA/libmesh/include/node.h:139: error:                 
   Node::Node(const Node&)
/home/oeser/DA/libmesh/include/node.h:130: error:                 
   Node::Node(double, double, double, unsigned int)

If I change ElectrPos.resize(ElectrCount) to
ElectrPos.resize(curr_node) as the compiler mentioned (with absence of
understanding why I should do this), the compiler complains:
InOut.C:163: error: no matching function for call to `std::vector<Node, 
   std::allocator<Node> >::resize(const Node&)'
/usr/include/c++/3.3/bits/stl_vector.h:434: error: candidates are: void 
   std::vector<_Tp, _Alloc>::resize(unsigned int, const _Tp&) [with _Tp
= Node,    _Alloc = std::allocator<Node>]
/usr/include/c++/3.3/bits/stl_vector.h:452: error:                 void 
   std::vector<_Tp, _Alloc>::resize(unsigned int) [with _Tp = Node,
_Alloc =    std::allocator<Node>]

What's going on, where is the problem? Because I'm currently new to OOP
and C++ I could not solve the problem. But I hope you can give me some
hints or a other way to solve the problem.

I think I need to store the reference, because I need to call
DofObject::dof_number for these nodes.

Best regards.
Jens.

-- 

[Libmesh-users] Re: Unused nodes

[Denis D. <dan...@ya...>]

Hmm... you are right, there is a memory leak...

And it depends on how many times I make "mesh refinement->equation system
reinit". Reference counting in libmesh and -log_summary option of petsc
give nothing (i.e. equal numbers of created and destroyed objects).
Valgrind is more careful. The full output of valgrind and ex10 is
atteched. There is one message about petsc, and messages about function
DofObject::set_old_dof_object(void)... I got the same errors for my
programm also.

Regards,
Denis


On Wed, Sep 24, 2003 at 05:33:45PM -0500, Benjamin S. Kirk wrote:
> [I have sent this to the new libmesh-users list]
> 
> OK, I'll get you a patch that you can try.  It would be nice to have an 
> option to remove the nodes, I agree...  This will certainly reduce the 
> disk space required.
> 
> I'm still worried about the memory usage you report.  is the memory 
> usage ~1/2 as much after 5000 time steps?  ~1/4 as much after 2500 time 
> steps??  It seems like there could be a memory leak occuring at each 
> time step.  Make sure you are running in debug mode & try the 
> -log_summary option, which will print memory usage statistics (from 
> PETSc) when the program quits.    The program valgrind can also be 
> useful in finding memory leaks.
> 
> The only reason I mention this is because I routinely work with meshes 
> that have on the order of 200k nodes and it doesn't require nearly that 
> much memory.
> 
> I know what needs to be changed in addition to the patch you sent 
> earlier.  I'll explain it more when I submit my patch later.
> 
> -Ben
> 

[Libmesh-users] Re: [Libmesh-devel] Unused nodes

[Benjamin S. K. <be...@cf...>]

[I have sent this to the new libmesh-users list]

OK, I'll get you a patch that you can try.  It would be nice to have an 
option to remove the nodes, I agree...  This will certainly reduce the 
disk space required.

I'm still worried about the memory usage you report.  is the memory 
usage ~1/2 as much after 5000 time steps?  ~1/4 as much after 2500 time 
steps??  It seems like there could be a memory leak occuring at each 
time step.  Make sure you are running in debug mode & try the 
-log_summary option, which will print memory usage statistics (from 
PETSc) when the program quits.    The program valgrind can also be 
useful in finding memory leaks.

The only reason I mention this is because I routinely work with meshes 
that have on the order of 200k nodes and it doesn't require nearly that 
much memory.

I know what needs to be changed in addition to the patch you sent 
earlier.  I'll explain it more when I submit my patch later.

-Ben



Denis Danilov wrote:

>On Mon, Sep 22, 2003 at 11:40:00AM -0500, John Peterson wrote:
> 
>  
>
>>Yes this is a design decision.  During successive coarsening
>>and refinement, the same nodes could be created and destroyed
>>multiple times.  It was felt that keeping them in the nodes vector
>>was a reasonable tradeoff of space for performance.
>>    
>>
>
>This is right for quasi-stationary problems with weak time dependence,
>where only small number of cell will be coarsened (relative to number of
>refined cell). But what about "moving boundary" problems with high
>refined mesh only in the vicinity of moving interface? For example, when
>interface advances from one corner into the domain.
> 
>  
>
>>Is there a good reason you really need to do this?  For the patch
>>to be accepted, you would probably need to contribute a version
>>which can be turned on/off during configure similar to the infinite
>>elements.
>>    
>>
>
>There are one reason --- usage of memory and hard disk place. I run my
>program and see that it requires about 1.7 GB memory (after 10000 time
>steps, each time step includes mesh "refinement/coarsen"). For this time
>step the mesh consists of 36441 elements (27487 active) and 177099 nodes
>are stored in the mesh. I hope that memory usage will be reduced to ~700
>MB (or even less) if unused nodes will be deleted. The other thing is
>hard disk place. Look into out.gmv files of ex10 and you will see a
>lot of zeros in sections "nodes" and "variable". This is "solution" at
>unused nodes. So, in my case, with 36441 elements and 177099 the
>gmv-file consists almost fully of zeros.
>
>Regards,
>Denis
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Libmesh-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>  
>