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}
(11) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2
(1) 
3

4

5

6

7

8

9

10

11

12
(1) 
13
(7) 
14
(2) 
15
(2) 
16
(2) 
17
(2) 
18

19
(4) 
20
(1) 
21

22

23

24

25

26

27
(12) 
28
(7) 
29
(5) 
30
(4) 

From: Min Xu <minxu@sc...>  20050930 15:26:47

Hi, Roy: I tried cvs update and your change did not show up yet. You could send your affected file to me if possible. Min On Friday 30 September 2005 09:40, Roy Stogner wrote: > On Fri, 30 Sep 2005, Min Xu wrote: > > ERROR: Unsupported 2D element type!: 1 > > [0] src/fe/fe_lagrange_shape_2D.C, line 196, compiled Sep 29 2005 at > > 08:52:36 p0_26805: p4_error: interrupt SIGx: 6 > > Yeah, this was my fault. Try it again after a cvs update. >  > Roy Stogner > > >  > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20050930 13:40:54

On Fri, 30 Sep 2005, Min Xu wrote: > ERROR: Unsupported 2D element type!: 1 > [0] src/fe/fe_lagrange_shape_2D.C, line 196, compiled Sep 29 2005 at 08:52:36 > p0_26805: p4_error: interrupt SIGx: 6 Yeah, this was my fault. Try it again after a cvs update.  Roy Stogner 
From: Roy Stogner <roystgnr@ic...>  20050930 13:15:41

On Fri, 30 Sep 2005, Min Xu wrote: > The patched ex4.C works well in 2D. Yet in 3D, > > ERROR: Unsupported 2D element type!: 1 > [0] src/fe/fe_lagrange_shape_2D.C, line 196, compiled Sep 29 2005 at 08:52:36 > p0_26805: p4_error: interrupt SIGx: 6 That looks like a bug in my new projection function. I'll let you know once I've got a patch in CVS.  Roy Stogner 
From: Min Xu <minxu@sc...>  20050930 12:55:35

Hi: I patched the original ex4.C to add an init_function: < // initialize the system < Number initial_value_poisson (const Point& p, < const Parameters& parameters, < const std::string& system_name, < const std::string& varname) < { < return 0; < } < < void init_poisson (EquationSystems& es, < const std::string& system_name) < { < // It is a good idea to make sure we are initializing < // the proper system. < assert (system_name == "Poisson"); < < // Get a reference to the Diffusion system object. < LinearImplicitSystem& system = < es.get_system<LinearImplicitSystem> ("Poisson"); < < system.project_solution(initial_value_poisson, NULL, es.parameters); < } 210d187 < system.attach_init_function (init_poisson); The patched ex4.C works well in 2D. Yet in 3D, Running ./ex4 d 3 n 15 Mesh Information: mesh_dimension()=3 spatial_dimension()=3 n_nodes()=29791 n_elem()=3375 n_local_elem()=3375 n_active_elem()=3375 n_subdomains()=1 n_processors()=1 processor_id()=0 ERROR: Unsupported 2D element type!: 1 [0] src/fe/fe_lagrange_shape_2D.C, line 196, compiled Sep 29 2005 at 08:52:36 p0_26805: p4_error: interrupt SIGx: 6 Best regards, Min Xu 
From: Shaoying Lu <sylu@ad...>  20050929 16:49:23

Hi,=20 I am using libmesh to solve reactiondiffusion equation systems and to = simulate calcium dynamics in cardiac cells.=20 Shaoying (Kathy) Lu Original Message From: libmeshusersadmin@... on behalf of John = Peterson Sent: Tue 9/27/2005 8:30 AM To: libmeshdevel@...; = libmeshusers@... Subject: [Libmeshusers] What do you use LibMesh for? =20 Hi, I believe this topic has been touched on before some time ago, but I'm in the process of making a list of applications that LibMesh is being used for. Please post to the list the any applications/PDEs you have used LibMesh to solve, whether they are class projects, formal research, or something in between. Thanks! Let me get the list started: .) Incompressible NavierStokes (natural convection) .) Burgers' Equation (1D) .) DoubleDiffusive Convection in Porous Media .) Tumor Angiogenesis modeling .) Linear AdvectionDiffusionReaction .) e. Coli proliferation problems =20  SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. = Download it for free  and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Michael Povolotskyi <povolotskyi@in...>  20050929 15:19:25

