<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:03 PM,  <span dir="ltr"><<a href="mailto:Carol.Brickley@awe.co.uk" target="_blank">Carol.Brickley@awe.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
All,<br>
<br>
I am still having problems with data inconsistencies. We think it is loss of accuracy but am not sure. I have tried using 1 tolerance of 1e-12 for the ksp tolerance (ksp_rtol) but that doesn't seem to change matters.<br></blockquote><div><br></div><div>I am not sure I understand what you want. What you seemed to report in the first email was a difference in output of size 1e-21. This is</div><div>smaller than the machine epsilon for double precision by several order of magnitude:</div><div><br></div><div>  <a href="http://en.wikipedia.org/wiki/Machine_epsilon">http://en.wikipedia.org/wiki/Machine_epsilon</a></div><div><br></div><div>This means that if you reverse the sum of just two numbers, you can have a difference this large since floating point operations are not</div><div>commutative. In general, you can only expect an answer accurate to</div><div><br></div><div>  \kappa(A) \epsilon</div><div><br></div><div>where \kappa(A) is the condition number of your operator, and this applies to both direct and iterative methods. So, there is a loss of </div><div>accuracy compared to exact arithmetic, but this is inherent in the definition floating point.</div><div><br></div><div>  Thanks,</div><div><br></div><div>      Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Carol<br>
<br>
<br>
Dr Carol Brickley<br>
BSc,PhD,ARCS,DIC,MBCS<br>
<br>
Senior Software Engineer<br>
Applied Computer Science<br>
DS+T,<br>
AWE<br>
Aldermaston<br>
Reading<br>
Berkshire<br>
RG7 4PR<br>
<br>
Direct: 0118 9855035<br>
<br>
-----Original Message-----<br>
From: Brickley Carol AWE<br>
Sent: 29 January 2015 17:12<br>
To: 'Barry Smith'<br>
Subject: RE: EXTERNAL: Re: EXTERNAL: Re: [petsc-users] F90 to petsc 3.4.3 interface - loss of accuracy<br>
<br>
Hi,<br>
<br>
The data change is in material temperature and pressure. It is different from the unstructured case.<br>
<br>
I tried using 1e-12 but this made no difference. I also thought it may be the way the 2d structured matrix is read in compared to the 1d unstructured matrix but as its symmetrical apparently this would not matter (ie, inner index before outer or vice versa).<br>
<br>
Any other ideas would be gratefully appreciated.<br>
<br>
Carol<br>
<br>
Dr Carol Brickley<br>
BSc,PhD,ARCS,DIC,MBCS<br>
<br>
Senior Software Engineer<br>
Applied Computer Science<br>
DS+T,<br>
AWE<br>
Aldermaston<br>
Reading<br>
Berkshire<br>
RG7 4PR<br>
<br>
Direct: 0118 9855035<br>
<br>
-----Original Message-----<br>
From: Barry Smith [mailto:<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>]<br>
Sent: 28 January 2015 18:59<br>
To: Brickley Carol AWE; PETSc users list<br>
Subject: EXTERNAL: Re: EXTERNAL: Re: [petsc-users] F90 to petsc 3.4.3 interface - loss of accuracy<br>
<br>
<br>
> On Jan 28, 2015, at 12:54 PM, <<a href="mailto:Carol.Brickley@awe.co.uk">Carol.Brickley@awe.co.uk</a>> <<a href="mailto:Carol.Brickley@awe.co.uk">Carol.Brickley@awe.co.uk</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I have a F90 suite that uses the petsc and runs for structured and unstructured matrices. For the unstructured we do not see the change at tiny decimal places but in the structured we do.<br>
<br>
   What data is the change in? A solution? Some derived quantity of the solution? Or in a residual?  Depending on what the difference is in generally that seems a very small difference to me.<br>
<br>
> The same solver is being used - GMRES. The tolerance should be 1e-10 in both cases but I can check in case there is a mistake.<br>
<br>
   You can try using KSP and SNES tolerances of 1e-12 to see if you get closer match -ksp_rtol 1.e-12 -snes_rtol 1.e-12<br>
