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

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2
(5) 
3

4

5

6
(5) 
7

8

9
(8) 
10
(9) 
11
(2) 
12
(3) 
13

14

15

16
(11) 
17
(2) 
18
(1) 
19
(11) 
20

21

22

23
(3) 
24

25
(1) 
26
(4) 
27
(5) 
28

29

30

31





From: Andrea HawkinsDaarud <andjhawkins@gm...>  20100812 22:01:39

Thank you for your response! > Depends on what you mean by "okay". If you integrate against a fine > grid solution that's more refined on an element (as we generally do) > then the main issue is quadrature error. Likewise if the grids aren't > nested. If you integrate against a solution where the "fine grid" > uses the same or a coarser element then there won't be any quadrature > error... normally in that case there also won't be a decent error > estimate, but it looks like you're doing something > different/interesting with your first equation. I see... There is a flag for computing error on parent... What exactly does that do? Something that could work for this particular situation would be to compute this difference for the elements of the parent mesh only. i.e. for each parent element loop over all the active child elements, sum those int_{child_elem}u^2 values to get the int_{parent_elem}u^2 value, and then compute the difference sqrt(int_{parent_elem}u^2)  sqrt(int_{parent_elem}(u')^2). It doesn't seem like that is what the flag is telling it to do, or is it? > The trouble is that afterward the sqrt call would still be applied to > a single integrated result... I guess you could call the > ExactErrorEstimator twice: once passing in an "exact solution" of 0 to > get the u^2 integral and a second time passing in an approximate > solution of 0 and an exact solution of the fine grid u' to get the > u'^2 integral. But I'm afraid it would probably be more efficient to > subclass ErrorEstimator, and just cutandpaste code as applicable > from ExactErrorEstimator. This did work, the square root wasn't a problem, just comment it out of the estimate_error routine and take care of it in the find_squared_elem_error routine. Thanks! Andrea 
From: Roy Stogner <roystgnr@ic...>  20100812 20:33:31

On Thu, 12 Aug 2010, Andrea HawkinsDaarud wrote: > So, we would like to calculate, if u is the solution being used as > the data and u' is the solution generated through a sample point, > > sqrt(int_{elem}u^2)  sqrt(\int_{elem}(u')^2). > > This would not be a problem at all if they were on the same mesh. > However, the computational expense of such a calculation is a really > big issue, and so I'm using the PatchRecoveryErrorEstimator for > refinement. Thus, there is absolutely no reason to suspect they would > be the same mesh. I had tried using ExactErrorEstimator (as I > mentioned in my last email to the list serve), but I see that that is > calculating > > sqrt(int_{elem}(uu')^2). > So, a couple of questions: > > I've just realized that in the estimate_errors routine it is assumed > that the two meshes have the same parent mesh... Is there a problem if > one is not necessarily a refined version of the other? i.e. is it ok > if they are each refined in locations where the other isn't? Depends on what you mean by "okay". If you integrate against a fine grid solution that's more refined on an element (as we generally do) then the main issue is quadrature error. Likewise if the grids aren't nested. If you integrate against a solution where the "fine grid" uses the same or a coarser element then there won't be any quadrature error... normally in that case there also won't be a decent error estimate, but it looks like you're doing something different/interesting with your first equation. > Assuming it isn't a problem, I'm really needing the first norm I've > listed. After looking through the code, I'm kind of talking myself > into the idea that maybe I just need to create a child class of > ExactErrorEstimator that has its own estimate_error routine which is > exactly the same except instead of calling find_squared_element_error > called something else which was exactly the same as > find_squared_element_error but use the difference I need instead. The trouble is that afterward the sqrt call would still be applied to a single integrated result... I guess you could call the ExactErrorEstimator twice: once passing in an "exact solution" of 0 to get the u^2 integral and a second time passing in an approximate solution of 0 and an exact solution of the fine grid u' to get the u'^2 integral. But I'm afraid it would probably be more efficient to subclass ErrorEstimator, and just cutandpaste code as applicable from ExactErrorEstimator.  Roy 
From: Andrea HawkinsDaarud <andjhawkins@gm...>  20100812 19:47:11

Hello I'm once again in need of guidance. As a bit of background, I'm working on a project similar in general idea to what PECOS is doing with Bayesian Calibration/Validation etc, but as applied to modeling tumor growth. We are currently just trying to show proof of concept using virtual experiments as data, i.e. use a model with a certain set of parameters and use the resulting solution as calibration and/or validation data. Keeping in mind that a real set of data would probably be something like an MRI pixelated image, for the data misfit we would like to consider as data the values per "pixel" or in this case per element. So, we would like to calculate, if u is the solution being used as the data and u' is the solution generated through a sample point, sqrt(int_{elem}u^2)  sqrt(\int_{elem}(u')^2). This would not be a problem at all if they were on the same mesh. However, the computational expense of such a calculation is a really big issue, and so I'm using the PatchRecoveryErrorEstimator for refinement. Thus, there is absolutely no reason to suspect they would be the same mesh. I had tried using ExactErrorEstimator (as I mentioned in my last email to the list serve), but I see that that is calculating sqrt(int_{elem}(uu')^2). So, a couple of questions: I've just realized that in the estimate_errors routine it is assumed that the two meshes have the same parent mesh... Is there a problem if one is not necessarily a refined version of the other? i.e. is it ok if they are each refined in locations where the other isn't? Assuming it isn't a problem, I'm really needing the first norm I've listed. After looking through the code, I'm kind of talking myself into the idea that maybe I just need to create a child class of ExactErrorEstimator that has its own estimate_error routine which is exactly the same except instead of calling find_squared_element_error called something else which was exactly the same as find_squared_element_error but use the difference I need instead. Would there be a better way to do it? Or would this not work at all? Thank you! Andrea 