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}
(51) 
_{Jul}
(12) 
_{Aug}
(46) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(4) 
2
(1) 
3

4
(2) 
5
(1) 
6
(1) 
7

8
(2) 
9

10

11

12

13
(6) 
14
(8) 
15
(1) 
16
(1) 
17
(2) 
18
(2) 
19
(2) 
20
(5) 
21
(15) 
22

23
(1) 
24

25
(5) 
26
(7) 
27
(7) 
28
(3) 
29
(18) 

From: Benjamin Kirk <benjamin.kirk@na...>  20080225 21:36:37

> I am curious as to what kind of multiphysics problems you have solved > with Libmesh before and what kind of approach you took for those. I > gather you used a single mesh for both the physics but where you able > to preserve the accuracy of the coupled solution in space and time ? > And did you use Operatorsplitting with iterations over the coupled > physics ? Actually most recently I have been working the conjugate heat transfer problem. The "external" application is hypersonic flight and the "internal" application is solidbody conduction. This uses two meshes, one for the fluid flow and one for the heat transfer. An operatorsplit approach is natural in this problem because of the disparate time scales. The external flow characteristic times are ~microseconds while the heat transfer problem is ~seconds. The approach couples the problem at the boundary. The temperature is interpolated from the heat transfer part to provide an isothermal boundary condition for the flow. The heat transfer is then interpolated from the fluid part and transformed into a heat transfer coefficient boundary condition for the heat transfer problem. It works well because the heat transfer coefficient is approximately constant for a small range in wall temperature, so the time coupling here is especially loose. Ben 
From: Roy Stogner <roystgnr@ic...>  20080225 19:19:06

On Mon, 25 Feb 2008, Yujie wrote: > Thank you for your reply. In fact, the basic problem is how to know the > relationship between the solution variables (one or several) and > the nonsolution variables(one or > several). If one uses two Systems for them, one for solution > variables, the other for nonsolution variables. Only one mesh is for > them. Assuming firstorder Lagrange shape function is used, how to > establish the relationship using the nodes on the mesh > or other information? For example, there are three solution variables (u, v, > p) on node 1 of the mesh in System 1, there > are two nonsolution variables (x, y) on node 1 of the mesh in System 2, > how to know they are relevant to node 1? That's what the DofMap class is for; give an Elem object (and possibly a variable number) to DofMap::dof_indices() and it will fill a vector with the global DoF index numbers for that variable(s) on that element. Alternatively, if you only want to use Lagrange shape functions, you can use the DofObject class methods to directly find the indices on a Node.  Roy 
From: Yujie <recrusader@gm...>  20080225 19:12:21

Dear Roy: Thank you for your reply. In fact, the basic problem is how to know the relationship between the solution variables (one or several) and the nonsolution variables(one or several). If one uses two Systems for them, one for solution variables, the other for nonsolution variables. Only one mesh is for them. Assuming firstorder Lagrange shape function is used, how to establish the relationship using the nodes on the mesh or other information? For example, there are three solution variables (u, v, p) on node 1 of the mesh in System 1, there are two nonsolution variables (x, y) on node 1 of the mesh in System 2, how to know they are relevant to node 1? thanks a lot. Regards, Yujie On 2/25/08, Roy Stogner <roystgnr@...> wrote: > > > On Mon, 25 Feb 2008, Yujie wrote: > > > Could you give me some hints to the email I have sent last week? > > > Yeah; sorry I let it get buried but it's been a busy week. > > > > In addition, even if you use another System, how to guarantee the > > Dof in one System is the same with that of the other, especially > > numbering? > > > If you use the same finite element spaces you should get the same > numbering, but don't count on that. Use the DoFMap in each system to > get the indexing of each variable, and then they don't have to be the > same. > > > > If there are several solution variables in the System, the > > nonsolution variable is only relevant to the nodes on the mesh, what > > is there are different Dofs between them, how to deal with it? > > > See ex13; there are multiple variables there, and to get their values > you can use the DofMap to get the local indices, use an appropriate FE > objct to get the shape functions, then do the sums at each quadrature > point. If the variables are in separate systems, all that changes is > that you have to use the DofMap in each system to get its own > variables. > > > > You agree that the best method is to add another system to the > > EquationSystems. You also consider that it is ok to use add_vector() > > to add a vector for the nonsolution variable. My problem is how to > > distribute the vector you add corresponding to DoF distribution on > > processors of the cluster when you add the vector? > > > Assuming both Systems are in the same EquationSystems object, they'll > be using the same Mesh with the same partitioning. The library will > handle parallel redistribution for you. > > > > Any functions in libmesh help keep this vector, such as initializing > > the distribution of this vector, updating this vector along with the > > change of Dof after refining mesh, and so on? thanks a lot. > > > EquationSystems::init() should handle the original distribution of the > vector, and EquationSystems::reinit() should do everything you need > after a mesh refinement. >  > > Roy > 
From: Roy Stogner <roystgnr@ic...>  20080225 18:44:37

On Mon, 25 Feb 2008, Yujie wrote: > Could you give me some hints to the email I have sent last week? Yeah; sorry I let it get buried but it's been a busy week. > In addition, even if you use another System, how to guarantee the > Dof in one System is the same with that of the other, especially > numbering? If you use the same finite element spaces you should get the same numbering, but don't count on that. Use the DoFMap in each system to get the indexing of each variable, and then they don't have to be the same. > If there are several solution variables in the System, the > nonsolution variable is only relevant to the nodes on the mesh, what > is there are different Dofs between them, how to deal with it? See ex13; there are multiple variables there, and to get their values you can use the DofMap to get the local indices, use an appropriate FE objct to get the shape functions, then do the sums at each quadrature point. If the variables are in separate systems, all that changes is that you have to use the DofMap in each system to get its own variables. > You agree that the best method is to add another system to the > EquationSystems. You also consider that it is ok to use add_vector() > to add a vector for the nonsolution variable. My problem is how to > distribute the vector you add corresponding to DoF distribution on > processors of the cluster when you add the vector? Assuming both Systems are in the same EquationSystems object, they'll be using the same Mesh with the same partitioning. The library will handle parallel redistribution for you. > Any functions in libmesh help keep this vector, such as initializing > the distribution of this vector, updating this vector along with the > change of Dof after refining mesh, and so on? thanks a lot. EquationSystems::init() should handle the original distribution of the vector, and EquationSystems::reinit() should do everything you need after a mesh refinement.  Roy 
From: Essau Magos <naumanen1994@STARLITE.DK>  20080225 15:18:02

She will start screaming in pleasure from now on! 