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}
(100) 
_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1
(5) 
2
(11) 
3
(3) 
4
(6) 
5
(1) 
6

7

8

9
(1) 
10
(4) 
11

12
(9) 
13
(2) 
14
(6) 
15
(3) 
16

17

18

19

20

21

22

23
(1) 
24
(2) 
25
(1) 
26

27

28

29
(8) 
30
(5) 



From: Ted Kord <teddy.kord@go...>  20090901 23:59:49

Thanks guys but the alterations in code that you gave are not working either. This is the actual equation I'm trying to solve: d/dx (x * du/dx) = 2/x^2 on the domain 1 < x < 2 subject to these boundary conditions: u(1) = 2 (x * du/dx) = 0.5 @ x = 2 Could you possibly show me how to solve this in libmesh with exemplar code. This would really help me get through the boook I'm using to learn the FEM using libmesh. Thank you. Regards Ted 
From: John Peterson <peterson@cf...>  20090901 14:33:11

On Tue, Sep 1, 2009 at 9:06 AM, zeljka<zeljkat@...> wrote: > Hi there! > I am tying to compile the svn version but the following errors occur > > In file included from src/numerics/eigen_solver.C:27: > /home/zeljka/libmesh/include/numerics/eigen_solver.h:200: error: > expected unqualifiedid before ‘<<’ token > /home/zeljka/libmesh/include/numerics/eigen_solver.h:208: error: > expected unqualifiedid before ‘>>’ token It looks to me like you have an SVN conflict in this file? I don't have any such '<<' or '>>' characters in my version of eigen_solver.h  John 
From: zeljka <zeljkat@ge...>  20090901 14:25:37

Hi there! I am tying to compile the svn version but the following errors occur In file included from src/numerics/eigen_solver.C:27: /home/zeljka/libmesh/include/numerics/eigen_solver.h:200: error: expected unqualifiedid before ‘<<’ token /home/zeljka/libmesh/include/numerics/eigen_solver.h:208: error: expected unqualifiedid before ‘>>’ token /home/zeljka/libmesh/include/numerics/eigen_solver.h: In member function ‘libMeshEnums::EigenSolverType EigenSolver<T>::eigen_solver_type() const’: /home/zeljka/libmesh/include/numerics/eigen_solver.h:92: error: ‘_eigen_solver_type’ was not declared in this scope /home/zeljka/libmesh/include/numerics/eigen_solver.h: In member function ‘void EigenSolver<T>::set_eigensolver_type(libMeshEnums::EigenSolverType)’: /home/zeljka/libmesh/include/numerics/eigen_solver.h:109: error: ‘_eigen_solver_type’ was not declared in this scope /home/zeljka/libmesh/include/numerics/eigen_solver.h: In constructor ‘EigenSolver<T>::EigenSolver()’: /home/zeljka/libmesh/include/numerics/eigen_solver.h:241: error: class ‘EigenSolver<T>’ does not have any field named ‘_eigen_solver_type’ /home/zeljka/libmesh/include/numerics/slepc_eigen_solver.h: In constructor ‘SlepcEigenSolver<T>::SlepcEigenSolver() [with T = double]’: src/numerics/eigen_solver.C:47: instantiated from ‘static AutoPtr<EigenSolver<T> > EigenSolver<T>::build(libMeshEnums::SolverPackage) [with T = double]’ src/numerics/eigen_solver.C:68: instantiated from here /home/zeljka/libmesh/include/numerics/slepc_eigen_solver.h:276: error: ‘class SlepcEigenSolver<double>’ has no member named ‘_eigen_solver_type’ make: *** [src/numerics/eigen_solver.x86_64unknownlinuxgnu.opt.o] Error 1 (SLEPc version: 3.0.0p3) Regards, Zeljka. 
From: Vijay S. Mahadevan <vijay.m@gm...>  20090901 05:32:39