Dear Libmesh developers, I'm implementing additional DOF in the way you suggested. 1) I define a new variable of type monomial constant. 2) I define two vectors that store DOF numbers: vector dof_indices is defined by dof_map.dof_indices (elem, dof_indices) and add_dofs_vector is defined by my routines. I built a matrix block that couples "normal" and additional variables: Ke_u_add.resize(dof_indices.size(), add_dofs_vector.size() ); 3) If there is no adaptive mesh refinement I simply use system.matrix>add_matrix(Ke_u_add,dof_indices,add_dofs_vector); and everything works. In the case of adaptive mesh refinement I try to use dof_map.constrain_element_matrix(Ke_u_add,dof_indices,add_dofs_vector); and then system.matrix>add_matrix(Ke_u_add,dof_indices,add_dofs_vector); This does not work because dof_map.constrain_element_matrix changes size of dof_indices and does not change size of Ke_u_add. What is wrong in my approach? Thank you very much, Michael. 
From: Wout Ruijter <woutruijter@gm...>  20050929 14:35:52

Hello Michael, On 9/29/05, Michael Schindler <mschindler@...> wrote: > > Hello Wout, > On 29.09.05, Wout Ruijter wrote: > > On 9/28/05, Michael Schindler <mschindler@...> wrote= : > > On 27.09.05, Roy Stogner wrote: > > > > On Tue, 27 Sep 2005, Wout Ruijter wrote: > > > > > > > > >Three questions regarding periodic boundary conditions: > > > > >1  Michael already showed how to implement periodic bc's of type > > > > >u(l)=3Du(r), > > > > >how do you add u(l)u(r)=3Dx? Is that a matter of modifying the > > > > >righthandside? > > > > >I mean, is the rhs taken into account for constrained dof? > > > > > > Exactly. At the moment only homogeneous constraints are supported. If > > > you really need inhomogeneous constraints you need two things: > > > 1. A marker pseudoDOFnumber that collects the inhomoheneity in the > > > ConstraintsRow > > > 2. patch the source code of libmesh. The function that really does th= e > > > constraint resolving. > > > I'm trying, in dof_map.h > > >>>>>>> > > //typedef std::map<unsigned int, Real> DofConstraintRow; > > > > class DofConstraintRow : public std::map<unsigned int,Real> > > { > > public: > > Real rhs; > > DofConstraintRow(){rhs =3D0.0;}; > > }; > > <<<<<<< > > > and in dof_map_constraints.C > > >>>>>>> > > for (unsigned int i=3D0; i<elem_dofs.size(); i++) > > if (this>is_constrained_dof(elem_dofs[i])) > > { > > // If the DOF is constrained > > DofConstraints::const_iterator > > pos =3D _dof_constraints.find(elem_dofs[i]); // find the constraint row > > > > assert (pos !=3D _dof_constraints.end()); > > > > const DofConstraintRow& constraint_row =3D pos>second; > > > > // assert (!constraint_row.empty()); // check that it is not empty > > // this should not be used because a > > // constraint of type u(n)=3Drhs > > // should be legal > > > > rhs(i) =3D constraint_row.rhs; > > // rhs(i) =3D 0.0; > > > > // std::cout<< "rhs =3D " <<rhs(i)<<std::endl; > > } > > <<<<<<<< > > and of course, you will need to change the routine that really does > the job, > > DofMap::constrain_element_matrix_and_vector > > in dof_map_constraints.C. It needs to know of the righthand side. > I had also to enlarge > > build_constraint_matrix > in order to also provide the rhs vector: > build_constraint_matrix_and_vector > > and so on ... > I need this for slip boundary conditions, where I have no > alternative. > > > But the easiest thing is to consider if you really need the the > > > inhomogeneous constraints. I had the simple case where I wanted a > > > pressuredriven flow, and the pressure had to fulfill similar > > > inhomogeneous constraints. But this could easily be avoided by adding > > > a constant gradient in the NavierStokes equation. > > > What kind of system do you need the constraints for? > > > > > > I need them for elastostatics, so nodes on opposite sides of a unit cel= l > > moving such that the unit cell remains repeatable. > > You have a position variable x(xi) for the nodes, right? > x is the cartesian component, xi a reference coordinate, in your case > also the cartesian one. > To make the whole thing repeatable your constraints for nodes i and j > (on a left/right boundary resp.) look like > > x_i =3D x_j + X > > where X is the periodicity vector. > Why not replace the variable x by something that takes X already into > account? > When the left reference boundary is xi=3D0 and the right one xi=3D1, then > you can define a new position variable > > p(xi) =3D x(xi) + xi * X > grad(p) =3D grad(x) + X > > and you will end up with homogeneous constraints > > p_i =3D p_j > > This is exactly what I have done with a constant pressure gradient. > And you can do that in arbitrary dimensions as long as you fill space > with a Bravais grid. This seems a nice way to deal with it, however, this means I have to reformulate my assembly and postprocessing functions in terms of p, right? I'll have a look at it, but I will first finalize the nonhomogeneous constraints. > > This is a serious problem. In most cases the _dof_coupling is already > > > built when you impose the constraints. Then, the Petsc solver will > > > have to enlarge its dofcoupling every time you fill the matrix at an > > > unexpected position. This makes the story damn slow. > > > Therefore, you will need to create the constraints _before_ the > > > dofcoupling is built. This is exactly what happens to the > > > hangingnode constraints. > > > > I take it you mean the dof_map, not the DofMap._dof_coupling. > > I am not quite sure at the moment. What I really mean is the sparsity > pattern in the Petsc matrix. You do not really want to fill the matrix > with values at unexpected positions. This makes Petsc slow. Ok, I think I know where to look. > I took me a long time to recognize this issue, and maybe there is > > > another solution, but I ended up by drilling a hole into the complete > > > library. I now have something like "attach_constrain_function" which > works > > > similar as "attach_assemble_function" and which is called from inside > > > the library right after the hanging nodes have been built. > > > > Thanks for pointing this out, this seems a difficult one, but I think > your > > solution would be the only way to have the desirable behaviour that: > > 1. The periodic or any new constraints override the hanging node > couplings > > 2. They are taken into account when building the dof map > > I have not found another way to do that. I must say I find it quite a nice solution, apart from the fact that does not come standard. So why search for an alternative? Greetings Wout Greetings, > Michael Schindler > >  > "A mathematician is a device for turning coffee into theorems" > Paul Erd=F6s. > > >  > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Michael Schindler <mschindler@us...>  20050929 11:00:48

