[petsc-dev] Interface for HIPS

On Tue, Dec 11, 2012 at 1:52 PM, John Fettig wrote: > It provides a parallel Schur complement preconditioner which can evidently > handle in a black-box fashion ill conditioned systems. I presume that the > interface to HYPRE would be extremely similar in nature. Here are a couple > of references

[petsc-dev] Fwd: Is there any example that allows time-integration provided by users

On Thu, Dec 13, 2012 at 9:30 AM, Peter Brune wrote: > > > > On Thu, Dec 13, 2012 at 11:29 AM, Barry Smith wrote: >> >> >> On Dec 13, 2012, at 11:27 AM, Peter Brune wrote: >> >> > An abandoned attempt at this lies dormant in src/snes/impls/multiblock. >> > We could try to revive it. >> >>Or a

[petsc-dev] making make cmake less verbose

On Thu, Dec 13, 2012 at 1:23 PM, Barry Smith wrote: > > > On Dec 13, 2012, at 3:18 PM, Jed Brown wrote: > >> It is displaying all the debugging information. You'll only get the useful >> information if you run this: >> >> make -j5 -C arch-gnu > >Yes, your suggestion is not verbose because it

[petsc-dev] "Libraries don't have to suck"

On Fri, Dec 14, 2012 at 5:20 PM, Barry Smith wrote: > > It won't fix any complaints because people will just live with their > out-of-date code until we remove the legacy support and THEN they will > complain. (And by then we'll have half-forgotten what we did so it will be > harder to help p

[petsc-dev] "Libraries don't have to suck"

On Fri, Dec 14, 2012 at 10:02 PM, Barry Smith wrote: > > We could have a two tar balls, the petsc release with backward > compatibility and one without and randomly parcel then out to downloaders. > Then wait two releases and collect all the petsc-maint data from both sets of > users and see

[petsc-dev] Seeeeaaaannnnnn!

On Thu, Dec 20, 2012 at 11:23 PM, Sean Farley wrote: > On Thu, Dec 20, 2012 at 10:15 PM, Barry Smith wrote: >> >> Snn! >> >>Yes Jed I know Apple computers suck. >> >>But how do I fix this? Note that simply changing SCALAPACK.py to >> scalapack.py doesn't resolve the problem

[petsc-dev] Seeeeaaaannnnnn!

On Thu, Dec 20, 2012 at 11:26 PM, Sean Farley wrote: > On Thu, Dec 20, 2012 at 10:23 PM, Sean Farley wrote: >> On Thu, Dec 20, 2012 at 10:15 PM, Barry Smith wrote: >>> >>> Snn! >>> >>>Yes Jed I know Apple computers suck. >>> >>>But how do I fix this? Note that simply changi

[petsc-dev] Documentation comment support

On Sun, Dec 23, 2012 at 9:27 PM, Barry Smith wrote: > > On Dec 23, 2012, at 4:16 PM, Jed Brown wrote: > > > On Sun, Dec 23, 2012 at 9:56 AM, Karl Rupp wrote: > > > > > > As for the cross-referencing manuals and man-pages: I talked with Barry > about that two weeks ago, since I had to produce a

[petsc-dev] Documentation comment support

On Sun, Dec 23, 2012 at 10:02 PM, Jed Brown wrote: > On Sun, Dec 23, 2012 at 8:55 PM, Barry Smith wrote: > >>What do you mean? Do you mean manual1.ind? Surely you don't mean from >> manual.pdf? > > > Yeah, we can grab it from manual1.ind and convert it to #page= links in > the HTML man page

[petsc-dev] New Year's renaming: DMComplex

On Tue, Jan 1, 2013 at 8:36 AM, Karl Rupp wrote: > Hi, > > > Can DMComplex also be used with real numbers? ;-) >> >> Yes, still the most commonly-asked question, and not likely to be fixed >> by popularity. The new year sounds like a good excuse to fix this >> confusion. Possible suggestions t

[petsc-dev] PetscPrintf() is never suppose to be used to print error messages

