On Thu, Apr 3, 2014 at 2:49 PM, Åsmund Ervik <[email protected]> wrote:
> Hi Matt, > > I'm handling the null space in the same way as ex34, that is, I remove the > null space (containing just the constant functions, I think) in both > ComputeRHS and ComputeMatrix. > That should be fine. > However, I just tried commenting out those lines (MatNullSpaceCreate, > MatSetNullSpace or MatNullSpaceRemove, MatNullSpaceDestroy) and that has no > effect. The same happens in ex34.c, commenting out the lines fixing the > null space makes no difference. Does that make sense? > It appears that the RHS in ex34 already has zero mean. Its possible for some Krylov iteration to preserve this property, but I think if you played around with solvers you could find one that screws it up without null space removal. > Are these examples intended to be run with some special options? I see in > the makefile (e.g. runex34) that there are a lot of multigrid options, but > I don't think that should matter? > > Also, could you confirm that ex34.c does zero Neumann BCs? The header was > a bit confusing, it says u=0 but I assume it should be du/dn = 0 (zero > normal derivative)? > Yes, its pure Neumann. Note that this is an easy analytical solution, so you can check your example. Matt > This is with 3.4.4, by the way. > > Thanks, > Åsmund > > ------------------------------ > *Fra:* Matthew Knepley [[email protected]] > *Sendt:* 3. april 2014 15:56 > *Til:* Åsmund Ervik > *Kopi:* [email protected] > *Emne:* Re: [petsc-users] Trying to write Fortran version of ksp/ex34.c > > On Thu, Apr 3, 2014 at 8:43 AM, Åsmund Ervik <[email protected]>wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Dear PETSc users, >> >> I'm trying to write a Poisson solver in Fortran using the >> KSPSetComputeOperators etc. framework. When debugging this, I ended up >> modifying ksp/ex22.f so that it matches ksp/ex34.c. The difference >> between these is that ex34.c has a non-constant RHS and Neumann BCs, >> which is closer to what I want. >> > > If it has Neumann conditions, then it has a null space. Have you > included this in > your solver? That can cause a residual offset. > > Matt > > >> Now, when I run these two programs I get the following: >> >> ./ex22f_mod >> Residual, L2 norm 1.007312 >> Error, sup norm 0.020941 >> Error, L1 norm 10.687882 >> Error, L2 norm 0.340425 >> >> ./ex34 >> Residual, L2 norm 1.07124e-05 >> Error, sup norm 0.0209405 >> Error, L1 norm 0.00618512 >> Error, L2 norm 0.000197005 >> >> but when I MatView/VecView the matrix and RHS for each example (write >> them to file), there is no difference. I have attached ex22f_mod.F90, >> any suggestions on what the error is? >> >> Once this example works, you can of course include it with PETSc. >> >> Regards, >> Åsmund >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQEcBAEBAgAGBQJTPWWZAAoJED+FDAHgGz19aNYIANyq9k3a5kHzTlAdybkZCYDw >> yKtDE5l/4iWYmNL49FH8AocHVcRivLaeJG5CGKqySFtZUXOlC9DM7rn4UmuQecni >> dgIQuTk0Ym+OJccHyT5xxnebpFVNrIOTpInfQaDW6dTyeL1svAMeHqslKaGepySL >> q/cODbgNDYgl6uumB+POMZevtlM6HPhl/1m7HofcHC9upvTRjSPqP1cg+kg+/8m2 >> Fdie/X7PCBfShrAys94kNXNcwtbO7taauphkQGMfyl0gUd+lFATG6zrEZdDqSFlV >> c44GFFbxW/SRIDBXdOeX9/cy75KW5do1Sildwb6R4H/i7t6/hCJUJuss7FHjmLc= >> =tV3N >> -----END PGP SIGNATURE----- >> > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