Hello Wout, On 29.09.05, Wout Ruijter wrote: > On 9/28/05, Michael Schindler <mschindler@...> wrote: > On 27.09.05, Roy Stogner wrote: > > > On Tue, 27 Sep 2005, Wout Ruijter wrote: > > > > > > >Three questions regarding periodic boundary conditions: > > > >1  Michael already showed how to implement periodic bc's of type > > > >u(l)=u(r), > > > >how do you add u(l)u(r)=x? Is that a matter of modifying the > > > >righthandside? > > > >I mean, is the rhs taken into account for constrained dof? > > > > Exactly. At the moment only homogeneous constraints are supported. If > > you really need inhomogeneous constraints you need two things: > > 1. A marker pseudoDOFnumber that collects the inhomoheneity in the > > ConstraintsRow > > 2. patch the source code of libmesh. The function that really does the > > constraint resolving. > I'm trying, in dof_map.h > >>>>>>> > //typedef std::map<unsigned int, Real> DofConstraintRow; > > class DofConstraintRow : public std::map<unsigned int,Real> > { > public: > Real rhs; > DofConstraintRow(){rhs =0.0;}; > }; > <<<<<<< > and in dof_map_constraints.C > >>>>>>> > for (unsigned int i=0; i<elem_dofs.size(); i++) > if (this>is_constrained_dof(elem_dofs[i])) > { > // If the DOF is constrained > DofConstraints::const_iterator > pos = _dof_constraints.find(elem_dofs[i]); // find the constraint row > > assert (pos != _dof_constraints.end()); > > const DofConstraintRow& constraint_row = pos>second; > > // assert (!constraint_row.empty()); // check that it is not empty > // this should not be used because a > // constraint of type u(n)=rhs > // should be legal > > rhs(i) = constraint_row.rhs; > // rhs(i) = 0.0; > > // std::cout<< "rhs = " <<rhs(i)<<std::endl; > } > <<<<<<<< and of course, you will need to change the routine that really does the job, DofMap::constrain_element_matrix_and_vector in dof_map_constraints.C. It needs to know of the righthand side. I had also to enlarge build_constraint_matrix in order to also provide the rhs vector: build_constraint_matrix_and_vector and so on ... I need this for slip boundary conditions, where I have no alternative. > But the easiest thing is to consider if you really need the the > > inhomogeneous constraints. I had the simple case where I wanted a > > pressuredriven flow, and the pressure had to fulfill similar > > inhomogeneous constraints. But this could easily be avoided by adding > > a constant gradient in the NavierStokes equation. > > What kind of system do you need the constraints for? > > > I need them for elastostatics, so nodes on opposite sides of a unit cell > moving such that the unit cell remains repeatable. You have a position variable x(xi) for the nodes, right? x is the cartesian component, xi a reference coordinate, in your case also the cartesian one. To make the whole thing repeatable your constraints for nodes i and j (on a left/right boundary resp.) look like x_i = x_j + X where X is the periodicity vector. Why not replace the variable x by something that takes X already into account? When the left reference boundary is xi=0 and the right one xi=1, then you can define a new position variable p(xi) = x(xi) + xi * X grad(p) = grad(x) + X and you will end up with homogeneous constraints p_i = p_j This is exactly what I have done with a constant pressure gradient. And you can do that in arbitrary dimensions as long as you fill space with a Bravais grid. > > This is a serious problem. In most cases the _dof_coupling is already > > built when you impose the constraints. Then, the Petsc solver will > > have to enlarge its dofcoupling every time you fill the matrix at an > > unexpected position. This makes the story damn slow. > > Therefore, you will need to create the constraints _before_ the > > dofcoupling is built. This is exactly what happens to the > > hangingnode constraints. > > I take it you mean the dof_map, not the DofMap._dof_coupling. I am not quite sure at the moment. What I really mean is the sparsity pattern in the Petsc matrix. You do not really want to fill the matrix with values at unexpected positions. This makes Petsc slow. > I took me a long time to recognize this issue, and maybe there is > > another solution, but I ended up by drilling a hole into the complete > > library. I now have something like "attach_constrain_function" which works > > similar as "attach_assemble_function" and which is called from inside > > the library right after the hanging nodes have been built. > > Thanks for pointing this out, this seems a difficult one, but I think your > solution would be the only way to have the desirable behaviour that: > 1. The periodic or any new constraints override the hanging node couplings > 2. They are taken into account when building the dof map I have not found another way to do that. Greetings, Michael Schindler  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Wout Ruijter <woutruijter@gm...>  20050929 10:27:13

