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}
(3) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(1) 
2
(10) 
3
(18) 
4

5

6
(2) 
7
(6) 
8
(15) 
9

10
(9) 
11
(8) 
12

13
(1) 
14

15
(10) 
16
(20) 
17
(1) 
18

19

20

21

22
(2) 
23
(13) 
24
(1) 
25

26
(1) 
27

28
(3) 
29
(4) 
30




From: Roy Stogner <roy@st...>  20080410 20:15:54

On Thu, 10 Apr 2008, Mike L wrote: > I am currently starting a project that will involve some mixed FEM work. I > have two coupled equations one equation is solved for each element (which > uses 3 or 4node, elements, solving for an unknown at the centroid of the > element), If you're talking about discontinuous constant elements, this is a capability which libMesh already has; if not then I'd still guess that your element type would be simple to add. > and the second would be solved for each element edge (which I am > proposing to use a normal vector element such as an RT0 at each edge). This, unfortunately, is not a capability libMesh already has  its finite element APIs are designed for scalarvalued elements, and we build vectorvalued mixed elements as tensor products of scalar spaces. For an inherently vectorvalued element like the RT family where this isn't possible, you'd have to add not only the new element but some new base class methods as well. That's not an impossible task, and you'd have people willing to help you, but it's not something you could jump in and do yourself in a couple days. > Looking through the documentation it appears to be both flexible, > and powerful. In the past I have always coded up my own FEM codes, > but I would like to try giving a library like libmesh a try. Is a > mixed problem like the one I am proposing, something that would be > possible to do using libmesh or some other general FEM library? Or > is something of this nature better off coded on my own? If it does > sound like something that libmesh could tackle, are there any code > examples that solve a similar, mixed problem? Thanks in advance. Some mixed elements are fine (see the NavierStokes examples for some P_n^d velocity with P_{n1} pressure examples), but for RT elements you'd have to do some library work within libMesh. I believe deal.II already has RT elements included, but only on quad and hex elements. And of course coding from scratch is always an option, if your needs are simple enough, but it would be significantly harder to add some of the libMesh features to your own code than it would be to add RT0 elements to libMesh. So I guess it depends on what you need. If you can get by without triangles or tetrahedra then I would suggest investigating deal.II. If you need simplices but you don't need parallelism, adaptivity, or any of the other more involved libMesh features then you can probably get by with writing your own code from scratch. In any other case, adding the RT0 elements to libMesh may be your best bet.  Roy 
From: Mike L <mdlibmesh@gm...>  20080410 19:52:18

Hello. I am currently starting a project that will involve some mixed FEM work. I have two coupled equations one equation is solved for each element (which uses 3 or 4node, elements, solving for an unknown at the centroid of the element), and the second would be solved for each element edge (which I am proposing to use a normal vector element such as an RT0 at each edge). Looking through the documentation it appears to be both flexible, and powerful. In the past I have always coded up my own FEM codes, but I would like to try giving a library like libmesh a try. Is a mixed problem like the one I am proposing, something that would be possible to do using libmesh or some other general FEM library? Or is something of this nature better off coded on my own? If it does sound like something that libmesh could tackle, are there any code examples that solve a similar, mixed problem? Thanks in advance. M 
From: Jed Brown <libmesh@59...>  20080410 18:04:19

On Thu 20080410 18:01, pcorreia@... wrote: > I appreciate your answer but in fact I want to define the solver inside > the code since I have different solvers for different systems. > So I rewrite the question: > How to call a direct solver with something like > 'linear_solver>set_solver_type'? > Thanks > Paulo I've only dabbled with libmesh, but it looks like 'ksp_type preonly' does not have an analogue. It looks like you could set it with KSPSetType(linear_solver>ksp(), KSPPREONLY); Choosing LU as a preconditioner is more natural: linear_solver>set_preconditioner_type(LU_PRECOND); If the preconditioning matrix is the same as the system matrix, this should make any iterative method converge after one step. Using 'ksp_type preonly' just eliminates some overhead. Also note that you can set a prefix for a particular solver and then set options using the options database. For example, KSPSetOptionsPrefix(schur_linear_solver>ksp(), "schur_"); and then you can specify options like: schur_ksp_gmres_restart 60 schur_pc_type asm schur_sub_pc_factor_levels 1 I hope this help. Jed 
From: <pcorreia@ue...>  20080410 16:21:23

I appreciate your answer but in fact I want to define the solver inside the code since I have different solvers for different systems. So I rewrite the question: How to call a direct solver with something like 'linear_solver>set_solver_type'? Thanks Paulo > On Thu 20080410 14:09, pcorreia@... wrote: >> Hi, >> How can I use a direct solver to solve a linear system of equations? >> Thanks in advance, >> Paulo > > You can do this entirely with PETSc command line arguments. For instance > > ksp_type preonly pc_type lu > > will solve the system using LU decomposition. If your matrix is > symmetric, you > can try pc_type cholesky. You can select different direct solvers by > changing > the matrix type with mat_type. Run the program with help and you will > see the > supported types (such as umfpack, superlu, aijspooles, sbaijmumps). > Depending > on the problem, you may want to try preconditioning with algebraic > multigrid. > You can build PETSc with libraries like Hypre, ML, and Prometheus, then > use > pc_type hypre. For 3D problems, I find this starts beating a direct > method > for quite small sizes. > > Jed > >  > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: John Peterson <jwpeterson@gm...>  20080410 14:03:03

