Re: [petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Zhang, Junchao via petsc-users]

Also works with PathScale EKOPath Compiler Suite installed on MCS machines.

$ pathcc -c check-pic.c -fPIC
$ pathcc -c check-pic.c
check-pic.c:2:2: error: "no-PIC"
#error "no-PIC"
 ^
1 error generated.

--Junchao Zhang


On Tue, May 28, 2019 at 1:54 PM Smith, Barry F. via petsc-users 
mailto:petsc-users@mcs.anl.gov>> wrote:

  Works for Intel and PGI compiles (the version I checked)

bsmith@es:~$ pgcc check-pic.c  -PIC
pgcc-Error-Unknown switch: -PIC
bsmith@es:~$ pgcc check-pic.c  -fPIC
bsmith@es:~$ pgcc check-pic.c
PGC-F-0249-#error --  "no-PIC" (check-pic.c: 2)
PGC/x86-64 Linux 19.3-0: compilation aborted
bsmith@es:~$ icc check-pic.c
check-pic.c(2): error: #error directive: "no-PIC"
  #error "no-PIC"
   ^

compilation aborted for check-pic.c (code 2)
bsmith@es:~$ icc check-pic.c -PIC
icc: command line warning #10006: ignoring unknown option '-PIC'
check-pic.c(2): error: #error directive: "no-PIC"
  #error "no-PIC"
   ^

compilation aborted for check-pic.c (code 2)
bsmith@es:~$ icc check-pic.c -fPIC
bsmith@es:~$


You are the man!


> On May 28, 2019, at 12:29 PM, Lisandro Dalcin via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
>
>
>
> On Tue, 28 May 2019 at 18:19, Jed Brown 
> mailto:j...@jedbrown.org>> wrote:
> Lisandro Dalcin via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> writes:
>
> > On Tue, 28 May 2019 at 17:31, Balay, Satish via petsc-users <
> > petsc-users@mcs.anl.gov> wrote:
> >
> >> Configure.log shows '--with-pic=1' - hence this error.
> >>
> >> Remove '--with-pic=1' and retry.
> >>
> >>
> > Nonsense. Why this behavior? Building a static library with PIC code is a
> > perfectly valid use case.
>
> And that's what will happen because Inge passed -fPIC in CFLAGS et al.
>
> Do you know how we could confirm that PIC code is generated without
> attempting to use shared libraries?
>
>
> I know how to do it with the `readelf` command for ELF objects. I even know 
> how to do it compile-time for GCC and clang. Maybe Intel also works this way. 
> I do not know about a general solution, though.
>
> $ cat check-pic.c
> #ifndef __PIC__
> #error "no-PIC"
> #endif
>
> $ gcc -c check-pic.c -fPIC
>
> $ clang -c check-pic.c -fPIC
>
> $ gcc -c check-pic.c
> check-pic.c:2:2: error: #error "no-PIC"
> 2 | #error "no-PIC"
>   |  ^
>
> $ clang -c check-pic.c
> check-pic.c:2:2: error: "no-PIC"
> #error "no-PIC"
>  ^
> 1 error generated.
>
> --
> Lisandro Dalcin
> 
> Research Scientist
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/

Re: [petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Jed Brown via petsc-users]

No love with:

cc: Sun C 5.12 Linux_i386 2011/11/16


Note that all of these compilers (including Sun C, which doesn't define
the macro) recognize -fPIC.  (Blue Gene xlc requires -qpic.)  Do we
still need to test the other alternatives?

"Smith, Barry F."  writes:

