> On Jun 28, 2016, at 9:30 AM, Jed Brown <[email protected]> wrote:
> 
> Thanks, Barry.  My blunder with the tests.  Should we still try to do the 
> optimization?

   I don't know, but it is creating a whole bunch of matrices which I didn't 
understand since with only RHS Jacobian it should be able to just use the one 
matrix. 

   So is it ending up with 3 matrices in memory requiring 3 times the memory 
needs? Definitely a bad thing!  

   Perhaps you can debug why my optimization broke the reuse ability and fix 
the reuse issue (if it is fixable) with my optimization? I don't have time to 
do it now.

   Barry



> 
> Barry Smith <[email protected]> writes:
> 
>>  Fixed in barry/fix-tscomputerhsjacobianconstant/maint merged to next for 
>> nightly testing
>> 
>>  Had I any brains at all I would have had Dominic use git bisect to 
>> determine the cause (which was Barry who added an optimization that broke 
>> Jed's cool trick for constant Jacobians) and this would have been resolved 
>> long ago. Curse on Jed for not adding his test cases, that he did write at 
>> least, to the automatic testing list in the makefile.
>> 
>>   Barry
>> 
>> 
>>> On Mar 23, 2016, at 5:54 PM, Barry Smith <[email protected]> wrote:
>>> 
>>> 
>>>  This problem still exists. What do we do? Broken code that a beginner 
>>> could easily start with is not a good thing.
>>> 
>>> Barry
>>> 
>>>> On Feb 27, 2016, at 5:21 PM, Barry Smith <[email protected]> wrote:
>>>> 
>>>> 
>>>> Jed and Emil,
>>>> 
>>>> Yes, this is a terrible mess. The TSComputeRHSJacobianConstant() will only 
>>>> work for methods that do not change entries in the Jacobian matrix. And 
>>>> for some reason the runex3_4 and _5 which do not work are turned off in 
>>>> the makefile !  It looks like Rosw does work because it does not change 
>>>> the matrix? And yet it is still turned off? 
>>>> 
>>>> I don't know what a good fix is. If we want to keep this capability then 
>>>> the TSComputeRHSJacobianConstant() interface has to keep a copy of the 
>>>> original user provided matrix and copy it into the matrices used by the 
>>>> method each time. This may lead to ugly special case code.
>>>> 
>>>> Something has to be done about (simplest thing is just tossing the entire 
>>>> concept) because now there is a very broken API in TS that beginning users 
>>>> are likely to try and get upset with.
>>>> 
>>>> Barry
>>>> 
>>>> 
>>>>> On Feb 26, 2016, at 11:04 AM, Dominic Meiser <[email protected]> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I'm running into problems with TS with a time independent, linear
>>>>> rhs.  Following the user's manual, I use
>>>>> 
>>>>> ierr=TSSetProblemType(ts, TS_LINEAR);CHKERRQ(ierr);
>>>>> ierr=TSSetRHSFunction(ts, 0, TSComputeRHSFunctionLinear, 0);CHKERRQ(ierr);
>>>>> ierr=TSSetRHSJacobian(ts, mat, mat, TSComputeRHSJacobianConstant, 
>>>>> 0);CHKERRQ(ierr);
>>>>> 
>>>>> But running the code I get:
>>>>> 
>>>>> [dmeiser@ivyamd src]$ ./sd -ts_monitor -snes_monitor 
>>>>> -ksp_monitor_true_residual -snes_converged_reason -ts_type beuler 
>>>>> -ts_max_steps 20 TS dt 0.01 time 0.
>>>>> 0 SNES Function norm 1.433485640883e+00 
>>>>>   0 KSP preconditioned resid norm 1.433485640883e-02 true resid norm 
>>>>> 1.433485640883e+00 ||r(i)||/||b|| 1.000000000000e+00
>>>>>   1 KSP preconditioned resid norm 6.528150237447e-18 true resid norm 
>>>>> 6.122666587510e-16 ||r(i)||/||b|| 4.271173992185e-16
>>>>> 1 SNES Function norm 1.419007435910e+02 
>>>>> Nonlinear solve converged due to CONVERGED_ITS iterations 1
>>>>> 1 TS dt 0.01 time 0.01
>>>>> 0 SNES Function norm 1.433342292319e+02 
>>>>> Nonlinear solve did not converge due to DIVERGED_LINEAR_SOLVE iterations 0
>>>>> [0]PETSC ERROR: --------------------- Error Message 
>>>>> --------------------------------------------------------------
>>>>> [0]PETSC ERROR:  
>>>>> [0]PETSC ERROR: TSStep has failed due to DIVERGED_NONLINEAR_SOLVE, 
>>>>> increase -ts_max_snes_failures or make negative to attempt recovery
>>>>> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html 
>>>>> for trouble shooting.
>>>>> [0]PETSC ERROR: Petsc Development GIT revision: pre-tsfc-330-gda8116b  
>>>>> GIT Date: 2016-02-23 15:17:17 -0600
>>>>> [0]PETSC ERROR: ./sd on a cplx named ivyamd.txcorp.com by dmeiser Fri Feb 
>>>>> 26 11:46:29 2016
>>>>> [0]PETSC ERROR: Configure options --with-scalar-type=complex --with-x=0 
>>>>> --with-debugging=1 --with-ssl=0 --with-fortran-kernels=0 --with-pthread=0 
>>>>> --download-fftw=1 --with-mpi=1 --download-mpich=1 
>>>>> --with-mpiuni-fortran-binding=0 --with-fortran-interfaces
>>>>> [0]PETSC ERROR: #1 TSStep() line 3346 in 
>>>>> /scr_ivyamd/dmeiser/SD/petsc/src/ts/interface/ts.c
>>>>> [0]PETSC ERROR: #2 TSSolve() line 3544 in 
>>>>> /scr_ivyamd/dmeiser/SD/petsc/src/ts/interface/ts.c
>>>>> [0]PETSC ERROR: #3 main() line 63 in /scr_ivyamd/dmeiser/SD/src/sd.c
>>>>> [0]PETSC ERROR: PETSc Option Table entries:
>>>>> [0]PETSC ERROR: -ksp_monitor_true_residual
>>>>> [0]PETSC ERROR: -snes_converged_reason
>>>>> [0]PETSC ERROR: -snes_monitor
>>>>> [0]PETSC ERROR: -ts_max_steps 2
>>>>> [0]PETSC ERROR: -ts_monitor
>>>>> [0]PETSC ERROR: -ts_type beuler
>>>>> [0]PETSC ERROR: ----------------End of Error Message -------send entire 
>>>>> error message to [email protected]
>>>>> application called MPI_Abort(MPI_COMM_WORLD, 91) - process 0
>>>>> [unset]: aborting job:
>>>>> application called MPI_Abort(MPI_COMM_WORLD, 91) - process 0
>>>>> 
>>>>> 
>>>>> It seems that the linear system is being solved just fine.  But
>>>>> apparently it's the wrong linear problem because the SNES
>>>>> function norm doesn't decrease.
>>>>> 
>>>>> I think the problem might be related to the following behaviour
>>>>> of `scr/ts/examples/tutorials/ex3.c`:
>>>>> 
>>>>> 
>>>>> [dmeiser@ivyamd tutorials]$ ./ex3 -nox -ts_type beuler -ts_max_steps 2 
>>>>> -ksp_converged_reason -snes_monitor
>>>>> Solving a linear TS problem on 1 processor
>>>>> Timestep   0: step size = 0.000143637, time = 0., 2-norm error = 
>>>>> 1.01507e-15, max norm error = 3.10862e-15
>>>>> 0 SNES Function norm 2.018485956680e+03 
>>>>> Linear solve converged due to CONVERGED_RTOL iterations 1
>>>>> 1 SNES Function norm 1.207665524289e+05 
>>>>> Timestep   1: step size = 0.000143637, time = 0.000143637, 2-norm error = 
>>>>> 0.000599907, max norm error = 0.000863771
>>>>> 0 SNES Function norm 1.195422385486e+05 
>>>>> Linear solve did not converge due to DIVERGED_PCSETUP_FAILED iterations 0
>>>>>                PCSETUP_FAILED due to FACTOR_NUMERIC_ZEROPIVOT 
>>>>> [0]PETSC ERROR: --------------------- Error Message 
>>>>> --------------------------------------------------------------
>>>>> [0]PETSC ERROR:  
>>>>> [0]PETSC ERROR: TSStep has failed due to DIVERGED_NONLINEAR_SOLVE, 
>>>>> increase -ts_max_snes_failures or make negative to attempt recovery
>>>>> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html 
>>>>> for trouble shooting.
>>>>> [0]PETSC ERROR: Petsc Development GIT revision: pre-tsfc-330-gda8116b  
>>>>> GIT Date: 2016-02-23 15:17:17 -0600
>>>>> [0]PETSC ERROR: ./ex3 on a cplx named ivyamd.txcorp.com by dmeiser Fri 
>>>>> Feb 26 11:36:28 2016
>>>>> [0]PETSC ERROR: Configure options --with-scalar-type=complex --with-x=0 
>>>>> --with-debugging=1 --with-ssl=0 --with-fortran-kernels=0 --with-pthread=0 
>>>>> --download-fftw=1 --with-mpi=1 --download-mpich=1 
>>>>> --with-mpiuni-fortran-binding=0 --with-fortran-interfaces
>>>>> [0]PETSC ERROR: #1 TSStep() line 3346 in 
>>>>> /scr_ivyamd/dmeiser/SD/petsc/src/ts/interface/ts.c
>>>>> [0]PETSC ERROR: #2 TSSolve() line 3544 in 
>>>>> /scr_ivyamd/dmeiser/SD/petsc/src/ts/interface/ts.c
>>>>> [0]PETSC ERROR: #3 main() line 216 in 
>>>>> /scr_ivyamd/dmeiser/SD/petsc/src/ts/examples/tutorials/ex3.c
>>>>> [0]PETSC ERROR: PETSc Option Table entries:
>>>>> [0]PETSC ERROR: -ksp_converged_reason
>>>>> [0]PETSC ERROR: -nox
>>>>> [0]PETSC ERROR: -snes_monitor
>>>>> [0]PETSC ERROR: -ts_max_steps 2
>>>>> [0]PETSC ERROR: -ts_type beuler
>>>>> [0]PETSC ERROR: ----------------End of Error Message -------send entire 
>>>>> error message to [email protected]
>>>>> application called MPI_Abort(MPI_COMM_WORLD, 91) - process 0
>>>>> [unset]: aborting job:
>>>>> application called MPI_Abort(MPI_COMM_WORLD, 91) - process 0
>>>>> 
>>>>> 
>>>>> I'm aware of Jed's commit e1244c6 which I thought was supposed to
>>>>> enable constant linear rhs without IFunction and IJacobian.  Note
>>>>> that e1244c6 also added tests that apparently produced very
>>>>> different output (see e.g.
>>>>> src/ts/examples/tutorials/output/ex3_4.out).
>>>>> 
>>>>> Is constant rhs without IFunction and IJacobian no longer
>>>>> supported or did it just breat at some point?  Do I need to call
>>>>> TSRHSJacobianSetReuse in addition to the lines of code above?  Is
>>>>> it better to treat such systems using TSComputeIFunctionLinear
>>>>> and TSComputeIJacobianConstant?
>>>>> 
>>>>> Thanks,
>>>>> Dominic
>>>>> 
>>>>> -- 
>>>>> Dominic Meiser
>>>>> Tech-X Corporation - 5621 Arapahoe Avenue - Boulder, CO 80303
>>>> 
>>> 

Reply via email to