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}
(30) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{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: 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 