Micheal, thanks for your pointers there On 9/28/05, Michael Schindler <mschindler@...> wrote: > > Hello, > > although I am probably not the Michael that Wout refers to ;) I have > also tried to implement the constraints for several purposes It seems that being a Micheal is periodically coupled to an abnormal interest in periodic boundary conditions ;) On 27.09.05, Roy Stogner wrote: > > On Tue, 27 Sep 2005, Wout Ruijter wrote: > > > > >Three questions regarding periodic boundary conditions: > > >1  Michael already showed how to implement periodic bc's of type > > >u(l)=3Du(r), > > >how do you add u(l)u(r)=3Dx? Is that a matter of modifying the > > >righthandside? > > >I mean, is the rhs taken into account for constrained dof? > > Exactly. At the moment only homogeneous constraints are supported. If > you really need inhomogeneous constraints you need two things: > 1. A marker pseudoDOFnumber that collects the inhomoheneity in the > ConstraintsRow > 2. patch the source code of libmesh. The function that really does the > constraint resolving. I'm trying, in dof_map.h >>>>>>> //typedef std::map<unsigned int, Real> DofConstraintRow; class DofConstraintRow : public std::map<unsigned int,Real> { public: Real rhs; DofConstraintRow(){rhs =3D0.0;}; }; <<<<<<< and in dof_map_constraints.C >>>>>>> for (unsigned int i=3D0; i<elem_dofs.size(); i++) if (this>is_constrained_dof(elem_dofs[i])) { // If the DOF is constrained DofConstraints::const_iterator pos =3D _dof_constraints.find(elem_dofs[i]); // find the constraint row assert (pos !=3D _dof_constraints.end()); const DofConstraintRow& constraint_row =3D pos>second; // assert (!constraint_row.empty()); // check that it is not empty // this should not be used because a // constraint of type u(n)=3Drhs // should be legal rhs(i) =3D constraint_row.rhs; // rhs(i) =3D 0.0; // std::cout<< "rhs =3D " <<rhs(i)<<std::endl; } <<<<<<<< But the easiest thing is to consider if you really need the the > inhomogeneous constraints. I had the simple case where I wanted a > pressuredriven flow, and the pressure had to fulfill similar > inhomogeneous constraints. But this could easily be avoided by adding > a constant gradient in the NavierStokes equation. > What kind of system do you need the constraints for? I need them for elastostatics, so nodes on opposite sides of a unit cell moving such that the unit cell remains repeatable. > >2  Is there any way in which of two elements with the same error > estimate > > >only one will be refined? > > > > If you have a mesh on which 400 elements have error 2 and 600 have > > error 1, then AFAIK telling libMesh to refine the worst 30% of > > elements will cause a random 300 elements from the first group to be > > flagged for refinement. Normally this is barely noticeable: any > > elements "left behind" by one refinement step are likely to be the > > first elements in line for refinement on the next step. If you need > > two meshes to match exactly or one mesh to be perfectly symmetric, > > though, this will be a problem. > > > > >If this is not the case I would be able to ensure matching meshes by > > >modifying the error estimates, or should I modify the refinement > > >flags directly? > > > > Either way is good; I'm not sure which way would be quicker to code. > > To be safe make sure to modify the flags conservatively: only set new > > refinement flags and remove coarsening flags, never set coarsening or > > remove refinement. > > > > >3 Am I right to presume that in the case that no interpolated > constraints > > >are used the _dof_coupling can be used for x=3D=3D0? > > >I guess this could speed up the whole matter in cases with many > couplings. > > This is a serious problem. In most cases the _dof_coupling is already > built when you impose the constraints. Then, the Petsc solver will > have to enlarge its dofcoupling every time you fill the matrix at an > unexpected position. This makes the story damn slow. > Therefore, you will need to create the constraints _before_ the > dofcoupling is built. This is exactly what happens to the I take it you mean the dof_map, not the DofMap._dof_coupling. hangingnode constraints. I took me a long time to recognize this issue, and maybe there is > another solution, but I ended up by drilling a hole into the complete > library. I now have something like "attach_constrain_function" which work= s > similar as "attach_assemble_function" and which is called from inside > the library right after the hanging nodes have been built. Thanks for pointing this out, this seems a difficult one, but I think your solution would be the only way to have the desirable behaviour that: 1. The periodic or any new constraints override the hanging node couplings 2. They are taken into account when building the dof map Michael Schindler > >  > "A mathematician is a device for turning coffee into theorems" > Paul Erd=F6s. Greetings Wout Ruijter 
From: Manav Bhatia <manav@u.washington.edu>  20050928 17:15:06