On Wed, Jan 2, 2013 at 2:07 AM, Barry Smith wrote: > > that is what (*PetscErrorPrintf)() is for. Please fix. Thanks Barry > > > ierr = MatSetValues(A, numIndices, indices, numIndices, indices, values, > mode); > if (ierr) { > PetscMPIIntrank; > PetscErrorCode ierr2; > > ier

[petsc-dev] PetscPrintf() is never suppose to be used to print error messages

On Wed, Jan 2, 2013 at 11:39 AM, Jed Brown wrote: > On Wed, Jan 2, 2013 at 11:32 AM, Matthew Knepley wrote: > >> I fixed the simple thing, but the PrintMatSetValues() is problematic. >> Right now, it just prints using >> PetscPrintf, which is wrong for errors like thi

[petsc-dev] SNES for 2x2 problems

On Wed, Jan 2, 2013 at 3:21 PM, Jed Brown wrote: > Matt, you know how we always tell people not to use KSP (or even Lapack) > for 2x2 problems? Surely the same advice applies to SNES, but your point > location code is doing it. > Yep. The wrapping overhead is far less with some Newton iterations

[petsc-dev] SNES for 2x2 problems

On Wed, Jan 2, 2013 at 4:19 PM, Jed Brown wrote: > On Wed, Jan 2, 2013 at 4:16 PM, Matthew Knepley wrote: > >> On Wed, Jan 2, 2013 at 3:21 PM, Jed Brown wrote: >> >>> Matt, you know how we always tell people not to use KSP (or even Lapack) >>> for 2x2 prob

[petsc-dev] Problem Assembling MatCreateAIJ (Parallel Sparse Matrix)

We cannot see the error message. Use CHKERRXX Matt On Jan 3, 2013 1:11 PM, "Hesameddin Ilatikhameneh" wrote: > The point is the problem occurs when I'm assembling the matrix and since > it is unsuccessful MatView gives error. > I assemble the matrix: > > this->Petsc_Error = >

[petsc-dev] Problem Assembling MatCreateAIJ (Parallel Sparse Matrix)

mpi/mpiaij.c > [1]PETSC ERROR: MatAssemblyEnd() line 4879 in > /home/Codes/trunk/Libs/Petsc/PETSC_Build_Real/src/mat/interface/matrix.c > > Thanks > Hesam > - Original Message - > From: "Matthew Knepley" > To: "For users of the development version o

[petsc-dev] patch for BiCG on GPUs.

On Mon, Jan 7, 2013 at 10:19 AM, Paul Mullowney wrote: > No problem. Thanks for the feedback. > > Sorry about the slow reply. Yes, petsc-dev is a good place for this. I > have a couple comments. First, it's *much* better to split the > "organization" part of the patch (which should be benign) fr

[petsc-dev] Nonblocking consensus and alternative "freespace" interface

On Mon, Jan 7, 2013 at 3:11 PM, Barry Smith wrote: > > On Jan 7, 2013, at 3:02 PM, Jed Brown wrote: > > > On Mon, Jan 7, 2013 at 2:39 PM, Barry Smith wrote: > > I think you should namespace the Seg thingy with Petsc and I'd advocate > namespacing even all the static functions with PETSc, makes

[petsc-dev] Nonblocking consensus and alternative "freespace" interface

On Mon, Jan 7, 2013 at 3:18 PM, Jed Brown wrote: > On Mon, Jan 7, 2013 at 3:16 PM, Matthew Knepley wrote: > >> I use the _Private(). > > > A lot of those _Private()s are exported symbols (because they are shared > within the library). > They should be file sco

[petsc-dev] Nonblocking consensus and alternative "freespace" interface

On Mon, Jan 7, 2013 at 3:20 PM, Jed Brown wrote: > On Mon, Jan 7, 2013 at 3:19 PM, Matthew Knepley wrote: > >> They should be file scope. > > > $ grep _Private include/**/*.h | wc > 53 2276600 > The PetscOptions and PetscInfo functions are example

[petsc-dev] Nonblocking consensus and alternative "freespace" interface

On Mon, Jan 7, 2013 at 5:42 PM, Barry Smith wrote: > > On Jan 7, 2013, at 5:28 PM, Jed Brown wrote: > > > On Mon, Jan 7, 2013 at 3:29 PM, Matthew Knepley > wrote: > > The PetscOptions and PetscInfo functions are examples where we used > _Private to > > indicat

[petsc-dev] Documentation comment support

On Tue, Jan 8, 2013 at 9:34 PM, Jed Brown wrote: > On Tue, Jan 8, 2013 at 9:32 PM, Jed Brown wrote: > >> On Tue, Jan 8, 2013 at 8:45 PM, Karl Rupp wrote: >> >>> I was thinking of using an input filter, perhaps after creating an index. http://www.stack.nl/~dimitri/**doxygen/manual/conf

[petsc-dev] Documentation comment support

On Tue, Jan 8, 2013 at 9:50 PM, Jed Brown wrote: > On Tue, Jan 8, 2013 at 9:43 PM, Matthew Knepley wrote: > >> Those wimps just call cpp instead of writing the preprocessor in Python >> too (I did this). That means >> you cannot regenerate properly. >> > >

[petsc-dev] Documentation comment support

On Tue, Jan 8, 2013 at 10:03 PM, Jed Brown wrote: > On Tue, Jan 8, 2013 at 9:54 PM, Matthew Knepley wrote: > >> I originally was forced into it to get typedefs, which have to be handled >> by the preprocessor. > > > This is crazy talk. The preprocessor doesn&

[petsc-dev] Documentation comment support

On Tue, Jan 8, 2013 at 10:32 PM, Jed Brown wrote: > On Tue, Jan 8, 2013 at 10:26 PM, Matthew Knepley wrote: > >> Bullshit. Try and do that. You will see the problem. > > > I don't know what you're getting at, but the fact remains that cpp does > nothing to

[petsc-dev] Documentation comment support

On Wed, Jan 9, 2013 at 7:58 AM, Jed Brown wrote: > On Tue, Jan 8, 2013 at 10:35 PM, Matthew Knepley wrote: > >> Look at the grammar from the back of K&R. It requires TYPE tokens when >> you have definitions. However, >> the lexer will produce an ID token unless y

[petsc-dev] [mpich-discuss] MPICH migration to git

On Wed, Jan 9, 2013 at 10:32 PM, "C. Bergstr?m" wrote: > On 01/10/13 11:23 AM, Barry Smith wrote: > >> On Jan 9, 2013, at 10:19 PM, Dmitry Karpeev wrote: >> >> My summary would be that >>> 1. Git's ui is bad >>> 2. There is the crappy index thingie >>> 3. I don't see how git branches are better

[petsc-dev] inconsistency for its own sake?

On Fri, Jan 11, 2013 at 12:12 PM, Jed Brown wrote: > Ah, Dependency versus Duplication. I blame the lack of transparency on the > editors, which could display the definition of the typedef instead of > having to jump to it. I like that the typedefs allow us to document the > function in one place

[petsc-dev] Compliant C89

On Mon, Jan 14, 2013 at 9:02 AM, Jed Brown wrote: > The cast macros like PetscBLASIntCast() are not "safe" in that they > include two separate statements. Unfortunately, we cannot do better with > C89 unless we pass the target as an argument. Regardless, these casts * > cannot* be used in declara

[petsc-dev] Compliant C89

On Mon, Jan 14, 2013 at 11:17 AM, Barry Smith wrote: > > On Jan 14, 2013, at 9:02 AM, Jed Brown wrote: > > > The cast macros like PetscBLASIntCast() are not "safe" in that they > include two separate statements. Unfortunately, we cannot do better with > C89 unless we pass the target as an argume

[petsc-dev] Barry doesn't like typedefs for function pointers

On Tue, Jan 15, 2013 at 9:49 AM, Lisandro Dalcin wrote: > On Mon, Jan 14, 2013 at 1:00 AM, Barry Smith wrote: > > > > ... please don't introduce new ones in the future. > > > > Can you provide your rationale for this? > Its in another thread, but you can't see the calling sequence. Matt

[petsc-dev] multiple dispatch code currently in PETSc

On Tue, Jan 15, 2013 at 1:50 PM, Barry Smith wrote: > > Do we really want mallocs for EVERY single multiple-dispatch function > call in PETSc? I suggest not having MatQueryOp() but calling directly > PetscOpFListFind() (with the MatOpFList argument) and changing > PetscOpFListAdd/Find() to use

[petsc-dev] PETSc goes Doxygen!?

On Tue, Jan 15, 2013 at 2:37 PM, Jed Brown wrote: > On Tue, Jan 15, 2013 at 2:15 PM, Karl Rupp wrote: > >> The listing of >> http://krupp.iue.tuwien.ac.at/**petsc-doxygen/ksp_2ksp_** >> 2examples_2tutorials_2ex4_8c-**example.html

[petsc-dev] PETSc goes Doxygen!?

On Tue, Jan 15, 2013 at 3:35 PM, Jed Brown wrote: > On Tue, Jan 15, 2013 at 3:30 PM, Matthew Knepley wrote: > >> I agree that it is not "user visible", but that does not mean I don't >> want documentation on it. >> > > There is no documentation on it

[petsc-dev] PETSc goes Doxygen!?

On Tue, Jan 15, 2013 at 2:15 PM, Karl Rupp wrote: > Hi again, > > some more improvements to the doxygen generation process have been applied: > Right now, the search stinks. If I type in GetCone I get nothing found, whereas DMPlexGetCone has three things found, but does not find DMPlexSe

[petsc-dev] PETSc goes Doxygen!?

On Tue, Jan 15, 2013 at 4:36 PM, Karl Rupp wrote: > Hi Matt, > > > Right now, the search stinks. If I type in >> >>GetCone >> >> I get nothing found, whereas >> >>DMPlexGetCone >> >> has three things found, but does not find DMPlexSetCone. This is crappy, >> and will >> not replace seein

[petsc-dev] Runge-Kutta example in TS

On Wed, Jan 16, 2013 at 12:04 PM, Gautam Bisht wrote: > Hi Jed, > > Is there an example of RK in petsc-dev? I found no result by running the > following command from petsc-dev/src/ts/examples/ > > grep -Ri 'TSRK' ./ > http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/TS/TSSSPRKS2.html

[petsc-dev] I hate this one

I thought we agreed that some of this is not crucial. I can't stand this in my code. Hate Hate Hate. https://bitbucket.org/petsc/petsc-dev/commits/cf69a5905ee4 Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 8:08 AM, Jed Brown wrote: > On Mon, Jan 21, 2013 at 7:49 AM, Matthew Knepley wrote: > >> I thought we agreed that some of this is not crucial. I can't >> stand this in my code. Hate Hate Hate. >> > > Oh come on, three "Hate&quo

[petsc-dev] I hate this one

s. This is exactly why people hate these standards. Prescribing a few, coarse features is fine and improves readability. Specifying the tiniest details is senseless and intrusive fascism. Matt > On Jan 21, 2013 8:10 AM, "Matthew Knepley" wrote: > >> On Mon, Jan 21, 2013 at 8

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 9:15 AM, Jed Brown wrote: > > On Mon, Jan 21, 2013 at 9:04 AM, Matthew Knepley wrote: > >> There is no getting over this. This is exactly why people hate these >> standards. Prescribing a few, coarse >> features is fine and improves readabil

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 9:18 AM, Matthew Knepley wrote: > On Mon, Jan 21, 2013 at 9:15 AM, Jed Brown wrote: > >> >> On Mon, Jan 21, 2013 at 9:04 AM, Matthew Knepley wrote: >> >>> There is no getting over this. This is exactly why people hate these >>

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 9:37 AM, Jed Brown wrote: > > On Mon, Jan 21, 2013 at 9:18 AM, Matthew Knepley wrote: > >> Again, there are limits to everything, and this surpasses the useful >> limit to this kind of specification. This is not personal expression, this >> is

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 9:51 AM, Jed Brown wrote: > > On Mon, Jan 21, 2013 at 9:42 AM, Matthew Knepley wrote: > >> Again, the data does not support you. An incredible number of instances, >> and almost all files were changed. Thus, >> this was far from "unconv

[petsc-dev] I hate this one

On Mon, Jan 21, 2013 at 10:06 AM, Karl Rupp wrote: > Hi Matt, > > > > Again, there are limits to everything, and this surpasses the useful > >> limit to this kind of specification. This is not personal >> expression, this >> is ease of reading. >> >> >> Also, judging by the ENORMO

[petsc-dev] Removed functions in MPI 3

On Mon, Jan 21, 2013 at 4:12 PM, Karl Rupp wrote: > Dear PETScians, > > MPI 3.0 *removes* a set of functions from MPI 1.x, of which the following > are in use in PETSc: > > * MPI_Type_struct, used in >src/ts/characteristic/impls/**da/slda.c >src/dm/impls/mesh/meshpcice.c > > * MPI_Errha

[petsc-dev] I hate this one

; > I say committing/pushing? because I don't know what the exact mechanism > would be to have consistent format in the master repository but each person > free to edit in their own format. But there should be a way, it only makes > sense. > > > On Jan 21, 2013, at 9:56 AM, Mat

[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

On Mon, Jan 21, 2013 at 7:18 PM, Jed Brown wrote: > > On Mon, Jan 21, 2013 at 7:05 PM, Karl Rupp wrote: > >> Things like >>> >>> if (y < 12) {ierr = Something(); CHKERRQ(ierr);} >>> >>> don't match the standard but ?. am I being too picky? I believe the >>> PETSc make uncrustify rule w

[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

On Mon, Jan 21, 2013 at 7:23 PM, Karl Rupp wrote: > Hi, > > > >> Things like >> >> if (y < 12) {ierr = Something(); CHKERRQ(ierr);} >> >> don't match the standard but ?. am I being too picky? I believe >> the PETSc make uncrustify rule would move that t

[petsc-dev] Style Guide: How to format single-line if/for/while-blocks?

On Tue, Jan 22, 2013 at 2:02 PM, Jed Brown wrote: > On Tue, Jan 22, 2013 at 1:28 PM, Karl Rupp wrote: > >> Yes, I'm aware of that. Since we have to update hgrc for the BuildSystem >> anyway, it's 'just another line'. >> > > Yeah, well, I still think it's rude for a build script to mess with the

[petsc-dev] Removed functions in MPI 3

On Tue, Jan 22, 2013 at 3:51 PM, Karl Rupp wrote: > Hi, > > MPI 3.0 *removes* a set of functions from MPI 1.x, of which the >> following are in use in PETSc: >> >> * MPI_Type_struct, used in >> src/ts/characteristic/impls/__**da/slda.c >> src/dm/impls/mesh/meshpcice

[petsc-dev] Removed functions in MPI 3

On Tue, Jan 22, 2013 at 4:12 PM, Karl Rupp wrote: > Hi Matt, > > Since there was a lack of consensus on alternatives, I applied >> Matt's Right Way here: >> https://bitbucket.org/petsc/__**petsc-dev/commits/__** >> fabf60c7d012db5a109255579665b5**__c2

[petsc-dev] Nightly tests quick summary page

On Wed, Jan 23, 2013 at 4:37 PM, Karl Rupp wrote: > Dear PETScians, > > I've adopted the HTML summary page script for the style checks a little in > order to have a quick overview of the results of our nightly tests: > > http://krupp.iue.tuwien.ac.at/**petsc-test/

[petsc-dev] Nightly tests quick summary page

On Wed, Jan 23, 2013 at 9:29 PM, Jed Brown wrote: > > On Wed, Jan 23, 2013 at 9:08 PM, Matthew Knepley wrote: > >> I am always skeptical of big programs to overall a large piece of >> infrastructure that works fairly well. >> >> However, there is a really simp

[petsc-dev] Fwd: Nightly tests quick summary page

On Thu, Jan 24, 2013 at 9:47 AM, Jed Brown wrote: > > On Thu, Jan 24, 2013 at 9:39 AM, Karl Rupp wrote: > >> Testing for the same number of iterations is - as you mentioned - a >> terrible metric. I see this regularly on GPUs, where rounding modes differ >> slightly from CPUs. Running a fixed (l

[petsc-dev] Making a PetSc Roll and Rocks Module

On Thu, Jan 24, 2013 at 12:51 PM, Barry Smith wrote: > > > Begin forwarded message: > > *From: *Philip Papadopoulos > *Subject: **Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module > * > *Date: *January 24, 2013 9:48:36 AM CST > *To: *"Schneider, Barry I." > *Cc: *Barry Smith > > D

[petsc-dev] Making a PetSc Roll and Rocks Module

On Thu, Jan 24, 2013 at 1:12 PM, Satish Balay wrote: > On Thu, 24 Jan 2013, Barry Smith wrote: > > > > > > > Begin forwarded message: > > > > > From: Philip Papadopoulos > > > Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module > > > Date: January 24, 2013 9:48:36 AM CST > >

[petsc-dev] Removed functions in MPI 3

On Tue, Jan 22, 2013 at 4:48 PM, Jed Brown wrote: > > On Tue, Jan 22, 2013 at 4:39 PM, Karl Rupp wrote: > >> Carefully fiddling with my local sources prior to the commit... I don't >> know of a way to test the backwards-macros other than inspecting the >> preprocessed code... >> >> Oh, and Barry

[petsc-dev] Making a PetSc Roll and Rocks Module

uilds and debug / optimized > versions > Pushed something that writes your simple module file to lib/modules/PETSc.mod. It would now be good to get feedback to make this the right thing. Matt > Blaise > > > wrote: > > > > On Thu, 24 Jan 2013, Matthew Knepley wrote: >

[petsc-dev] Making a PetSc Roll and Rocks Module

pend-path PATH /home/balay/spetsc/asterix64/bin:/home/balay/spetsc/bin > > I have some fixes [except for the modfile name] which I can push. > Cool, do it. Matt > thanks, > Satish > > > > > Blaise > > > > > > On Jan 24, 2013, at 6:19 PM,

[petsc-dev] Ongoing formatting changes

On Mon, Jan 28, 2013 at 3:22 PM, Jed Brown wrote: > These changes are pretty obnoxious for contributors who have to constantly > rebase or merge (generating useless merge commits) amidst the constant > formatting changes. Since most of these are applications of scripts, can we > just enqueue them

[petsc-dev] Uncrustify has fucked up my file

Why is it putting fucking whitespace in? I don't need this shit. Matt -- 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 -- next part -- An H

[petsc-dev] Uncrustify has fucked up my file

On Thu, Jan 31, 2013 at 8:24 PM, Jed Brown wrote: > On Thu, Jan 31, 2013 at 7:18 PM, Matthew Knepley wrote: > >> Why is it putting fucking whitespace in? I don't need this shit. >> > > I don't know, it looks nicer to me. ;-) > You think the moustache looks

[petsc-dev] Uncrustify has fucked up my file

On Thu, Jan 31, 2013 at 8:35 PM, Karl Rupp wrote: > Hi Matt, > > > Why is it putting fucking whitespace in? I don't need this shit. >> >> >> I don't know, it looks nicer to me. ;-) >> >> >> You think the moustache looks nice. >> > > :-D I don't think the comparison is legit at this p

[petsc-dev] Uncrustify has fucked up my file

On Thu, Jan 31, 2013 at 8:40 PM, Jed Brown wrote: > > On Thu, Jan 31, 2013 at 7:37 PM, Matthew Knepley wrote: > >> This essentially already *was* consistent throughout PETSc already, the >>> exception being src/dm/*. It is, however, not written explicitly in

[petsc-dev] Pushing non-working code

I think non-working is a misnomer here. These do not break the build. Matt On Feb 2, 2013 4:23 PM, "Jed Brown" wrote: > It seems like every time I pull PETSc, I get more build noise from unused > or uninitialized variables. I have a suggestion: if it's not clean yet, > just don't push it. If

[petsc-dev] Pushing non-working code

On Sat, Feb 2, 2013 at 5:20 PM, Jed Brown wrote: > > On Sat, Feb 2, 2013 at 4:14 PM, Matthew Knepley wrote: > >> I think non-working is a misnomer here. These do not break the build. > > > They issue warnings and the code can't possibly execute correctly. Jus

[petsc-dev] Pushing non-working code

On Sat, Feb 2, 2013 at 5:56 PM, Karl Rupp wrote: > Hi guys, > > > > They issue warnings and the code can't possibly execute correctly. > >> Just don't push it (or push it somewhere else) until it's been >> cleaned up to the point where it's not wasting our time to review. >> >> >> I w

[petsc-dev] Pushing non-working code

On Sat, Feb 2, 2013 at 6:44 PM, Jed Brown wrote: > The other issue is that we work with applications that need to be able to > rely on their PETSc being stable. If we can provide a 'dev' that is > relatively stable, we can rapidly deliver new features, which encourages > them to work more closely

[petsc-dev] Pushing non-working code

On Sat, Feb 2, 2013 at 6:00 PM, Jed Brown wrote: > > On Sat, Feb 2, 2013 at 4:38 PM, Matthew Knepley wrote: > >> I would love it if people never pushed code with any bugs. This is >> possible, just not efficient. All changes to >> workflow should be evaluated on this

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:02 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 9:35 AM, Matthew Knepley wrote: > >> Again, you misuse words when it is convenient for you. This is dishonest >> argument. >> >> "Stable" for applications means that the beh

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:09 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 9:58 AM, Matthew Knepley wrote: > >> It is not the current workflow that must be justified, but a mandatory >> change in that workflow. I don't think there is any >> evidence that it inc

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:14 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 11:09 AM, Matthew Knepley wrote: > >> If the checkin you originally complained about the build did not fail and >> a memory leak did not appear. You >> still cannot explain what was wrong

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley wrote: > >> Can you quantify your productivity gains that come from pushing >>> checkpoints instead of waiting for a semantically meaningful point to merge >&

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:20 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley wrote: > >> I did address. It would be great if people never pushed warnings. I try >> not to. >> > > You push new warnings almost every day. > Hyperb

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:27 PM, Sean Farley wrote: > On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley > wrote: > > > >> > >> Pushing as a checkpointing mechanism discourages review. > > > > > > Review should happend when the section is complete

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:24 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley wrote: > >> Its more work for me. Clearly you are asking me to do something I do not >> currently do. A loss. >> > > How is _not typing 'hg merge' o

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:31 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 11:23 AM, Matthew Knepley wrote: > >> How do you identify what the feature is when it's in 10 commits >>> interspersed over 200 in the history. My claim is that you should make >>>

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:32 PM, Karl Rupp wrote: > On 02/03/2013 11:25 AM, Sean Farley wrote: > >> On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley >> wrote: >> >>> On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown wrote: >>> >>>> >

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:49 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 11:31 AM, Matthew Knepley wrote: > >> How is _not typing 'hg merge' or 'hg pull'_ harder than typing it? Do >>> your work in a bookmark and merge it when it's ready for

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 12:59 PM, Karl Rupp wrote: > Hi Matt, > > > On 02/03/2013 11:37 AM, Matthew Knepley wrote: > >> >> +1 for Sean. I'm tired of carefully writing down the points I'm >> trying to make, carefully (re-)reading through what

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 1:29 PM, Karl Rupp wrote: > Hi Matt, > > > > --- > >> 'I don't think there is any >> >> evidence that it increases productivity, and quite a lot that it is >> rather marginal on that score while increasing development >> costs. I do not see any effect fr

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 1:38 PM, Matthew Knepley wrote: > On Sun, Feb 3, 2013 at 1:29 PM, Karl Rupp wrote: > >> Hi Matt, >> >> >> > --- >> >>> 'I don't think there is any >>> >>> evidence that it increases pr

[petsc-dev] Pushing non-working code

On Sun, Feb 3, 2013 at 2:04 PM, Jed Brown wrote: > > On Sun, Feb 3, 2013 at 12:29 PM, Karl Rupp wrote: > >> New developers are usually willing to adapt to the workflow of the >> project anyways, particularly if it follows established 'best practices'. >> 'Compile cleanly at high warning levels'

[petsc-dev] Should we add something like this?

http://www.geodynamics.org/cig/software/pylith/user_resources/submit_pub Matt -- 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 -- next part ---

[petsc-dev] Should we add something like this?

d of CGI can we run at ANL? or what form submission can they do? Thanks, Matt > On Mon, Feb 4, 2013 at 3:55 PM, Matthew Knepley wrote: > >> http://www.geodynamics.org/cig/software/pylith/user_resources/submit_pub >> >>Matt >> >> -- >>

[petsc-dev] Should we add something like this?

On Mon, Feb 4, 2013 at 5:13 PM, Satish Balay wrote: > On Mon, 4 Feb 2013, Matthew Knepley wrote: > > > Satish, what kind of CGI can we run at ANL? or what form submission can > > they do? > > I see TAO uses some CGI for download - so presumably we can use >

[petsc-dev] Registration implicitly collective on COMM_WORLD

On Mon, Feb 4, 2013 at 11:40 PM, Jed Brown wrote: > On Mon, Feb 4, 2013 at 10:05 PM, Barry Smith wrote: > >> >>This is currently a mess. >> >>Say one process calls PetscFunctionListAdd() with a function pointer, >> but another calls it with the string name of the function. Now both >> pr

[petsc-dev] Registration implicitly collective on COMM_WORLD

egistered. > Tell them its not loaded and see if they can figure out that it is. Matt > ?.. > > Including where the comms are passed around for all the methods. > > Barry > > > On Feb 4, 2013, at 10:53 PM, Matthew Knepley wrote: > > > On Mon, Feb

[petsc-dev] Registration implicitly collective on COMM_WORLD

On Tue, Feb 5, 2013 at 12:08 AM, Jed Brown wrote: > > On Mon, Feb 4, 2013 at 11:01 PM, Barry Smith wrote: > >>Now we need to make several more decisions. >> >> 1) are PETSc package registrations collective? sys, vec, mat, dm, ksp, >> snes, ts >> currently as Jed noted they are not excep

[petsc-dev] Registration implicitly collective on COMM_WORLD

On Tue, Feb 5, 2013 at 12:29 AM, Jed Brown wrote: > > On Mon, Feb 4, 2013 at 11:10 PM, Matthew Knepley wrote: > >> 2) are all PETSc packages registered upfront during PetscInitialize()? >>>> currently only with dynamic loading of petsc libs >>>> >

[petsc-dev] Registration implicitly collective on COMM_WORLD

On Tue, Feb 5, 2013 at 8:28 AM, Jed Brown wrote: > > On Mon, Feb 4, 2013 at 11:33 PM, Matthew Knepley wrote: > >> I see nothing wrong with those tradeoffs, its just beginning to sound >> complicated to me (like the Fortran stuff I can never remember). >> I would say,

[petsc-dev] Registration implicitly collective on COMM_WORLD

On Tue, Feb 5, 2013 at 8:42 AM, Jed Brown wrote: > > On Tue, Feb 5, 2013 at 7:32 AM, Matthew Knepley wrote: > >>4. XXIntializePackage() is called automatically for all default PETSc >> classes when using --with-single-library=1 >> >> I am guessing that defau

[petsc-dev] ugliness due to missing lapack routines

On Wed, Feb 6, 2013 at 8:45 PM, Barry Smith wrote: > > PETSc is littered with > > if (A->factortype == MAT_FACTOR_LU) { > #if defined(PETSC_MISSING_LAPACK_GETRS) > SETERRQ(PETSC_COMM_SELF,PETSC_ERR_SUP,"GETRS - Lapack routine is > unavailable."); > #else > > PetscStackCall("LAPACKgetrs",L

[petsc-dev] removing PETSC_NULL?

On Wed, Feb 6, 2013 at 9:33 PM, Jed Brown wrote: > On Wed, Feb 6, 2013 at 7:35 PM, Barry Smith wrote: > >> >>In 1994 NULL was a pain because for different systems it was in >> different include files and sometimes you had to do very nasty stuff like >> >> #if !defined(NULL) >> #define NULL

[petsc-dev] macro functions growing like rabbits

On Wed, Feb 6, 2013 at 11:12 PM, Jed Brown wrote: > On Wed, Feb 6, 2013 at 10:07 PM, Barry Smith wrote: > >> >> >> While I'm busy converting macro functions to C functions, others >> (unnamed, but Jed knows how to find them using the revision control system) >> are adding new ones like there i

[petsc-dev] ugliness due to missing lapack routines

On Wed, Feb 6, 2013 at 11:43 PM, Jed Brown wrote: > On Wed, Feb 6, 2013 at 9:43 PM, Matthew Knepley wrote: > >> On Wed, Feb 6, 2013 at 8:45 PM, Barry Smith wrote: >> >>> >>> PETSc is littered with >>> >>> if (A->factortype == MA

[petsc-dev] ugliness due to missing lapack routines

On Wed, Feb 6, 2013 at 11:53 PM, Jed Brown wrote: > > On Wed, Feb 6, 2013 at 10:45 PM, Matthew Knepley wrote: > >> I think we have to make a distinction as to what kind of code is in >> there. The proposed >> stub does nothing but raise an error, just as Fortran stub

[petsc-dev] ugliness due to missing lapack routines

On Thu, Feb 7, 2013 at 12:09 AM, Jed Brown wrote: > > On Wed, Feb 6, 2013 at 11:00 PM, Matthew Knepley wrote: > >> You are right. All of petscblaslapack.h should be generated :) > > > Perhaps, but not in petscconf.h. I think rampant duplication is the much > bigger

[petsc-dev] ugliness due to missing lapack routines

On Thu, Feb 7, 2013 at 5:07 PM, Jed Brown wrote: > > On Thu, Feb 7, 2013 at 3:50 PM, Barry Smith wrote: > >>Why would it not be? Your editor is not capable of ever displaying >> more than one buffer ever? >> > > Now I'll have two versions of the "same file". I could probably even > script Em

<    9   10   11   12   13   14   15   16   17   18   >