>   Works for Intel and PGI compiles (the version I checked)
>
> bsmith@es:~$ pgcc check-pic.c  -PIC
> pgcc-Error-Unknown switch: -PIC
> bsmith@es:~$ pgcc check-pic.c  -fPIC
> bsmith@es:~$ pgcc check-pic.c 
> PGC-F-0249-#error --  "no-PIC" (check-pic.c: 2)
> PGC/x86-64 Linux 19.3-0: compilation aborted
> bsmith@es:~$ icc check-pic.c 
> check-pic.c(2): error: #error directive: "no-PIC"
>   #error "no-PIC"
>^
>
> compilation aborted for check-pic.c (code 2)
> bsmith@es:~$ icc check-pic.c -PIC
> icc: command line warning #10006: ignoring unknown option '-PIC'
> check-pic.c(2): error: #error directive: "no-PIC"
>   #error "no-PIC"
>^
>
> compilation aborted for check-pic.c (code 2)
> bsmith@es:~$ icc check-pic.c -fPIC
> bsmith@es:~$ 
>
>
> You are the man!
>
>
>> On May 28, 2019, at 12:29 PM, Lisandro Dalcin via petsc-users 
>>  wrote:
>> 
>> 
>> 
>> On Tue, 28 May 2019 at 18:19, Jed Brown  wrote:
>> Lisandro Dalcin via petsc-users  writes:
>> 
>> > On Tue, 28 May 2019 at 17:31, Balay, Satish via petsc-users <
>> > petsc-users@mcs.anl.gov> wrote:
>> >
>> >> Configure.log shows '--with-pic=1' - hence this error.
>> >>
>> >> Remove '--with-pic=1' and retry.
>> >>
>> >>
>> > Nonsense. Why this behavior? Building a static library with PIC code is a
>> > perfectly valid use case.
>> 
>> And that's what will happen because Inge passed -fPIC in CFLAGS et al.
>> 
>> Do you know how we could confirm that PIC code is generated without
>> attempting to use shared libraries?
>> 
>> 
>> I know how to do it with the `readelf` command for ELF objects. I even know 
>> how to do it compile-time for GCC and clang. Maybe Intel also works this 
>> way. I do not know about a general solution, though.
>> 
>> $ cat check-pic.c 
>> #ifndef __PIC__
>> #error "no-PIC"
>> #endif
>> 
>> $ gcc -c check-pic.c -fPIC
>> 
>> $ clang -c check-pic.c -fPIC
>> 
>> $ gcc -c check-pic.c
>> check-pic.c:2:2: error: #error "no-PIC"
>> 2 | #error "no-PIC"
>>   |  ^
>> 
>> $ clang -c check-pic.c
>> check-pic.c:2:2: error: "no-PIC"
>> #error "no-PIC"
>>  ^
>> 1 error generated.
>>  
>> -- 
>> Lisandro Dalcin
>> 
>> Research Scientist
>> Extreme Computing Research Center (ECRC)
>> King Abdullah University of Science and Technology (KAUST)
>> http://ecrc.kaust.edu.sa/

Re: [petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Smith, Barry F. via petsc-users]

  Works for Intel and PGI compiles (the version I checked)

bsmith@es:~$ pgcc check-pic.c  -PIC
pgcc-Error-Unknown switch: -PIC
bsmith@es:~$ pgcc check-pic.c  -fPIC
bsmith@es:~$ pgcc check-pic.c 
PGC-F-0249-#error --  "no-PIC" (check-pic.c: 2)
PGC/x86-64 Linux 19.3-0: compilation aborted
bsmith@es:~$ icc check-pic.c 
check-pic.c(2): error: #error directive: "no-PIC"
  #error "no-PIC"
   ^

compilation aborted for check-pic.c (code 2)
bsmith@es:~$ icc check-pic.c -PIC
icc: command line warning #10006: ignoring unknown option '-PIC'
check-pic.c(2): error: #error directive: "no-PIC"
  #error "no-PIC"
   ^

compilation aborted for check-pic.c (code 2)
bsmith@es:~$ icc check-pic.c -fPIC
bsmith@es:~$ 


You are the man!