Nonlinear heatconduction, cavity radiation, and thermoelastic problems in solid mechanics with modal and buckling eigenvalue analysis. Manav On Sep 27, 2005, at 8:29 PM, libmeshusers request@... wrote: > From: John Peterson <peterson@...> > Date: Tue, 27 Sep 2005 08:30:01 0500 > To: libmeshdevel@..., libmesh > users@... > Subject: [Libmeshusers] What do you use LibMesh for? > > > Hi, > > I believe this topic has been touched on before some time ago, > but I'm in the process of making a list of applications that > LibMesh is being used for. Please post to the list the any > applications/PDEs you have used LibMesh to solve, whether they > are class projects, formal research, or something in between. > > Thanks! > > > Let me get the list started: > .) Incompressible NavierStokes (natural convection) > .) Burgers' Equation (1D) > .) DoubleDiffusive Convection in Porous Media > .) Tumor Angiogenesis modeling > .) Linear AdvectionDiffusionReaction > .) e. Coli proliferation problems > > 
From: John Peterson <peterson@cf...>  20050928 14:03:35

Hi, Thanks to everyone who has responded, there were a great variety of answers. I believe this is simultaneously a strength and weakness of the library  we can tackle a large breadth of problems, but the depth of libmesh users does not extend beyond about 2 or 3 in any given area. Please feel free to respond if you haven't yet, and also send me any paper references you may have in which libmesh was used. I will cite them in the libmesh paper we are working on. J 
From: <antiga@ma...>  20050928 13:23:03

Hi, one more for the survey I'm using libmesh for 1) Unsteady incompressible NavierStokes 2) Magnetic Resonance simulation 3) Lagrangian particle tracking together with D.Steinman's group at Robarts Research Institute, London, Ontario. Luca On Tue, Sep 27, 2005 at 05:51:06PM +0100, Wout Ruijter wrote: > Hi there, > > I use libmesh for elastostatics, applied to the analysis of composite > materials. > > Greetings > Wout Ruijter  Luca Antiga, PhD  Biomedical Technologies Laboratory Bioengineering Department, Mario Negri Institute Villa Camozzi, 24020, Ranica (BG), Italy  phone: +39 035 4535381 email: antiga@... web: http://villacamozzi.marionegri.it/~luca  
From: Roy Stogner <roystgnr@ic...>  20050928 12:58:07

On Wed, 28 Sep 2005, Wout Ruijter wrote: > Sorry for being thick, but I don't understand how the penalty method you > suggested in an earlier mail would lead to a coupling of DOF (not a > constraint) without having to do a lookup of the corresponding dof on the > other side of the mesh and/or meddling with the sparsity structure. If it > does that, I would happily implement and use it. The penalty method would require a lookup of the corresponding element on the other side of the mesh, although not necessarily of every corresponding DoF. Such a lookup table would be fast to update after refinement, though  you'd just need to loop through the previous mesh's lookup table, delete any coarsened entries and check which children of refined elements correspond to which children of the parent's corresponding element.  Roy 
From: Michael Schindler <mschindler@us...>  20050928 11:38:01

