Hi Tim,
On Wed, Aug 27, 2008 at 3:53 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
>
> Please find attached the new patch that corrects the error I made in
> parallel for the L-infty norm. After all, I did not change the name of the
> L_INF norm since I think the result of the discussion is that thi
Dear John
On Tue, 26 Aug 2008, John Peterson wrote:
Unfortunately the error is not a linear function in general, even
though the approximate solution may be.
Yes. I was thinking about the case where the 'exact' solution is just
a solution on a finer grid, in which case (if I understand the
On Aug 26, 2008, at 9:27 AM, David Knezevic wrote:
> But the L2, H1 etc errors in ExactSolution are computed using
> quadrature
> rules, so they are just approximations as well.
They are not approximations if both your FE solution and the analytic
solution you are comparing against can be inte
> Well... yeah but it still feels it's a different class of
> approximation deserving a different enum. Errors in computing the L2
> and H1 errors are due to quadrature error, which can be bounded in
> terms of higher-order derivatives of the exact solution. The
> approximate L_INF norm calculati
On Tue, Aug 26, 2008 at 10:27 AM, David Knezevic <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>>> What about returning this value as the DISCRETE_L_INF norm instead? In
>>> particular since the FEMNormType enum offers this norm anyway.
>>
>> I think this might be confusing ... the DISCRETE_ versions are
On Tue, Aug 26, 2008 at 10:22 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John,
>
> On Tue, 26 Aug 2008, John Peterson wrote:
>
>> On Tue, Aug 26, 2008 at 9:20 AM, Tim Kroeger
>>>
>>> On Tue, 26 Aug 2008, John Peterson wrote:
>>>
I'm not sure about your implementation of L_INF. You're t
Dear John,
On Tue, 26 Aug 2008, John Peterson wrote:
> On Tue, Aug 26, 2008 at 9:20 AM, Tim Kroeger
>>
>> On Tue, 26 Aug 2008, John Peterson wrote:
>>
>>> I'm not sure about your implementation of L_INF. You're taking
>>>
>>> ||e||_{\infty} = max_q |e(x_q)|
>>>
>>> where x_q are the quadrature p
On Tue, Aug 26, 2008 at 10:22 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
>
> Also, there is a different error in my patch: In parallel, I sum up the
> L-infty norms of all the processors, instead of taking their max value.
Ah very true, there is a Parallel::sum for the error_vals at the end
of _co
Hi all,
>> What about returning this value as the DISCRETE_L_INF norm instead? In
>> particular since the FEMNormType enum offers this norm anyway.
>
> I think this might be confusing ... the DISCRETE_ versions are meant
> to be for R^n vectors, and in this case of course you can get the
> "exact
On Tue, Aug 26, 2008 at 9:20 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John,
>
> On Tue, 26 Aug 2008, John Peterson wrote:
>
>> I'm not sure about your implementation of L_INF. You're taking
>>
>> ||e||_{\infty} = max_q |e(x_q)|
>>
>> where x_q are the quadrature points. In fact, isn't th
On Tue, Aug 26, 2008 at 9:15 AM, Derek Gaston <[EMAIL PROTECTED]> wrote:
> In Encore at Sandia you get the choice to either compute L_Inf at the
> quadrature points or at the nodes.
>
> There really isn't a good way to give L_Inf for a finite element
> calculation because our solutions are cont
Dear John,
On Tue, 26 Aug 2008, John Peterson wrote:
> I'm not sure about your implementation of L_INF. You're taking
>
> ||e||_{\infty} = max_q |e(x_q)|
>
> where x_q are the quadrature points. In fact, isn't the solution
> sometimes superconvergent at the quadrature points, and therefore this
In Encore at Sandia you get the choice to either compute L_Inf at the
quadrature points or at the nodes.
There really isn't a good way to give L_Inf for a finite element
calculation because our solutions are continuous functions. The
finite difference guys would just take the difference
On Tue, Aug 26, 2008 at 5:02 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
> Dear John,
>
> On Mon, 25 Aug 2008, John Peterson wrote:
>
>> On Mon, Aug 25, 2008 at 8:28 AM, Tim Kroeger
>
>>> Would you please be so kind and check that changes in (provided you like
>>> them)?
>>
>> I'll take a look at th
Dear John,
On Mon, 25 Aug 2008, John Peterson wrote:
> On Mon, Aug 25, 2008 at 8:28 AM, Tim Kroeger
>> Would you please be so kind and check that changes in (provided you like
>> them)?
>
> I'll take a look at this patch today. Thanks!
So, what was the result of looking at the patch?
Best Reg
Hi Tim,
On Mon, Aug 25, 2008 at 8:28 AM, Tim Kroeger
<[EMAIL PROTECTED]> wrote:
>
> Would you please be so kind and check that changes in (provided you like
> them)?
I'll take a look at this patch today. Thanks!
--
John
-
Dear all,
Meanwhile, I found out that the ExactSolution class seems to offer
exactly what I need. However, I have attached a patch that extends
that class in two ways:
1. It is satisfied with const references to the EquationSystem
objects.
2. It can compute also the L1 and L_INF norms of
Dear all,
Some time has passed since this discussion (I suddenly had to work on
different things). Since time may have solved some things, I ask
again:
Is there currently a method to perform a comparison of two computation
results on different grids (one of which is finer than the other) *in
Dear Roy and all,
On Wed, 16 Apr 2008, Roy Stogner wrote:
> On Wed, 16 Apr 2008, Tim Kroeger wrote:
>
>> Next question from me: Is there some easy way in libMesh to compare
>> computation results on different grids? I.e., I have two
>> EquationSystems instances that consist of equal systems but l
> The tool I work on here at work can compare any two arbitrary
> solutions to each other... even with completely non-nested grids. The
> user gets to decide what kind of crime they want to commit though.
> Often (if the meshes are really dissimilar) we'll use an overkill
> rendezvous mesh to tra
On Wed, 16 Apr 2008, John Peterson wrote:
> In the nested case, differing p-levels would also be interesting.
> Should I then perform my integration over the mesh which has a single
> high-p element or over the one that chose to split it into multiple
> low-degree elements having small h?
You in
On Wed, Apr 16, 2008 at 9:27 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Wed, 16 Apr 2008, John Peterson wrote:
>
>
> > Just out of curiosity, what would be the "right thing" to do in order
> > to compare two meshes with different (still nested) refinement
> > patterns or two solutions on co
Dear Roy and all,
On Wed, 16 Apr 2008, Roy Stogner wrote:
> On Wed, 16 Apr 2008, John Peterson wrote:
>
>> It's not immediately obvious to me what such a comparison would
>> actually tell you in any case...
>
> Oh, well I just meant that *what* to do to integrate between two such
> grids was obvio
The tool I work on here at work can compare any two arbitrary
solutions to each other... even with completely non-nested grids. The
user gets to decide what kind of crime they want to commit though.
Often (if the meshes are really dissimilar) we'll use an overkill
rendezvous mesh to transfer both
On Wed, 16 Apr 2008, John Peterson wrote:
> Just out of curiosity, what would be the "right thing" to do in order
> to compare two meshes with different (still nested) refinement
> patterns or two solutions on completely non-nested grids?
Loop over one grid. On each element, if the other grid i
On Wed, Apr 16, 2008 at 8:15 AM, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
> On Wed, 16 Apr 2008, Tim Kroeger wrote:
>
> > Next question from me: Is there some easy way in libMesh to compare
> > computation results on different grids? I.e., I have two
> > EquationSystems instances that consist
On Wed, 16 Apr 2008, Tim Kroeger wrote:
> Next question from me: Is there some easy way in libMesh to compare
> computation results on different grids? I.e., I have two
> EquationSystems instances that consist of equal systems but live on
> different grids, where both grids are refinements of th
Dear libMesh team,
Next question from me: Is there some easy way in libMesh to compare
computation results on different grids? I.e., I have two
EquationSystems instances that consist of equal systems but live on
different grids, where both grids are refinements of the same initial
grid. For
28 matches
Mail list logo
