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