> On May 28, 2019, at 12:29 PM, Lisandro Dalcin via petsc-users 
>  wrote:
> 
> 
> 
> On Tue, 28 May 2019 at 18:19, Jed Brown  wrote:
> Lisandro Dalcin via petsc-users  writes:
> 
> > On Tue, 28 May 2019 at 17:31, Balay, Satish via petsc-users <
> > petsc-users@mcs.anl.gov> wrote:
> >
> >> Configure.log shows '--with-pic=1' - hence this error.
> >>
> >> Remove '--with-pic=1' and retry.
> >>
> >>
> > Nonsense. Why this behavior? Building a static library with PIC code is a
> > perfectly valid use case.
> 
> And that's what will happen because Inge passed -fPIC in CFLAGS et al.
> 
> Do you know how we could confirm that PIC code is generated without
> attempting to use shared libraries?
> 
> 
> I know how to do it with the `readelf` command for ELF objects. I even know 
> how to do it compile-time for GCC and clang. Maybe Intel also works this way. 
> I do not know about a general solution, though.
> 
> $ cat check-pic.c 
> #ifndef __PIC__
> #error "no-PIC"
> #endif
> 
> $ gcc -c check-pic.c -fPIC
> 
> $ clang -c check-pic.c -fPIC
> 
> $ gcc -c check-pic.c
> check-pic.c:2:2: error: #error "no-PIC"
> 2 | #error "no-PIC"
>   |  ^
> 
> $ clang -c check-pic.c
> check-pic.c:2:2: error: "no-PIC"
> #error "no-PIC"
>  ^
> 1 error generated.
>  
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/

Re: [petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Jed Brown via petsc-users]

Lisandro Dalcin via petsc-users  writes:

> On Tue, 28 May 2019 at 17:31, Balay, Satish via petsc-users <
> petsc-users@mcs.anl.gov> wrote:
>
>> Configure.log shows '--with-pic=1' - hence this error.
>>
>> Remove '--with-pic=1' and retry.
>>
>>
> Nonsense. Why this behavior? Building a static library with PIC code is a
> perfectly valid use case.

And that's what will happen because Inge passed -fPIC in CFLAGS et al.

Do you know how we could confirm that PIC code is generated without
attempting to use shared libraries?

if self.argDB['with-pic'] and not useSharedLibraries:
  # this is a flaw in configure; it is a legitimate use case where PETSc is 
built with PIC flags but not shared libraries
  # to fix it the capability to build shared libraries must be enabled in 
configure if --with-pic=true even if shared libraries are off and this
  # test must use that capability instead of using the default shared 
library build in that case which is static libraries
  raise RuntimeError("Cannot determine compiler PIC flags if shared 
libraries is turned off\nEither run using --with-shared-libraries or 
--with-pic=0 and supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and 
FCFLAGS\n")

Re: [petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Smith, Barry F. via petsc-users]

> On May 28, 2019, at 10:01 AM, Lisandro Dalcin  wrote:
> 
> 
> 
> On Tue, 28 May 2019 at 17:31, Balay, Satish via petsc-users 
>  wrote:
> Configure.log shows '--with-pic=1' - hence this error.
> 
> Remove '--with-pic=1' and retry.
> 
> 
> Nonsense. Why this behavior? Building a static library with PIC code is a 
> perfectly valid use case. 

   Indeed it is. But for that case PETSc's configure requires the user to pass 
the appropriate flag for PIC in through the compiler flags. (Should be better 
documented EXACTLY how)

   The reason for this nonsense design feature is that Configure does not know 
how to check for appropriate PIC flags unless Configure has turned on shared 
libraries for PETSc. It is rather convoluted; I'd love if someone fixed it but 
obviously Jed, Satish, and I (who agree with you that this is utter nonsense) 
are not brave enough to muck with that portion of configure.

 

> 
> -- 
> Lisandro Dalcin
> 
> Research Scientist
> Extreme Computing Research Center (ECRC)
> King Abdullah University of Science and Technology (KAUST)
> http://ecrc.kaust.edu.sa/

Re: [petsc-users] TS: How to implement a simple stopping criterion

[Zhang, Hong via petsc-users]

You are right that TSEvent is not suitable for this case.  To stop the 
timestepper, I would call TSSetConvergedReason(ts,TS_CONVERGED_USER) in a 
PostStep function.

Hong (Mr.)

> On May 28, 2019, at 4:36 AM, Patrick Sanan via petsc-users 
>  wrote:
> 
> I'm working with/on a code which uses TSSUNDIALS, and I'd like to be able to 
> stop the timestepper based on the value of the solution. In particular, I 
> wish to enforce that a given concentration has not changed by more than a 
> specified amount before stopping. Note that this is simpler than general 
> event detection, as I'm happy stopping before the condition is satisfied and 
> don't care about finding the point in time when the condition is satisfied 
> exactly.
> 
> As far as I know, PETSc's event handling interface isn't supported with the 
> SUNDIALS implementation. (As an aside, I'd be happier using TSARKIMEX or 
> another native timestepper, but so far haven't been able to avoid tiny 
> timesteps).
> 
> My question is whether the following approach has any obvious fatal flaw, and 
> if any TS gurus have other/better/simpler ideas.
> 
> The idea is to add my own logic, say with TSSetPreStep(), to:
> 
> 1. Maintain the previous step's state (this is a 1d problem, so I'm not too 
> concerned about the overhead of this)
> 2. Check my condition, and if it's satisfied, dump the previous step's data, 
> and use TSSetMaxTime() with the previous step's time, thus ending the solve.
> 