Ted, I assume your dirichlet_value=2.0 and neumann_value=0.5 on your assembly routines for the boundary ? If yes, the boundary assembly is not correct. A generic code for bc specification would look like : for (unsigned int side=0; side<elem>n_sides(); side++) if (elem>neighbor(side) == NULL) { const Real penalty = 1.e10; const std::vector<std::vector<Real> >& phi_face = fe_face>get_phi(); const std::vector<Real>& JxW_face = fe_face>get_JxW(); const std::vector<Point >& qface_point = fe_face>get_xyz(); fe_face>reinit(elem, side); for (unsigned int qp=0; qp<qface.n_points(); qp++) { const Real xf = qface_point[qp](0); const Real yf = qface_point[qp](1); const Real zf = qface_point[qp](2); if (bc_id == 0) { const Real value = exact_solution(xf, yf, zf); for (unsigned int i=0; i<phi_face.size(); i++) for (unsigned int j=0; j<phi_face.size(); j++) Ke(i,j) += JxW_face[qp]*penalty*phi_face[i][qp]*phi_face[j][qp]; for (unsigned int i=0; i<phi_face.size(); i++) Fe(i) += JxW_face[qp]*penalty*value*phi_face[i][qp]; } else if (bc_id == 1) { const Real value = neumann_value(xf, yf, zf); for (unsigned int i=0; i<phi_face.size(); i++) Fe(i) += JxW_face[qp]*value*phi_face[i][qp]; } } Most part of it is taken from ex4.C. Substitute in the neumann_value for the side and you should get the right solution. Just look at the variational form for your problem and this should be easy to see. Vijay On Mon, Aug 31, 2009 at 6:57 PM, Ted Kord<teddy.kord@...> wrote: >> >> Well, to impose a Neumann BC on part of the boundary you should only add >> Neumann BC terms to the entries of the rhs vector corresponding to dofs on >> the relevant part of the boundary. So you'd need to detect which part of the >> boundary you're on and add the Neumann BC terms accordingly. Have a look at >> ex13 for an example usage of boundary IDs for this kind of purpose. For more >> complicated domains, I typically generate a mesh using gmsh, which enables >> you to specify boundary IDs (using a gmsh "physical"). >> >> In principle 1D is the same except that in that simpler case the Neumann >> term is not an integral so you don't need a boundary quadrature rule etc... >> Also there are only 2 boundary elements in a 1D mesh so you could easily >> determine which boundary element you're on by testing the value of >> elem>centroid() or something. >> >> If you can't get it to work, then just send your BC code fragment to the >> list... >> >>  Dave >> > > > This is what I've tried. The Dirichlet BC works fine but the plot of the > solution implies that something's terriby wrong with the Neumann B.C : > > for(unsigned int s=0; s<elem>n_sides(); s++) > { > { > Ke(s,s) += penalty; > > short int bc_id = mesh.boundary_info>boundary_id (elem,s); > > if (bc_id == 0) //Left end : Dirichlet BC > Fe(s) += 2*penalty; > else if (bc_id == 1) //Right end : Neumann BC > Fe(s) +=  0.5; > > } > } > > What am I doing incorrectly? > > Thanks > > Ted >  > Let Crystal Reports handle the reporting  Free Crystal Reports 2008 30Day > trial. Simplify your report design, integration and deployment  and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobjjuly > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Ted Kord <teddy.kord@go...>  20090901 03:46:45

> > Well, to impose a Neumann BC on part of the boundary you should only add > Neumann BC terms to the entries of the rhs vector corresponding to dofs on > the relevant part of the boundary. So you'd need to detect which part of the > boundary you're on and add the Neumann BC terms accordingly. Have a look at > ex13 for an example usage of boundary IDs for this kind of purpose. For more > complicated domains, I typically generate a mesh using gmsh, which enables > you to specify boundary IDs (using a gmsh "physical"). > > In principle 1D is the same except that in that simpler case the Neumann > term is not an integral so you don't need a boundary quadrature rule etc... > Also there are only 2 boundary elements in a 1D mesh so you could easily > determine which boundary element you're on by testing the value of > elem>centroid() or something. > > If you can't get it to work, then just send your BC code fragment to the > list... > >  Dave > This is what I've tried. The Dirichlet BC works fine but the plot of the solution implies that something's terriby wrong with the Neumann B.C : for(unsigned int s=0; s<elem>n_sides(); s++) { { Ke(s,s) += penalty; short int bc_id = mesh.boundary_info>boundary_id (elem,s); if (bc_id == 0) //Left end : Dirichlet BC Fe(s) += 2*penalty; else if (bc_id == 1) //Right end : Neumann BC Fe(s) +=  0.5; } } What am I doing incorrectly? Thanks Ted 