><br>
> Carol<br>
><br>
> Dr Carol Brickley<br>
> BSc,PhD,ARCS,DIC,MBCS<br>
><br>
> Senior Software Engineer<br>
> Applied Computer Science<br>
> DS+T,<br>
> AWE<br>
> Aldermaston<br>
> Reading<br>
> Berkshire<br>
> RG7 4PR<br>
><br>
> Direct: 0118 9855035<br>
><br>
> -----Original Message-----<br>
> From: Barry Smith [mailto:<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>]<br>
> Sent: 28 January 2015 18:52<br>
> To: Brickley Carol AWE<br>
> Cc: <a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</a><br>
> Subject: EXTERNAL: Re: [petsc-users] F90 to petsc 3.4.3 interface - loss of accuracy<br>
><br>
><br>
>> On Jan 28, 2015, at 12:39 PM, <<a href="mailto:Carol.Brickley@awe.co.uk">Carol.Brickley@awe.co.uk</a>> <<a href="mailto:Carol.Brickley@awe.co.uk">Carol.Brickley@awe.co.uk</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Does anyone find loss of accuracy between F90 code and Petsc 3.4.3 C codes? I am noticing that some of my data is returning 9.99999997e-13 instead of 1.00000000e-12 for example.<br>
><br>
>  I am not sure exactly what your question is. Do you have two codes a F90 code without PETSc and a PETSc based C code? What is the data that is different? Is it solutions, residual values, ...?  This kind of small difference can often be caused by different tolerances used during the iterative solvers. We'll need more information in order to make any suggestions.<br>
><br>
>   Barry<br>
><br>
>><br>
>> Carol<br>
>><br>
>> Dr Carol Brickley<br>
>> BSc,PhD,ARCS,DIC,MBCS<br>
>><br>
>> Senior Software Engineer<br>
>> Applied Computer Science<br>
>> DS+T,<br>
>> AWE<br>
>> Aldermaston<br>
>> Reading<br>
>> Berkshire<br>
>> RG7 4PR<br>
>><br>
>> Direct: 0118 9855035<br>
>><br>
>> ___________________________________________________ ____________________________ The information in this email and in any attachment(s) is commercial in confidence. If you are not the named addressee(s) or if you receive this email in error then any distribution, copying or use of this communication or the information in it is strictly prohibited. Please notify us immediately by email at admin.internet(at)<a href="http://awe.co.uk" target="_blank">awe.co.uk</a>, and then delete this message from your computer. While attachments are virus checked, AWE plc does not accept any liability in respect of any virus which is not detected. AWE Plc Registered in England and Wales Registration No 02763902 AWE, Aldermaston, Reading, RG7 4PR<br>
>><br>
><br>
><br>
> ___________________________________________________<br>
> ____________________________<br>
><br>
> The information in this email and in any attachment(s) is<br>
> commercial in confidence. If you are not the named addressee(s)<br>
> or<br>
> if you receive this email in error then any distribution, copying or<br>
> use of this communication or the information in it is strictly<br>
> prohibited. Please notify us immediately by email at<br>
> admin.internet(at)<a href="http://awe.co.uk" target="_blank">awe.co.uk</a>, and then delete this message from<br>
> your computer. While attachments are virus checked, AWE plc<br>
> does not accept any liability in respect of any virus which is not<br>
> detected.<br>
><br>
> AWE Plc<br>
> Registered in England and Wales<br>
> Registration No 02763902<br>
> AWE, Aldermaston, Reading, RG7 4PR<br>
<br>
<br>
___________________________________________________<br>
____________________________<br>
<br>
The information in this email and in any attachment(s) is<br>
commercial in confidence. If you are not the named addressee(s)<br>
or<br>
if you receive this email in error then any distribution, copying or<br>
use of this communication or the information in it is strictly<br>
prohibited. Please notify us immediately by email at<br>
admin.internet(at)<a href="http://awe.co.uk" target="_blank">awe.co.uk</a>, and then delete this message from<br>
your computer. While attachments are virus checked, AWE plc<br>
does not accept any liability in respect of any virus which is not<br>
detected.<br>
<br>
AWE Plc<br>
Registered in England and Wales<br>
Registration No 02763902<br>
AWE, Aldermaston, Reading, RG7 4PR<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>