Yikes, bug-city. I'll send you a fix shortly.

  Barry


> On Apr 7, 2022, at 11:21 AM, Alfredo J Duarte Gomez <[email protected]> 
> wrote:
> 
> Hello Barry,
> 
> Thank you for the clarification, the petsc user manual does list snes_mf_type 
> <default or wp> as the options so I was confused.
> 
> I believe the function accuracy is fine, but I would like to experiment with 
> other "h" routines to see if I can get some improvement for small time steps. 
> However, i am still having  trouble switching that routine at least from what 
> I see from the message I described in my previous email. I tried out 
> -snes_mf_type dp, but it did not change the output.
> 
> I am currently only calling SNESSetFromOptions() on my snes object, which I 
> assumed would handle the -snes_mf_type option. Do I need to get the Jacobian 
> from the snes and then call a MatSetFromOptions() on my matrix-free jacobian 
> to use this option?
> 
> Thank you,
> 
> -Alfredo 
> 
> On Wed, Apr 6, 2022 at 6:35 PM Barry Smith <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> I notice that this part of the message does not change even when I specify 
> "-snes_mf_type default" (which is the alternative to wp), so I am a bit 
> confused on how I interact to the -snes_mf_type or if I am interpreting the 
> message wrong. Could you clarify this?
> 
>   Hmm, the two possibilities are -snes_mf_type wp or ds. I would expect an 
> error message if you passed default.
> 
>  Regarding selecting the 
> 
>    err=1.49012e-08 (relative error in function evaluation)
> 
> this number should be the square root of the expected error in the function 
> evaluation. So for double-precision numbers and a function evaluation with no 
> noise (so computed accurately to double precision) the tolerance is the 
> square root of the machine epsilon. 
> 
> You should only change this number (make it bigger) if you know that your 
> function evaluations are not fully accurate. For example, if you know your 
> function evaluation is only accurate to 10 decimal digits you could use an 
> err of 1e-5. 
> 
> But if your function evaluations are accurate to double precision then 
> changing this number is unlikely to help anything.
> 
>   Barry
> 
> 
> 
> 
>> On Apr 6, 2022, at 3:13 PM, Alfredo J Duarte Gomez <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Good afternoon petsc team, 
>> 
>> I have a few questions regarding the matrixfree in the snes context.
>> 
>> I am currently using the matrix-free method with my own preconditioner to 
>> solve a TS problem. I currently trigger this with the -snes_mf_operator 
>> option.
>> 
>> So far the default values have been working great, but I ran into trouble 
>> during a convergence study when I made the time step very small, which I 
>> suspect is probably happening because it's dropping below the matrix-vector 
>> product tolerance.
>> 
>> I wanted to explore the parameters of the matrix-vector product but using 
>> the -snes_view option I notice that the following full message comes out:
>> 
>> -----------------------------------------------------------------------------------
>> SNES Object: 96 MPI processes
>>   type: newtonls
>>   maximum iterations=20, maximum function evaluations=10000
>>   tolerances: relative=1e-06, absolute=1e-06, solution=1e-15
>>   total number of linear solver iterations=14
>>   total number of function evaluations=35
>>   norm schedule ALWAYS
>>   Jacobian is never rebuilt
>>   Jacobian is applied matrix-free with differencing
>>   Jacobian is applied matrix-free with differencing, no explict Jacobian
>>   SNESLineSearch Object: 96 MPI processes
>>     type: l2
>>     maxstep=1.000000e+08, minlambda=1.000000e-12
>>     tolerances: relative=1.000000e-08, absolute=1.000000e-15, 
>> lambda=1.000000e-08
>>     maximum iterations=1
>>   KSP Object: 96 MPI processes
>>     type: gmres
>>       restart=100, using Classical (unmodified) Gram-Schmidt 
>> Orthogonalization with no iterative refinement
>>       happy breakdown tolerance 1e-30
>>     maximum iterations=400, initial guess is zero
>>     tolerances:  relative=0.01, absolute=1e-50, divergence=10000.
>>     left preconditioning
>>     using PRECONDITIONED norm type for convergence test
>>   PC Object: 96 MPI processes
>>     type: shell
>>       MyPreconditioner
>>     linear system matrix followed by preconditioner matrix:
>>     Mat Object: 96 MPI processes
>>       type: mffd
>>       rows=8400000, cols=8400000
>>         Matrix-free approximation:
>>           err=1.49012e-08 (relative error in function evaluation)
>>           Using wp compute h routine
>>               Does not compute normU
>>     Mat Object: 96 MPI processes
>>       type: mpiaij
>>       rows=8400000, cols=8400000, bs=4
>>       total: nonzeros=2041029504, allocated nonzeros=2041029504
>>       total number of mallocs used during MatSetValues calls=0
>> --------------------------------------------------------------------------------
>> 
>> I have been focusing specifically on the part:
>> 
>>         Matrix-free approximation:
>>           err=1.49012e-08 (relative error in function evaluation)
>>           Using wp compute h routine
>>               Does not compute normU
>> 
>> I notice that this part of the message does not change even when I specify 
>> "-snes_mf_type default" (which is the alternative to wp), so I am a bit 
>> confused on how I interact to the -snes_mf_type or if I am interpreting the 
>> message wrong. Could you clarify this?
>> 
>> Also let me know if you have any general suggestions on tightening the 
>> tolerance of the matricxvector products.
>> 
>> Thank you,
>> 
>> -Alfredo  
>> 
>> 
>> 
>> -- 
>> Alfredo Duarte
>> Graduate Research Assistant
>> The University of Texas at Austin
> 
> 
> 
> -- 
> Alfredo Duarte
> Graduate Research Assistant
> The University of Texas at Austin

Reply via email to