Re: [petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Balay, Satish via petsc-users]

Configure.log shows '--with-pic=1' - hence this error.

Remove '--with-pic=1' and retry.

Saitsh

On Tue, 28 May 2019, Inge Gutheil via petsc-users wrote:

> Dear PETSc list,
> when I try to install the petsc-3.11.2 library as a static library - for
> some reasons I do not want the dynamic library -
> I suddenly get the error
> 
> Cannot determine compiler PIC flags if shared libraries is turned off
> Either run using --with-shared-libraries or --with-pic=0 and supply the
> compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS
> 
> Attached find the configure.log
> I added --with-pic=0 as can seen from configure.log but I do not know
> where I can find how to set the compiler PIC flag via CFLAGS, CXXXFLAGS,
> and FCFLAGS, at least -fPIC seems to be not sufficient, so what can I do?
> 
> Wit 3.11.1 I did not have that problem.
> 
> Regards
> Inge
> 
> 

[petsc-users] How do I supply the compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

[Inge Gutheil via petsc-users]

Dear PETSc list,
when I try to install the petsc-3.11.2 library as a static library - for
some reasons I do not want the dynamic library -
I suddenly get the error

Cannot determine compiler PIC flags if shared libraries is turned off
Either run using --with-shared-libraries or --with-pic=0 and supply the
compiler PIC flag via CFLAGS, CXXXFLAGS, and FCFLAGS

Attached find the configure.log
I added --with-pic=0 as can seen from configure.log but I do not know
where I can find how to set the compiler PIC flag via CFLAGS, CXXXFLAGS,
and FCFLAGS, at least -fPIC seems to be not sufficient, so what can I do?

Wit 3.11.1 I did not have that problem.

Regards
Inge

-- 

Inge Gutheil
Juelich Supercomputing Centre
Institute for Advanced Simulation
Forschungszentrum Juelich GmbH
52425 Juelich, Germany

  Phone:   +49-2461-61-3135
  Fax: +49-2461-61-6656
  E-mail:i.guth...@fz-juelich.de

Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt



Starting configure run at Tue, 28 May 2019 13:48:21 +0200
Configure Options: --configModules=PETSc.Configure --optionsModule=config.compilerOptions --prefix=/usr/local/software/jureca/Stages/Devel-2019a/software/PETSc/3.11.2-intel-para-2019a_debug --with-large-file-io --with-debugging=1 --with-errorchecking=1 --with-cxx-dialect=C++11 --download-hypre=1 --download-spai=1 --download-triangle=1 --download-chaco=1 --download-superlu=1 --download-metis=1 --download-superlu_dist=1 --download-sundials=1 --download-mumps=1 --download-spooles=1 --download-parms=1 --download-parmetis=1 --download-hdf5=1 --download-hypre-shared=0 --download-metis-shared=0 --download-parmetis-shared=0 --download-spooles-shared=0 --download-superlu-shared=0 --download-superlu_dist-shared=0 --download-mumps-shared=0 --download-spai-shared=0 --download-chaco-shared=0 --download-sundials-shared=0 --download-parms-shared=0 --download-hdf5-shared=0 --with-cc=mpicc --with-cxx=mpicxx --with-c++-support --with-fc=mpif90 --CFLAGS="-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC" --CXXFLAGS="-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC" --FFLAGS="-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC" --with-gnu-compilers=0 --with-mpi=1 --with-build-step-np=48 --with-shared-libraries=0 --with-debugging=0 --with-pic=1 --with-x=0 --with-windows-graphics=0 --with-fftw=1 --with-fftw-include=/usr/local/software/jureca/Stages/Devel-2019a/software/imkl/2019.3.199-ipsmpi-2019a/mkl/include/fftw --with-fftw-lib="[/usr/local/software/jureca/Stages/Devel-2019a/software/imkl/2019.3.199-ipsmpi-2019a/mkl/lib/intel64/libfftw3xc_intel_pic.a,libfftw3x_cdft_lp64_pic.a,libmkl_cdft_core.a,libmkl_blacs_intelmpi_lp64.a,libmkl_intel_lp64.a,libmkl_sequential.a,libmkl_core.a]" --with-scalapack=1 --with-scalapack-include=/usr/local/software/jureca/Stages/Devel-2019a/software/imkl/2019.3.199-ipsmpi-2019a/mkl/include --with-scalapack-lib="[/usr/local/software/jureca/Stages/Devel-2019a/software/imkl/2019.3.199-ipsmpi-2019a/mkl/lib/intel64/libmkl_scalapack_lp64.a,libmkl_blacs_intelmpi_lp64.a,libmkl_intel_lp64.a,libmkl_sequential.a,libmkl_core.a]" --with-blaslapack-lib="[/usr/local/software/jureca/Stages/Devel-2019a/software/imkl/2019.3.199-ipsmpi-2019a/mkl/lib/intel64/libmkl_intel_lp64.a,libmkl_sequential.a,libmkl_core.a]"
Working directory: /dev/shm/mathprod/PETSc/3.11.2/intel-para-2019a_debug/petsc-3.11.2
Machine platform:
('Linux', 'jrl07', '3.10.0-957.5.1.el7.x86_64', '#1 SMP Fri Feb 1 14:54:57 UTC 2019', 'x86_64', 'x86_64')
Python version:
2.7.5 (default, Oct 30 2018, 23:45:53) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]


TEST configureExternalPackagesDir from config.framework(/dev/shm/mathprod/PETSc/3.11.2/intel-para-2019a_debug/petsc-3.11.2/config/BuildSystem/config/framework.py:830)
TESTING: configureExternalPackagesDir from config.framework(/dev/shm/mathprod/PETSc/3.11.2/intel-para-2019a_debug/petsc-3.11.2/config/BuildSystem/config/framework.py:830)

TEST configureDebuggers from config.utilities.debuggers(/dev/shm/mathprod/PETSc/3.11.2/intel-para-2019a_debug/petsc-3.11.2/config/BuildSystem/config/utilities/debuggers.py:21)
TESTING: configureDebuggers from 

Re: [petsc-users] Matrix free GMRES seems to ignore my initial guess

[Smith, Barry F. via petsc-users]

> On May 28, 2019, at 12:41 AM, Jan Izak Cornelius Vermaak 
>  wrote:
> 
> Checking the matrix would be hard as I have a really big operator. Its 
> transport sweeps.
> 
> When I increase the restart interval the solution converges to the right one.

  Run with -ksp_monitor_true_residual what are the true residuals being printed?

  The GMRES code has been in continuous use for 25 years, it would stunning if 
you suddenly found a bug in it. 

   How it works, within a restart, the GMRES algorithm uses a simple recursive 
formula to compute an "estimate" for the residual norm. At restart it actually 
computes the current solution and then uses that to compute an accurate 
residual norm via the formula b - A x. When the residual computed by the b - A 
x is different than that computed by the recursive formula it means the 
recursive formula has run into some difficulty (bad operator, bad 
preconditioner, null space in the operator) and is not computing correct 
values. Now if you increase the restart to past the point when it "converges" 
you are hiding the incorrectly computed values computed via the recursive 
formula. 

  I urge you to check the residual norm by b - A x at the end of the solve and 
double check that it is small. It seems unlikely GMRES is providing the correct 
answer for your problem.

   Barry