Hello, although I am probably not the Michael that Wout refers to ;) I have also tried to implement the constraints for several purposes On 27.09.05, Roy Stogner wrote: > On Tue, 27 Sep 2005, Wout Ruijter wrote: > > >Three questions regarding periodic boundary conditions: > >1  Michael already showed how to implement periodic bc's of type > >u(l)=u(r), > >how do you add u(l)u(r)=x? Is that a matter of modifying the > >righthandside? > >I mean, is the rhs taken into account for constrained dof? Exactly. At the moment only homogeneous constraints are supported. If you really need inhomogeneous constraints you need two things: 1. A marker pseudoDOFnumber that collects the inhomoheneity in the ConstraintsRow 2. patch the source code of libmesh. The function that really does the constraint resolving. But the easiest thing is to consider if you really need the the inhomogeneous constraints. I had the simple case where I wanted a pressuredriven flow, and the pressure had to fulfill similar inhomogeneous constraints. But this could easily be avoided by adding a constant gradient in the NavierStokes equation. What kind of system do you need the constraints for? > >2  Is there any way in which of two elements with the same error estimate > >only one will be refined? > > If you have a mesh on which 400 elements have error 2 and 600 have > error 1, then AFAIK telling libMesh to refine the worst 30% of > elements will cause a random 300 elements from the first group to be > flagged for refinement. Normally this is barely noticeable: any > elements "left behind" by one refinement step are likely to be the > first elements in line for refinement on the next step. If you need > two meshes to match exactly or one mesh to be perfectly symmetric, > though, this will be a problem. > > >If this is not the case I would be able to ensure matching meshes by > >modifying the error estimates, or should I modify the refinement > >flags directly? > > Either way is good; I'm not sure which way would be quicker to code. > To be safe make sure to modify the flags conservatively: only set new > refinement flags and remove coarsening flags, never set coarsening or > remove refinement. > > >3 Am I right to presume that in the case that no interpolated constraints > >are used the _dof_coupling can be used for x==0? > >I guess this could speed up the whole matter in cases with many couplings. This is a serious problem. In most cases the _dof_coupling is already built when you impose the constraints. Then, the Petsc solver will have to enlarge its dofcoupling every time you fill the matrix at an unexpected position. This makes the story damn slow. Therefore, you will need to create the constraints _before_ the dofcoupling is built. This is exactly what happens to the hangingnode constraints. I took me a long time to recognize this issue, and maybe there is another solution, but I ended up by drilling a hole into the complete library. I now have something like "attach_constrain_function" which works similar as "attach_assemble_function" and which is called from inside the library right after the hanging nodes have been built. Michael Schindler  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Wout Ruijter <woutruijter@gm...>  20050928 11:16:54

Roy, Thanks for the comments On 9/27/05, Roy Stogner <roystgnr@...> wrote: > > On Tue, 27 Sep 2005, Wout Ruijter wrote: > > > Three questions regarding periodic boundary conditions: > > 1  Michael already showed how to implement periodic bc's of type > u(l)=3Du(r), > > how do you add u(l)u(r)=3Dx? Is that a matter of modifying the > righthandside? > > I mean, is the rhs taken into account for constrained dof? > > You'll have to do so explicitly. I don't recall whether Michael > finally ended up using a penalty method or building libMesh > constraints to do his boundary conditions, but only the former method > will work for your case. I don't think the DofConstraintRow objects > can include right hand side terms. I guess one could create loose nodes, or dofs, for that matter, which could be forced using a penalty method and which provide the constant that is needed. I see now that there has been a discussion on that before, I'll read some o= n it. > 2  Is there any way in which of two elements with the same error estimat= e > > only one will be refined? > > If you have a mesh on which 400 elements have error 2 and 600 have > error 1, then AFAIK telling libMesh to refine the worst 30% of > elements will cause a random 300 elements from the first group to be > flagged for refinement. Normally this is barely noticeable: any > elements "left behind" by one refinement step are likely to be the > first elements in line for refinement on the next step. If you need > two meshes to match exactly or one mesh to be perfectly symmetric, > though, this will be a problem. > > > If this is not the case I would be able to ensure matching meshes by > > modifying the error estimates, or should I modify the refinement > > flags directly? > > Either way is good; I'm not sure which way would be quicker to code. > To be safe make sure to modify the flags conservatively: only set new > refinement flags and remove coarsening flags, never set coarsening or > remove refinement. Of course. > 3 Am I right to presume that in the case that no interpolated constraint= s > > are used the _dof_coupling can be used for x=3D=3D0? > > I guess this could speed up the whole matter in cases with many > couplings. > > I don't think I understand this question. >  > Roy Stogner > Sorry, the last one is fairly vague, I mean, if a node is linked to 1 other node with u(l)=3Du(r), one could use the _dof_coupling instead of a constraint, whereas if it is linked to a couple of nodes (when it is a hanging node), or when u(l)u(r)=3Dx, x!=3D0,= one would need a constraint row to handle it. However, this may be fairly obsolete, because I don't think using _dof_coupling is a good idea, as it seems to allocate N^2 memory. Sorry for being thick, but I don't understand how the penalty method you suggested in an earlier mail would lead to a coupling of DOF (not a constraint) without having to do a lookup of the corresponding dof on the other side of the mesh and/or meddling with the sparsity structure. If it does that, I would happily implement and use it. Thanks a lot for your time, Wout 
From: Michael Povolotskyi <povolotskyi@in...>  20050928 09:05:45

