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}
(69) 
_{Sep}
(26) 
_{Oct}
(43) 
_{Nov}
(62) 
_{Dec}

S  M  T  W  T  F  S 





1

2

3

4

5
(2) 
6
(1) 
7
(9) 
8
(2) 
9

10

11

12
(15) 
13
(18) 
14
(11) 
15
(5) 
16
(10) 
17

18

19
(3) 
20
(9) 
21
(7) 
22
(5) 
23

24

25

26

27
(3) 
28
(4) 
29
(4) 
30
(1) 
31

From: Mladen Jurak <jurak@ma...>  20090122 19:07:34

Roy Stogner wrote: > > Would it suffice to have an elem_rate_solution available, which > contained (u_nu_p)/deltat on each variable? I might be adding that > for one of my own applications and to make it simpler to write user > code with nonlinear mass matrices again. >  > Roy > > It would be nice to have "(u_nu_p)/deltat" or "u_p". I would prefer some "elem_old_solution" in DifferentiableSystem class. Mladen 
From: Roy Stogner <roystgnr@ic...>  20090122 19:00:20

On Thu, 22 Jan 2009, Mladen Jurak wrote: > The problem is on the boundary where I need to calculate total > flow in order to complete saturation equation. This boundary flow > can be calculated only by using local mass conservation and in > that way I introduce time derivative into spatial > discretization. My need for old solution comes from this time > derivative, but, perhaps, I could shift these boundary terms > containing (p^new p^old)/dt to mass residual part of the > residual. Would it suffice to have an elem_rate_solution available, which contained (u_nu_p)/deltat on each variable? I might be adding that for one of my own applications and to make it simpler to write user code with nonlinear mass matrices again.  Roy 
From: Mladen Jurak <jurak@ma...>  20090122 18:40:17

Roy Stogner wrote: > Mladen Jurak wrote: > >> I wander about the use of "elem_fixed_solution" in >> "EulerSolver::element_residual" method. Fixed solution is >> set to "theta_solution" and therefore during the call to >> "_system.element_time_derivative" both "elem_fixed_solution" >> and "elem_solution" have the same data. > > Right. > >> It happens to me >> that in "element_time_derivative" I need the solution from the >> preceding time level ("old_elem_solution" in >> "EulerSolver::element_residual"). > > May I ask why? > My use of the library is not standard. I solve compressible twophase flow equations by vertexcentered finite volume method, by using some additional classes (made by David Trujillo from University of Pau). The system in fractional flow formulation is composed of pressure equation which gives the total flow, and saturation equation (of convectiondiffusion type) in which the total flow is used. The problem is on the boundary where I need to calculate total flow in order to complete saturation equation. This boundary flow can be calculated only by using local mass conservation and in that way I introduce time derivative into spatial discretization. My need for old solution comes from this time derivative, but, perhaps, I could shift these boundary terms containing (p^new p^old)/dt to mass residual part of the residual. Sorry for this confusing explanation. >> My question is couldn't "elem_fixed_solution" be set to >> "old_elem_solution" in "EulerSolver::element_residual". Then one >> would have more information while assembling the system. >> I don't see any obstacle, but in the other hand I am not sure that >> I understand well the concept of fixed solution. > > Suppose you've got a system like: > > d(M(u))/dt = F(u) > > A theta method solve, from previous timestep u_p to next timestep u_n > via theta interpolant u_t, might look like: > > (M(u_n)  M(u_p))/deltat = F(u_t) > > And when discretizing in space by taking only the weighted products > against test functions: > > (M(u_n,v)  M(u_p,v))/deltat = F(u_t,v) > > So for most people, all F() needs to evaluate is the derivative at > u_t, not u_p or u_n. > > The reason for adding elem_fixed_solution was, when we wanted to do > some stabilized formulations, we had v = v_c + w(u_f)  the test > function was now a function v(u) of the solution. But that u had to > be fixed  evaluating M(u_n,v(u_n))  M(u_p,v(u_p)) is inconsistent. > To avoid losing secondorder accuracy in CrankNicholson, the obvious > choice for EulerSolver was v(u_f) where u_f = u_t. > > But while that's the right thing to do for EulerSolver, it sounds like > it's incompatible with what you want  hence my "why?" question. The > right thing to do may be to modify a cloned EulerSolver (like I did > with Euler2Solver when I wanted trapezoidal time integration), but > it's impossible to be sure without knowing what you plan to use the > old solution for. >  > Roy > > 
From: Roy Stogner <roystgnr@ic...>  20090122 18:03:07

Mladen Jurak wrote: > I wander about the use of "elem_fixed_solution" in > "EulerSolver::element_residual" method. Fixed solution is > set to "theta_solution" and therefore during the call to > "_system.element_time_derivative" both "elem_fixed_solution" > and "elem_solution" have the same data. Right. > It happens to me > that in "element_time_derivative" I need the solution from the > preceding time level ("old_elem_solution" in > "EulerSolver::element_residual"). May I ask why? > My question is couldn't "elem_fixed_solution" be set to > "old_elem_solution" in "EulerSolver::element_residual". Then one > would have more information while assembling the system. > I don't see any obstacle, but in the other hand I am not sure that > I understand well the concept of fixed solution. Suppose you've got a system like: d(M(u))/dt = F(u) A theta method solve, from previous timestep u_p to next timestep u_n via theta interpolant u_t, might look like: (M(u_n)  M(u_p))/deltat = F(u_t) And when discretizing in space by taking only the weighted products against test functions: (M(u_n,v)  M(u_p,v))/deltat = F(u_t,v) So for most people, all F() needs to evaluate is the derivative at u_t, not u_p or u_n. The reason for adding elem_fixed_solution was, when we wanted to do some stabilized formulations, we had v = v_c + w(u_f)  the test function was now a function v(u) of the solution. But that u had to be fixed  evaluating M(u_n,v(u_n))  M(u_p,v(u_p)) is inconsistent. To avoid losing secondorder accuracy in CrankNicholson, the obvious choice for EulerSolver was v(u_f) where u_f = u_t. But while that's the right thing to do for EulerSolver, it sounds like it's incompatible with what you want  hence my "why?" question. The right thing to do may be to modify a cloned EulerSolver (like I did with Euler2Solver when I wanted trapezoidal time integration), but it's impossible to be sure without knowing what you plan to use the old solution for.  Roy 
From: Mladen Jurak <jurak@ma...>  20090122 17:48:20

Hi, I wander about the use of "elem_fixed_solution" in "EulerSolver::element_residual" method. Fixed solution is set to "theta_solution" and therefore during the call to "_system.element_time_derivative" both "elem_fixed_solution" and "elem_solution" have the same data. It happens to me that in "element_time_derivative" I need the solution from the preceding time level ("old_elem_solution" in "EulerSolver::element_residual"). My question is couldn't "elem_fixed_solution" be set to "old_elem_solution" in "EulerSolver::element_residual". Then one would have more information while assembling the system. I don't see any obstacle, but in the other hand I am not sure that I understand well the concept of fixed solution. Thanks, Mladen 