> Checked against a reference solution and Classic Richardson. It is really as 
> if the initial guess is completely ignored.
> 
> [0]  Computing b
> [0]  Iteration 0 Residual 169.302
> [0]  Iteration 1 Residual 47.582
> [0]  Iteration 2 Residual 13.2614
> [0]  Iteration 3 Residual 4.46795
> [0]  Iteration 4 Residual 1.03038
> [0]  Iteration 5 Residual 0.246807
> [0]  Iteration 6 Residual 0.0828341
> [0]  Iteration 7 Residual 0.0410627
> [0]  Iteration 8 Residual 0.0243749
> [0]  Iteration 9 Residual 0.0136067
> [0]  Iteration 10 Residual 0.00769078
> [0]  Iteration 11 Residual 0.00441658
> [0]  Iteration 12 Residual 0.00240794
> [0]  Iteration 13 Residual 0.00132048
> [0]  Iteration 14 Residual 0.00073003
> [0]  Iteration 15 Residual 0.000399504
> [0]  Iteration 16 Residual 0.000217677
> [0]  Iteration 17 Residual 0.000120408
> [0]  Iteration 18 Residual 6.49719e-05
> [0]  Iteration 19 Residual 3.44523e-05
> [0]  Iteration 20 Residual 1.87909e-05
> [0]  Iteration 21 Residual 1.02385e-05
> [0]  Iteration 22 Residual 5.57859e-06
> [0]  Iteration 23 Residual 3.03431e-06
> [0]  Iteration 24 Residual 1.63696e-06
> [0]  Iteration 25 Residual 8.78202e-07
> 
> On Mon, May 27, 2019 at 11:55 PM Smith, Barry F.  wrote:
> 
>This behavior where the residual norm jumps at restart indicates something 
> is very very wrong. Run with the option -ksp_monitor_true_residual and I 
> think you'll see the true residual is not decreasing as is the preconditioned 
> residual. My guess is that your "action of the matrix" is incorrect and not 
> actually a linear operator. Try using MatComputeExplicitOperator() and see 
> what explicit matrix it produces, is it what you expect?
> 
>Barry
> 
> 
> 
> 
> > On May 27, 2019, at 11:33 PM, Jan Izak Cornelius Vermaak via petsc-users 
> >  wrote:
> > 
> > Hi all,
> > 
> > So I am faced with this debacle. I have a neutron transport solver with a 
> > sweep code that can compute the action of the matrix on a vector.
> > 
> > I use a matrix shell to set up the action of the matrix. The method works 
> > but only if I can get the solution converged before GMRES restarts. It gets 
> > the right answer. Now my first problem is (and I only saw this when I hit 
> > the first restart) is that it looks like the solver completely resets after 
> > the GMRES-restart. Below is an iteration log with restart interval set to 
> > 10. At first I thought it wasn't updating the initial guess but it became 
> > clear that it initial guess always had no effect. I do set 
> > KSPSetInitialGuessNonZero but it has no effect.
> > 
> > Is the matrix-free business defaulting my initial guess to zero everytime? 
> > What can I do to actually supply an initial guess? I've used PETSc for 
> > diffusion many times and the initial guess always works, just not now.
> > 
> > [0]  Computing b
> > [0]  Iteration 0 Residual 169.302
> > [0]  Iteration 1 Residual 47.582
> > [0]  Iteration 2 Residual 13.2614
> > [0]  Iteration 3 Residual 4.46795
> > [0]  Iteration 4 Residual 1.03038
> > [0]  Iteration 5 Residual 0.246807
> > [0]  Iteration 6 Residual 0.0828341
> > [0]  Iteration 7 Residual 0.0410627
> > [0]  Iteration 8 Residual 0.0243749
> > [0]  Iteration 9 Residual 0.0136067
> > [0]  Iteration 10 Residual 169.302
> > [0]  Iteration 11 Residual 47.582
> > [0]  Iteration 12 Residual 13.2614
> > [0]  Iteration 13 Residual 4.46795
> > [0]  Iteration 14 Residual 1.03038
> > [0]  Iteration 15 Residual 0.246807
> > [0]  Iteration 16 Residual 0.0828341
> > [0]  Iteration 17 Residual 0.0410627
> > [0]  Iteration 18 Residual 0.0243749
> > [0]  Iteration 19 Residual 0.0136067
> > [0]  Iteration 20 Residual 169.302