Roy Stogner wrote: > On Tue, 27 Sep 2005, Wout Ruijter wrote: > >> Three questions regarding periodic boundary conditions: >> 1  Michael already showed how to implement periodic bc's of type >> u(l)=u(r), >> how do you add u(l)u(r)=x? Is that a matter of modifying the >> righthandside? >> I mean, is the rhs taken into account for constrained dof? > > > You'll have to do so explicitly. I don't recall whether Michael > finally ended up using a penalty method or building libMesh > constraints to do his boundary conditions, but only the former method > will work for your case. I don't think the DofConstraintRow objects > can include right hand side terms. > Yes, I implemented only libMesh constraints without the right hand side terms. Michael. 
From: Roy Stogner <roystgnr@ic...>  20050927 21:22:18

On Tue, 27 Sep 2005, Wout Ruijter wrote: > Three questions regarding periodic boundary conditions: > 1  Michael already showed how to implement periodic bc's of type u(l)=u(r), > how do you add u(l)u(r)=x? Is that a matter of modifying the righthandside? > I mean, is the rhs taken into account for constrained dof? You'll have to do so explicitly. I don't recall whether Michael finally ended up using a penalty method or building libMesh constraints to do his boundary conditions, but only the former method will work for your case. I don't think the DofConstraintRow objects can include right hand side terms. > 2  Is there any way in which of two elements with the same error estimate > only one will be refined? If you have a mesh on which 400 elements have error 2 and 600 have error 1, then AFAIK telling libMesh to refine the worst 30% of elements will cause a random 300 elements from the first group to be flagged for refinement. Normally this is barely noticeable: any elements "left behind" by one refinement step are likely to be the first elements in line for refinement on the next step. If you need two meshes to match exactly or one mesh to be perfectly symmetric, though, this will be a problem. > If this is not the case I would be able to ensure matching meshes by > modifying the error estimates, or should I modify the refinement > flags directly? Either way is good; I'm not sure which way would be quicker to code. To be safe make sure to modify the flags conservatively: only set new refinement flags and remove coarsening flags, never set coarsening or remove refinement. > 3 Am I right to presume that in the case that no interpolated constraints > are used the _dof_coupling can be used for x==0? > I guess this could speed up the whole matter in cases with many couplings. I don't think I understand this question.  Roy Stogner 
From: Min Xu <minxu@sc...>  20050927 21:01:49

Hi, there: There are two solver classes: PetscNonlinearSolver and PetscLinearSolver in libmesh. What is the difference between the two classes? In my case, the Jacobian is only specified in a form of its product of a given vector. So a matrixfree NewtonKrylov method is required. Which solver should I use? Best regards, Min Xu 
From: Wout Ruijter <woutruijter@gm...>  20050927 20:06:00

Dear sirs, Three questions regarding periodic boundary conditions: 1  Michael already showed how to implement periodic bc's of type u(l)=3Du(= r), how do you add u(l)u(r)=3Dx? Is that a matter of modifying the righthandsi= de? I mean, is the rhs taken into account for constrained dof? 2  Is there any way in which of two elements with the same error estimate only one will be refined? If this is not the case I would be able to ensure matching meshes by modifying the error estimates, or should I modify the refinement flags directly? 3 Am I right to presume that in the case that no interpolated constraints are used the _dof_coupling can be used for x=3D=3D0? I guess this could speed up the whole matter in cases with many couplings. Thanks in advance for your opinion Wout 
From: Wout Ruijter <woutruijter@gm...>  20050927 16:51:34

