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}
(41) 
_{May}
(73) 
_{Jun}
(32) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2

3

4

5

6
(5) 
7

8

9
(2) 
10

11

12

13
(1) 
14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31


From: Mark Blome <mblome@au...>  20041213 12:49:24

Hi everybody, I have a short question about the mesh.data class. For the system I want to solve I need to know the gradients of the material property (conductivity) which I stored in the mesh.data object (associated to each node). Does libmesh provide an easy way for doing this ? Thanks for any hint, Mark 
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20041209 18:46:24

The constraint matrix is typically used to enforce continuity constraints in the case of AMR, but the idea is general and can be employed for other uses... The idea is as follows: express local (element) degrees of freedom, u_e, as some linear combination of other degrees of freedom (which may or may not be local) u_o: u_e = C u_o where C is the constraint matrix. When an element matrix and vector are built, this is typically done in terms of local DOFs. If these DOFs are constrained then the local matrix/vector must be modified: K_e u_e = f_e becomes C^T K_e u_e = C^T f_e C^T K_e C u_o = C^T f_e The C u_o term above replaces the local degrees of freedom u_e with their constrained values, effectively constraining your trial space. The C^T imposes the same constraints on your test space. (see "Computational Grids" by Graham Carey, published by Taylor & Francis for more details To be more specific: oo c o         oo b          oo a o For the "hanging node" b, the constraint (assuming linear basis functions) is u_b = 0.5*(u_a + u_c) It is precisely this scenario that the constraint matrix addresses The approach used in libMesh is to handle "recursive constraints" (consider u_e = C1 u_o1, u_o1 = C2 u_o2). So, from the library's perspective, it is perfectly acceptable to constrain degrees of freedom in terms of other degrees of freedom which are themselves constrained... There are other approaches that may be used to enforce continuity (lagrange multipliers, penalty) but I like this one. Hope this helps... Ben Original Message From: libmeshusersadmin@... [mailto:libmeshusersadmin@...] On Behalf Of Manav Bhatia Sent: Thursday, December 09, 2004 11:09 AM To: libmeshusers@... Subject: [Libmeshusers] Constraint matrix Hi, Could anyone please tell me about the basic idea behind the purpose of constraint matrix and how it works? Thanks in advance, Manav 
From: Manav Bhatia <manav@u.washington.edu>  20041209 17:04:29

Hi, Could anyone please tell me about the basic idea behind the purpose of constraint matrix and how it works? Thanks in advance, Manav 
From: Roy Stogner <roystgnr@ic...>  20041206 21:08:46

On Mon, 6 Dec 2004, KIRK, BENJAMIN (JSCEG) (NASA) wrote: > With the analogy to a point load, I believe what you want to do is simply > add the relevant contribution to the system "load" vector after assembly. This is a good shortcut if you're using a finite element which has a unitvalued basis function and a bunch of zerovalued basis functions at the node. Although this may be true for all the useful finite element types (the monomial basis is the only exception I know of) in libMesh right now, it's not guaranteed to be true for any element  the C1continuous elements I'm adding don't have degrees of freedom corresponding to midedge node values, for example. In the most general case you need to get the values for all test functions supported at your point load, and add the weighted contribution for each of the nonzero ones.  Roy Stogner 
From: KIRK, BENJAMIN (JSCEG) (NASA) <benjamin.kirk1@na...>  20041206 20:45:50

With the analogy to a point load, I believe what you want to do is simply add the relevant contribution to the system "load" vector after assembly. You can get the global dof number like this: const unsigned int dn = node>dof_number (sys_number, var_number, component_number); Then add the relevant value to the load vector: system.rhs>add(dn, value); Note that in general you will only want to do this on one processor, so the above becomes: if (libMesh::processor_id() == 0) system.rhs>add(dn, value); You can do this at the end of the assembly routine after the loop over the elements. Ben 
From: Roy Stogner <roystgnr@ic...>  20041206 18:46:57

On Mon, 6 Dec 2004, John Peterson wrote: > Mark Blome writes: > > > > I am currently developing a finite element geoelectric forward > > solver and I am very pleased with the possibilities libmesh gives > > me for doing this. For the equation system assembly function I > > ran across a problem for which I cannot really find a solution. > > For the geolelectric problem I have to introduce a source term > > associated to a node on the surface of the input mesh (for the > > current electrode). The node is correctly marked with a boundary > > marker and I can read it in without a problem (its a tetgen mesh). > > However I cannot find a way to set the source term in the right > > hand side correctly because I can not find out which one of the > > quadrature points is the one that corresponds to the node that I > > marked in the mesh. Am I right that it is not even guaranteed that > > one of the quadrature points will lie on the node where my > > electrode is attached to? Would that mean that I have to > > interpolate the source term from the node position to the nearest > > quadrature point to get the correct right hand side value? Is > > there a way to force one of the quadrature points to be on the > > node? Or are my thoughts just going in the wrong direction ? > > Thanks for any help on this, > You are correct that the Gaussian quadrature points do not lie on the > nodes. There are the trapezoidal and Simpson quadrature rules whose points > however do lie at the nodes. If the value of the source term is availabe > at every node, you can use the finite element basis functions to interpolate > a value at the quadrature point. I assume that it makes sense for your > problem for the source term at a given point to be a weighted average of > nearby points... It sounds as if this source term is a Dirac delta functional, not an integrable function. If that's the case, then unless the functional happens to fall on a quadrature point it can't be exactly evaluated in the quadrature loop at all. I'm assuming the term to be integrated looks like the integral of k * delta(p) * v_i, and assuming you're using continuous elements. If the point load is on the interior of an element, you can simply use the FE<Dim,T>::shape() function to get the value of test function v_i at the point load location p, and multiply this by the load magnitude k. If the point load is on the edge of an element but on the interior of the domain, then you'll also need to make sure you only add the load on one element, not once for each adjoining element. If the point load is on the boundary of your domain, then the right thing to do depends on your problem physics and on how the load is defined. In the worst case you may need to figure out what fraction of the angle (out of 2 pi radians or 4 pi steradians) at that boundary point is inside your domain, and only add that fraction of the load magnitude.  Roy Stogner 
From: John Peterson <peterson@cf...>  20041206 15:57:35

Mark Blome writes: > > Hi everybody, > > I am currently developing a finite element geoelectric forward solver and I > am very pleased with the possibilities libmesh gives me for doing this. > For the equation system assembly function I ran across a problem for which I > cannot really find a solution. For the geolelectric problem I have to > introduce a source term associated to a node on the surface of the input mesh > (for the current electrode). The node is correctly marked with a boundary > marker and I can read it in without a problem (its a tetgen mesh). However I > cannot find a way to set the source term in the right hand side correctly > because I can not find out which one of the quadrature points is the one that > corresponds to the node that I marked in the mesh. Am I right that it is not > even guaranteed that one of the quadrature points will lie on the node where > my electrode is attached to? Would that mean that I have to interpolate the > source term from the node position to the nearest quadrature point to get the > correct right hand side value? Is there a way to force one of the quadrature > points to be on the node? Or are my thoughts just going in the wrong > direction ? Thanks for any help on this, Hi, You are correct that the Gaussian quadrature points do not lie on the nodes. There are the trapezoidal and Simpson quadrature rules whose points however do lie at the nodes. If the value of the source term is availabe at every node, you can use the finite element basis functions to interpolate a value at the quadrature point. I assume that it makes sense for your problem for the source term at a given point to be a weighted average of nearby points... John 
From: Mark Blome <mblome@au...>  20041206 14:55:15

Hi everybody, I am currently developing a finite element geoelectric forward solver and I am very pleased with the possibilities libmesh gives me for doing this. For the equation system assembly function I ran across a problem for which I cannot really find a solution. For the geolelectric problem I have to introduce a source term associated to a node on the surface of the input mesh (for the current electrode). The node is correctly marked with a boundary marker and I can read it in without a problem (its a tetgen mesh). However I cannot find a way to set the source term in the right hand side correctly because I can not find out which one of the quadrature points is the one that corresponds to the node that I marked in the mesh. Am I right that it is not even guaranteed that one of the quadrature points will lie on the node where my electrode is attached to? Would that mean that I have to interpolate the source term from the node position to the nearest quadrature point to get the correct right hand side value? Is there a way to force one of the quadrature points to be on the node? Or are my thoughts just going in the wrong direction ? Thanks for any help on this, Mark 