Great answer, thanks Jed. J On Thu, Apr 10, 2008 at 7:27 AM, Jed Brown <libmesh@...> wrote: > On Thu 20080410 14:09, pcorreia@... wrote: > > Hi, > > How can I use a direct solver to solve a linear system of equations? > > Thanks in advance, > > Paulo > > You can do this entirely with PETSc command line arguments. For instance > > ksp_type preonly pc_type lu > > will solve the system using LU decomposition. If your matrix is symmetric, you > can try pc_type cholesky. You can select different direct solvers by changing > the matrix type with mat_type. Run the program with help and you will see the > supported types (such as umfpack, superlu, aijspooles, sbaijmumps). Depending > on the problem, you may want to try preconditioning with algebraic multigrid. > You can build PETSc with libraries like Hypre, ML, and Prometheus, then use > pc_type hypre. For 3D problems, I find this starts beating a direct method > for quite small sizes. > > Jed > > > >  > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Jed Brown <libmesh@59...>  20080410 12:29:26

On Thu 20080410 14:09, pcorreia@... wrote: > Hi, > How can I use a direct solver to solve a linear system of equations? > Thanks in advance, > Paulo You can do this entirely with PETSc command line arguments. For instance ksp_type preonly pc_type lu will solve the system using LU decomposition. If your matrix is symmetric, you can try pc_type cholesky. You can select different direct solvers by changing the matrix type with mat_type. Run the program with help and you will see the supported types (such as umfpack, superlu, aijspooles, sbaijmumps). Depending on the problem, you may want to try preconditioning with algebraic multigrid. You can build PETSc with libraries like Hypre, ML, and Prometheus, then use pc_type hypre. For 3D problems, I find this starts beating a direct method for quite small sizes. Jed 
From: <pcorreia@ue...>  20080410 12:09:42

Hi, How can I use a direct solver to solve a linear system of equations? Thanks in advance, Paulo 
From: Benjamin Kirk <benjamin.kirk@na...>  20080410 11:05:01

>> ./configure withcc=mpicc withcxx=mpicxx withf77=mpif77 ... >> >> (or whatever mpi compiler wrappers LAM uses) and give it a shot? >> >> The MPI compiler wrappers should find the libraries directly. The >> ULAM_WANT_MPI2CPP may or may not still be necessary. > > I still don't quite understand; what you say sounds like "You have > been doing A before, please try A instead". I assume you mean I > should try configuring PETSc *without* the mpicc like scripts. Anyway, > I tried both, but without success. No, I wanted to make sure you compile *libMesh* with the same mpicclike scripts you use for PETSc. The MPI compiler scripts should get all the MPI libraries automatically, and if they do not then certainly the MPI installation is to blame. Anyway, I am glad you have a workaround. Ben 
From: Tim Kroeger <tim.kroeger@ce...>  20080410 09:17:44

Dear Ben, On Tue, 8 Apr 2008, Benjamin Kirk wrote: >> I now found a way that works. It consists of adding the following two >> lines to Make.common: >> >> >> libmesh_CXXFLAGS += ULAM_WANT_MPI2CPP >> libmesh_LDFLAGS += L/usr/local/lammpi/lib llammpi++ >> >> > > From your petscconf file it seems you built petsc with mpicc and friends, so > libMesh cannot "snoop" the MPI configuration. > > Can you try > > ./configure withcc=mpicc withcxx=mpicxx withf77=mpif77 ... > > (or whatever mpi compiler wrappers LAM uses) and give it a shot? > > The MPI compiler wrappers should find the libraries directly. The > ULAM_WANT_MPI2CPP may or may not still be necessary. I still don't quite understand; what you say sounds like "You have been doing A before, please try A instead". I assume you mean I should try configuring PETSc *without* the mpicc like scripts. Anyway, I tried both, but without success. I decided to give up and use the workaround mentioned above. However, it is not working anymore, although I can't imagine what's different now from two days ago. Hence, I started again adding linker options to include the libs that contain the missing symbols and this time ended up with the following line at the end of Make.common: libmesh_LDFLAGS += L/usr/local/lammpi/lib lmpi llammpi++ llam lutil This makes it work for today. The "ULAM_WANT_MPI2CPP" is no longer required. This seems all very stochastic to me, but perhaps the cluster already senses that I want to do stochastic finite element computations. Best Regards, Tim  Dr. Tim Kroeger Phone +494212187710 tim.kroeger@..., tim.kroeger@... Fax +494212184236 MeVis Research GmbH, Universitaetsallee 29, 28359 Bremen, Germany Amtsgericht Bremen HRB 16222 Geschaeftsfuehrer: Prof. Dr. H.O. Peitgen 