Hi there, I use libmesh for elastostatics, applied to the analysis of composite materials. Greetings Wout Ruijter 
From: Steffen Petersen <steffen.petersen@tu...>  20050927 16:11:59

.) Helmholtz equation and wave equation for interior and exterior domains .) Eigenvalue/Modal analysis Steffen > Urspr=FCngliche Nachricht > Von: libmeshusersadmin@...=20 > [mailto:libmeshusersadmin@...] Im Auftrag=20 > von John Peterson > Gesendet: Dienstag, 27. September 2005 15:30 > An: libmeshdevel@...;=20 > libmeshusers@... > Betreff: [Libmeshusers] What do you use LibMesh for? >=20 >=20 >=20 > Hi, >=20 > I believe this topic has been touched on before some time ago, > but I'm in the process of making a list of applications that > LibMesh is being used for. Please post to the list the any > applications/PDEs you have used LibMesh to solve, whether they > are class projects, formal research, or something in between. >=20 > Thanks! >=20 >=20 > Let me get the list started: > .) Incompressible NavierStokes (natural convection) > .) Burgers' Equation (1D) > .) DoubleDiffusive Convection in Porous Media > .) Tumor Angiogenesis modeling > .) Linear AdvectionDiffusionReaction > .) e. Coli proliferation problems > =20 >=20 >=20 >  > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App=20 > Server. Download > it for free  and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers >=20 
From: Min Xu <minxu@sc...>  20050927 14:58:16

I am currently using libmesh to develop a code for optical imaging based on the diffusion model in 2D/3D. Min Xu On Tuesday 27 September 2005 09:30, John Peterson wrote: > Hi, > > I believe this topic has been touched on before some time ago, > but I'm in the process of making a list of applications that > LibMesh is being used for. Please post to the list the any > applications/PDEs you have used LibMesh to solve, whether they > are class projects, formal research, or something in between. > > Thanks! > > > Let me get the list started: > .) Incompressible NavierStokes (natural convection) > .) Burgers' Equation (1D) > .) DoubleDiffusive Convection in Porous Media > .) Tumor Angiogenesis modeling > .) Linear AdvectionDiffusionReaction > .) e. Coli proliferation problems > > > >  > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download it for free  and be entered to win a 42" plasma tv or your very > own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roy Stogner <roystgnr@ic...>  20050927 14:42:15

Oh, "please post to the list" you said... ;)  Roy  Forwarded message  Date: Tue, 27 Sep 2005 08:38:10 0500 (CDT) From: Roy Stogner <roystgnr@...> To: John Peterson <peterson@...> Subject: Re: [Libmeshusers] What do you use LibMesh for? On Tue, 27 Sep 2005, John Peterson wrote: > Let me get the list started: > .) Incompressible NavierStokes (natural convection) > .) Burgers' Equation (1D) > .) DoubleDiffusive Convection in Porous Media > .) Tumor Angiogenesis modeling > .) Linear AdvectionDiffusionReaction > .) e. Coli proliferation problems Shearthinning incompressible flow and transport Plate bending  Roy Stogner 
From: Michael Schindler <mschindler@us...>  20050927 14:36:11

> Hi, > > I believe this topic has been touched on before some time ago, > but I'm in the process of making a list of applications that > LibMesh is being used for. Please post to the list the any > applications/PDEs you have used LibMesh to solve, whether they > are class projects, formal research, or something in between. > > Thanks! .) incompressible Stokes equation with free capillary boundaries  research Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20050927 14:17:38

.) Compressible NavierStokes (aerodynamics/aerothermodynamics)  research .) e. Coli models  research .) porous media flows  research .) boundary layer solutions in a twolayer methodology  production code Original Message From: libmeshusersadmin@... [mailto:libmeshusersadmin@...] On Behalf Of John Peterson Sent: Tuesday, September 27, 2005 8:30 AM To: libmeshdevel@...; libmeshusers@... Subject: [Libmeshusers] What do you use LibMesh for? Hi, I believe this topic has been touched on before some time ago, but I'm in the process of making a list of applications that LibMesh is being used for. Please post to the list the any applications/PDEs you have used LibMesh to solve, whether they are class projects, formal research, or something in between. Thanks! Let me get the list started: .) Incompressible NavierStokes (natural convection) .) Burgers' Equation (1D) .) DoubleDiffusive Convection in Porous Media .) Tumor Angiogenesis modeling .) Linear AdvectionDiffusionReaction .) e. Coli proliferation problems  SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free  and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Libmeshusers mailing list Libmeshusers@... https://lists.sourceforge.net/lists/listinfo/libmeshusers 