Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Close
From: Roy Stogner <roystgnr@ic...>  20121011 16:45:35

Vikram and I are waffling on this question, so I thought I'd throw it out for everybody's feedback: For signed error estimates, e.g. estimates of QuantityofInterest error where Q  Q_h ~= sum_E ( \eta_E ), what should the estimate_error() method put in our ErrorVector? The signed eta_E, or the unsigned abs(eta_E)? On the one hand: if error vectors can contain signed values, then every MeshRefinement heuristic is going to have to be modified to do abs() calls itself, 99% of the time this is going to be a complete waste, and (given that the ErrorEstimator subclass also calculates a global "Q  Q_h" estimate that can be accessed without that summation) it's hard to come up with usage cases for the signed local values. On the other hand: since abs() doesn't require any more cache misses or use any more memory bandwidth, doing it redundantly in MeshRefinement local variables may not actually waste time on modern processors. And if someone ever *does* want to use signed local values for something (cancellationaware refinement heuristics??) then it would be good if we didn't destroy that sign information before giving local values to them. Opinions, or factors I've missed?  Roy 
From: Paul T. Bauman <ptbauman@gm...>  20121011 16:49:20

Off the top of my head, the only the I can see is it would be nice to be able to sum the error vector to get the total error estimate. But maybe there's other things already there to do that? On Thu, Oct 11, 2012 at 11:45 AM, Roy Stogner <roystgnr@...>wrote: > > Vikram and I are waffling on this question, so I thought I'd throw it > out for everybody's feedback: > > For signed error estimates, e.g. estimates of QuantityofInterest > error where Q  Q_h ~= sum_E ( \eta_E ), what should the > estimate_error() method put in our ErrorVector? The signed eta_E, > or the unsigned abs(eta_E)? > > On the one hand: if error vectors can contain signed values, then > every MeshRefinement heuristic is going to have to be modified to do > abs() calls itself, 99% of the time this is going to be a complete > waste, and (given that the ErrorEstimator subclass also calculates a > global "Q  Q_h" estimate that can be accessed without that > summation) it's hard to come up with usage cases for the signed local > values. > > On the other hand: since abs() doesn't require any more cache misses > or use any more memory bandwidth, doing it redundantly in > MeshRefinement local variables may not actually waste time on modern > processors. And if someone ever *does* want to use signed local > values for something (cancellationaware refinement heuristics??) then > it would be good if we didn't destroy that sign information before > giving local values to them. > > Opinions, or factors I've missed? >  > Roy > > >  > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelicdev2dev > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers > 
From: Roy Stogner <roystgnr@ic...>  20121011 16:53:41

On Thu, 11 Oct 2012, Paul T. Bauman wrote: > Off the top of my head, the only the I can see is it would be nice to be able to sum the error vector to get the total error estimate. But maybe > there's other things already there to do that? Yes  because the first AdjointRefinementErrorEstimator code path *doesn't* actually support that sum equation, and because that code path won't ever be completely deprecated (getting a proper partition will require that nodesplitting trick for nonFEMSystem users and so will be slightly more expensive), the estimator has a method for grabbing the true global estimate independent of the local values.  Roy 
From: John Peterson <peterson@cf...>  20121011 17:02:00

On Thu, Oct 11, 2012 at 10:45 AM, Roy Stogner <roystgnr@...> wrote: > > Vikram and I are waffling on this question, so I thought I'd throw it > out for everybody's feedback: > > For signed error estimates, e.g. estimates of QuantityofInterest > error where Q  Q_h ~= sum_E ( \eta_E ), what should the > estimate_error() method put in our ErrorVector? The signed eta_E, > or the unsigned abs(eta_E)? If you decide to allow signed values in ErrorVector, be sure to also fix ErrorVector::minimum() which currently assumes only positive values are in the vector.  John 
From: Roy Stogner <roystgnr@ic...>  20121022 06:38:57

On Thu, 11 Oct 2012, John Peterson wrote: > On Thu, Oct 11, 2012 at 10:45 AM, Roy Stogner <roystgnr@...> wrote: >> >> Vikram and I are waffling on this question, so I thought I'd throw it >> out for everybody's feedback: >> >> For signed error estimates, e.g. estimates of QuantityofInterest >> error where Q  Q_h ~= sum_E ( \eta_E ), what should the >> estimate_error() method put in our ErrorVector? The signed eta_E, >> or the unsigned abs(eta_E)? > > If you decide to allow signed values in ErrorVector, be sure to also > fix ErrorVector::minimum() which currently assumes only positive > values are in the vector. Will do. But after looking at a buildbot regression tonight, I'm starting to lean towards the unsigned option again: otherwise we either need our ErrorVector data type to become complexvalued or we're forced to have inconsistent behavior for enablecomplex.  Roy 