July 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Regression tests
by Jed Brown 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:44 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > You do not read it correctly. It operates exactly as everything else. You > move make.log to make.log.bkp, which is what we do now, and > write into make.log. It seems to be writing without moving first. > > >> I think it is wrong to reuse the name make.log for both purposes. >> Regardless, the symlinks are not removed, so make.log output overwrites >> $PETSC_ARCH/conf/make.log and (the next time you run it) >> $PETSC_ARCH/conf/make.log.bkp. >> > > In my first message, it says "this is a bug". What is hard about that? > What necessitates 3 replies missing that point? Sounds like your "correct behavior" is exactly what I'm complaining about. Since there is only one level of backup, running twice, as in ./builder2.py buildExample src/... ./builder2.py buildExample src/... destroys all trace of the make.log for the library.

1 0

Re: [petsc-dev] Regression tests
by Matthew Knepley 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:39 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 26, 2012 at 2:34 PM, Matthew Knepley <knepley(a)gmail.com>wrote: > >> Well, that's an interesting (and confusing) idea for how it *could* work >>> some day, but it's not how it currently works. >>> >> >> How the fuck is that confusing? Is this just for the sake of argument. >> This is how we DESIGNED configure to work >> and treat logs. Were you absent that day? Do you have a note? >> > > Normally make.log is moved to make.log.bkp, overwriting the original > make.log.bkp. PETSc uses the symlinks to point to the latest versions of > make.log and make.log.bkp, but there is only one level of history. > > Now your suggestion here (if I read your statement correctly) was that > there would be multiple classes of make.log, with builder2.py buildExample > only overwriting make.log, but the make.log.bkp from building the library > could only be overwritten after another library build. I think that is > massively confusing. > You do not read it correctly. It operates exactly as everything else. You move make.log to make.log.bkp, which is what we do now, and write into make.log. It seems to be writing without moving first. > I think it is wrong to reuse the name make.log for both purposes. > Regardless, the symlinks are not removed, so make.log output overwrites > $PETSC_ARCH/conf/make.log and (the next time you run it) > $PETSC_ARCH/conf/make.log.bkp. > In my first message, it says "this is a bug". What is hard about that? What necessitates 3 replies missing that point? 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

1 0

Re: [petsc-dev] Regression tests
by Jed Brown 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:35 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > So what you're saying is that your system could be extended to do this? >> I'm not disagreeing, but I think my suggestion is more maintainable and >> extensible. As I said in my first reply, the differences are mostly >> cosmetic, but I think there is good reason to prefer the form I suggest. >> The important thing in either case is to have a database of tests so we can >> program behavior. >> > > Obviously I disagree. I responded to the maintainability argument, but you > just ignored the response. > Since it's maintainable to put everything in one file, why not put all of PETSc in one file? I prefer local declaration of tests and the error conditions are handled much better.

1 0

Re: [petsc-dev] Regression tests
by Jed Brown 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:34 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > Well, that's an interesting (and confusing) idea for how it *could* work >> some day, but it's not how it currently works. >> > > How the fuck is that confusing? Is this just for the sake of argument. > This is how we DESIGNED configure to work > and treat logs. Were you absent that day? Do you have a note? > Normally make.log is moved to make.log.bkp, overwriting the original make.log.bkp. PETSc uses the symlinks to point to the latest versions of make.log and make.log.bkp, but there is only one level of history. Now your suggestion here (if I read your statement correctly) was that there would be multiple classes of make.log, with builder2.py buildExample only overwriting make.log, but the make.log.bkp from building the library could only be overwritten after another library build. I think that is massively confusing. I think it is wrong to reuse the name make.log for both purposes. Regardless, the symlinks are not removed, so make.log output overwrites $PETSC_ARCH/conf/make.log and (the next time you run it) $PETSC_ARCH/conf/make.log.bkp.

1 0

Re: [petsc-dev] Regression tests
by Matthew Knepley 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:31 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 26, 2012 at 2:17 PM, Matthew Knepley <knepley(a)gmail.com>wrote: >> >> You can tell from the primary key what it is. If the primary key is >> wrong, it does not help you in your scenario as it could be >> misspelled, or intended to be put in another directory. This is dubious >> at best. >> > > I don't need the primary key to be "right" to have good diagnostics, I > just need to know that the Test() declaration (which executes code at the > time the test is created) is inconsistent. My error message tells you the > line that is bad. This is important. > > >> We should have a discussion about whether we want to support this after >> 3.3. >> >> > > What's the problem? Is builder.py having trouble figuring out how to link > PETSc in general? Maybe it should use "make getlinklibs". ;-D > > Note that people occasionally ask for minimal builds for low-level > functionality. Barry was even asking if it would be feasible to have a way > to build only some KSPs, PCs, and matrix formats. I like that the option > keeps us honest. > > >> >> > No no. Your original make log is in PETSC_ARCH/conf/make.log. It should >> never be corrupted. You >> remove the link at make.log.bkp. >> > > Well, that's an interesting (and confusing) idea for how it *could* work > some day, but it's not how it currently works. > > >> >> > >> Same way we do in the makefiles now. It has an attribute "complex", >> "superlu", etc. >> > > So what you're saying is that your system could be extended to do this? > I'm not disagreeing, but I think my suggestion is more maintainable and > extensible. As I said in my first reply, the differences are mostly > cosmetic, but I think there is good reason to prefer the form I suggest. > The important thing in either case is to have a database of tests so we can > program behavior. > Obviously I disagree. I responded to the maintainability argument, but you just ignored the response. > Some have these. > > > Held separately? > Yep. Matt > regressionRequirements = {'src/vec/vec/examples/tests/ex31': > set(['Matlab']) > } > > -- 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

1 0

Re: [petsc-dev] Complex Cholesky
by Hong Zhang 26 Jul '12

26 Jul '12

Jose : > > Then why not give a PETSC_ERR_SUP error? > Patched 3.3 and petsc-dev. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/ff096aff2a39 When I find time, I'll implement MatSolve() for seqsbaij_hermitian :-) Hong

1 0

Re: [petsc-dev] Regression tests
by Matthew Knepley 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:31 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 26, 2012 at 2:17 PM, Matthew Knepley <knepley(a)gmail.com>wrote: >> >> You can tell from the primary key what it is. If the primary key is >> wrong, it does not help you in your scenario as it could be >> misspelled, or intended to be put in another directory. This is dubious >> at best. >> > > I don't need the primary key to be "right" to have good diagnostics, I > just need to know that the Test() declaration (which executes code at the > time the test is created) is inconsistent. My error message tells you the > line that is bad. This is important. > > >> We should have a discussion about whether we want to support this after >> 3.3. >> >> > > What's the problem? Is builder.py having trouble figuring out how to link > PETSc in general? Maybe it should use "make getlinklibs". ;-D > > Note that people occasionally ask for minimal builds for low-level > functionality. Barry was even asking if it would be feasible to have a way > to build only some KSPs, PCs, and matrix formats. I like that the option > keeps us honest. > > >> >> > No no. Your original make log is in PETSC_ARCH/conf/make.log. It should >> never be corrupted. You >> remove the link at make.log.bkp. >> > > Well, that's an interesting (and confusing) idea for how it *could* work > some day, but it's not how it currently works. > How the fuck is that confusing? Is this just for the sake of argument. This is how we DESIGNED configure to work and treat logs. Were you absent that day? Do you have a note? Matt > > >> >> > >> Same way we do in the makefiles now. It has an attribute "complex", >> "superlu", etc. >> > > So what you're saying is that your system could be extended to do this? > I'm not disagreeing, but I think my suggestion is more maintainable and > extensible. As I said in my first reply, the differences are mostly > cosmetic, but I think there is good reason to prefer the form I suggest. > The important thing in either case is to have a database of tests so we can > program behavior. > > >> Some have these. > > > Held separately? > > regressionRequirements = {'src/vec/vec/examples/tests/ex31': > set(['Matlab']) > } > > -- 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

1 0

Re: [petsc-dev] Regression tests
by Jed Brown 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 2:17 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > You can tell from the primary key what it is. If the primary key is wrong, > it does not help you in your scenario as it could be > misspelled, or intended to be put in another directory. This is dubious at > best. > I don't need the primary key to be "right" to have good diagnostics, I just need to know that the Test() declaration (which executes code at the time the test is created) is inconsistent. My error message tells you the line that is bad. This is important. > We should have a discussion about whether we want to support this after > 3.3. > > What's the problem? Is builder.py having trouble figuring out how to link PETSc in general? Maybe it should use "make getlinklibs". ;-D Note that people occasionally ask for minimal builds for low-level functionality. Barry was even asking if it would be feasible to have a way to build only some KSPs, PCs, and matrix formats. I like that the option keeps us honest. > > No no. Your original make log is in PETSC_ARCH/conf/make.log. It should > never be corrupted. You > remove the link at make.log.bkp. > Well, that's an interesting (and confusing) idea for how it *could* work some day, but it's not how it currently works. > > > Same way we do in the makefiles now. It has an attribute "complex", > "superlu", etc. > So what you're saying is that your system could be extended to do this? I'm not disagreeing, but I think my suggestion is more maintainable and extensible. As I said in my first reply, the differences are mostly cosmetic, but I think there is good reason to prefer the form I suggest. The important thing in either case is to have a database of tests so we can program behavior. > Some have these. Held separately? regressionRequirements = {'src/vec/vec/examples/tests/ex31': set(['Matlab']) }

1 0

Re: [petsc-dev] Regression tests
by Matthew Knepley 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 1:52 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Thu, Jul 26, 2012 at 1:30 PM, Matthew Knepley <knepley(a)gmail.com>wrote: > >> On Thu, Jul 26, 2012 at 12:21 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >> >>> Builder does some of this, but I think not all, and I don't think it's >>> as convenient. The differences are partly syntactic. First, to add a test, >>> you have to add lines to a single global file (currently 1500 lines). By >>> creating the dictionary globally, we can't do consistency checks when the >>> test is declared, instead you only do it later once you have lost line >>> number information. You also can't build in the source directory, or >>> anything similar, which makes it hard for a user to split an example out >>> into their own toy project. Since you mess around with stdout, we are >>> losing warning messages (including color) and lose some Emacs M-x compile >>> convenience. (this can be fixed easily enough). >>> >> >> 1) I am fine with changing where the options come from, meaning if we >> want to also check for an import somewhere. Personally, I think >> its easier to maintain a central database than a distributed >> database. I would only suggest a distributed database for scalability, which >> we do not need. >> >> 2) I take your point about users adding tests (extensibility), which is >> why I would be fine with checking for an import >> >> 3) I have no idea what you mean about consistency checks >> > > Suppose the user misspells a file name or dict key, or they forget a > mandatory key. With a dict, all you can do is spit out the entry that you > think is corrupt and the user is on their own to figure out where the > declaration is in the file. With my model, you immediately get the file and > line number where the invalid record was created. With separate files, we > can also get more context-sensitive behavior to avoid repeating ourselves > so much. > You can tell from the primary key what it is. If the primary key is wrong, it does not help you in your scenario as it could be misspelled, or intended to be put in another directory. This is dubious at best. > >> 4) You can run builder on source anywhere. This is how I check the crazy >> things people send us. >> >> >>> Note that my suggestion does not _prevent_ using a global script, but it >>> localizes the declaration and would make it possible to run locally. >>> >>> On Thu, Jul 26, 2012 at 11:37 AM, Matthew Knepley <knepley(a)gmail.com>wrote: >>> >>>> ./test.py build ex19 >>>>> >>>> >>> $ config/builder2.py buildExample src/snes/examples/tutorials/ex19.c >>> Namespace(files=['src/snes/examples/tutorials/ex19.c'], func=<function >>> buildExample at 0x1fa56e0>) >>> Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >>> ERROR IN LINK ****************************** >>> >>> /usr/bin/ld: cannot find -lpetsc >>> >>> collect2: error: ld returned 1 exit >>> status >>> >>> (maybe it doesn't work --with-single-library=0) >>> >> >> It does not. I don't see a reason to support this. If its does, it is >> accidental. >> > > It's still a supported option in PETSc. I use it in my default PETSC_ARCH > because (a) link is one second faster and (b) it keeps us honest about > dependencies. > We should have a discussion about whether we want to support this after 3.3. > >> >>> $ PETSC_ARCH=mpich-singlelib config/builder2.py buildExample >>> src/snes/examples/tutorials/ex19.c >>> Namespace(files=['src/snes/examples/tutorials/ex19.c'], func=<function >>> buildExample at 0x25dd6e0>) >>> Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >>> >>> (hmm, where is the executable anyway) >>> >>> $ ls -ltr | tail -3 >>> lrwxrwxrwx 1 jed users 35 Jul 26 11:57 make.log.bkp -> >>> /home/jed/petsc/mpich/conf/make.log >>> lrwxrwxrwx 1 jed users 45 Jul 26 11:58 make.log -> >>> /home/jed/petsc/mpich-singlelib/conf/make.log >>> -rw-r--r-- 1 jed users 5271714 Jul 26 11:58 RDict.log >>> >>> (oh cool, it overwrote my library build with the make.log from this >>> example) >>> >> >> It shouldn't. It should move make.log to make.log.bkp first. There must >> be a bug. >> > > So the second time I run it, the original make.log is gone. Not better. > No no. Your original make log is in PETSC_ARCH/conf/make.log. It should never be corrupted. You remove the link at make.log.bkp. > >> >>> $ cat make.log >>> Loaded configure to cache: size 298004 >>> Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >>> Compiling C files >>> ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >>> Pushing language C >>> /opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include >>> -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include >>> -I/home/jed/usr/elemental-mpich/include -I/usr/include >>> -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >>> -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= >>> /home/jed/petsc/src/snes/examples/tutorials/ex19.c >>> sh: /opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include >>> -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include >>> -I/home/jed/usr/elemental-mpich/include -I/usr/include >>> -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >>> -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= >>> /home/jed/petsc/src/snes/examples/tutorials/ex19.c >>> Executing: /opt/mpich2/bin/mpicc -c >>> -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/petsc/include >>> -I/home/jed/petsc/mpich-singlelib/include >>> -I/home/jed/usr/elemental-mpich/include -I/usr/include >>> -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >>> -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= >>> /home/jed/petsc/src/snes/examples/tutorials/ex19.c >>> sh: >>> Popping language C >>> Moving ex19.o to >>> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o >>> Moving ex19.d to >>> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.d >>> Linking object ['/home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o'] >>> into /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 >>> Pushing language C >>> Pushing language C >>> Popping language C >>> Pushing language CUDA >>> Popping language CUDA >>> Pushing language Cxx >>> Popping language Cxx >>> Pushing language FC >>> Popping language FC >>> Pushing language C >>> Popping language C >>> sh: /opt/mpich2/bin/mpicc -o >>> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 -fPIC -Wall >>> -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline >>> -O0 /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o >>> -L/home/jed/petsc/mpich-singlelib/lib -lpetsc >>> -Wl,-rpath,/home/jed/petsc/mpich-singlelib/lib >>> -L/home/jed/petsc/mpich-singlelib/lib -ltriangle -lX11 -lchaco -lparmetis >>> -lmetis -Wl,-rpath,/home/jed/usr/elemental-mpich/lib >>> -L/home/jed/usr/elemental-mpich/lib -lelemental -lplcg -lpmrrr -lamspub >>> -lml -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >>> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >>> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -lmpichcxx -lstdc++ -lpthread >>> -lblacs -lHYPRE -lmpichcxx -lstdc++ -Wl,-rpath,/usr/lib -L/usr/lib >>> -lcholmod -lamd -lcolamd -lcamd -lccolamd -lumfpack -lcholmod -lcamd >>> -lccolamd -lcolamd -lamd -llapack -lblas -lm -L/usr/local/cuda/lib >>> -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >>> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >>> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -ldl >>> -Wl,-rpath,/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt -lgcc_s -ldl >>> Executing: /opt/mpich2/bin/mpicc -o >>> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 -fPIC -Wall >>> -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline >>> -O0 /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o >>> -L/home/jed/petsc/mpich-singlelib/lib -lpetsc >>> -Wl,-rpath,/home/jed/petsc/mpich-singlelib/lib >>> -L/home/jed/petsc/mpich-singlelib/lib -ltriangle -lX11 -lchaco -lparmetis >>> -lmetis -Wl,-rpath,/home/jed/usr/elemental-mpich/lib >>> -L/home/jed/usr/elemental-mpich/lib -lelemental -lplcg -lpmrrr -lamspub >>> -lml -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >>> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >>> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -lmpichcxx -lstdc++ -lpthread >>> -lblacs -lHYPRE -lmpichcxx -lstdc++ -Wl,-rpath,/usr/lib -L/usr/lib >>> -lcholmod -lamd -lcolamd -lcamd -lccolamd -lumfpack -lcholmod -lcamd >>> -lccolamd -lcolamd -lamd -llapack -lblas -lm -L/usr/local/cuda/lib >>> -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >>> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >>> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -ldl >>> -Wl,-rpath,/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt -lgcc_s -ldl >>> sh: >>> Popping language C >>> >>> (the above output loses warnings) >>> >> >> Bug. >> >> >>> $ mpich-singlelib/lib/ex19-obj/ex19 -happy-running >>> >>> >>>> >>>>> ./test.py check ex19_fas >>>>> >>>> >>> $ PETSC_ARCH=mpich-singlelib config/builder2.py check --testnum 5 >>> src/snes/examples/tutorials/ex19.c >>> Namespace(args=[], files=['src/snes/examples/tutorials/ex19.c'], >>> func=<function check at 0xfe17d0>, retain=False, testnum=5) >>> All tests pass >>> >>> (edit file, insert syntax error, re-run) >>> >>> [same output as above] >>> >>> >>>>> ./test.py check ex19_\* # run all the ex19 tests >>>>> >>>>> ./test.py check -n 16 --if '(X || Fortran) && !Complex' >>>>> >>>> >>> How? >>> >> >> >> Internally it knows all these predicates like num processes, Fortran and >> complex. >> > > It knows Fortran only in that the source file is Fortran. How does it know > whether an example supports complex or whether a given run uses SuperLU, > etc? > Same way we do in the makefiles now. It has an attribute "complex", "superlu", etc. > There is no command line syntax for it. I did >> not think there was for make either. >> > > It's manual through TESTEXAMPLES_SUPERLU, etc. > > >> You can do that from the run parameters at the op of builder.py. >> > > I don't think so. I think you have to add another dict key to your example > declarations. > Some have these. 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

1 0

Re: [petsc-dev] Regression tests
by Jed Brown 26 Jul '12

26 Jul '12

On Thu, Jul 26, 2012 at 1:30 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Thu, Jul 26, 2012 at 12:21 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > >> Builder does some of this, but I think not all, and I don't think it's as >> convenient. The differences are partly syntactic. First, to add a test, you >> have to add lines to a single global file (currently 1500 lines). By >> creating the dictionary globally, we can't do consistency checks when the >> test is declared, instead you only do it later once you have lost line >> number information. You also can't build in the source directory, or >> anything similar, which makes it hard for a user to split an example out >> into their own toy project. Since you mess around with stdout, we are >> losing warning messages (including color) and lose some Emacs M-x compile >> convenience. (this can be fixed easily enough). >> > > 1) I am fine with changing where the options come from, meaning if we want > to also check for an import somewhere. Personally, I think > its easier to maintain a central database than a distributed database. > I would only suggest a distributed database for scalability, which > we do not need. > > 2) I take your point about users adding tests (extensibility), which is > why I would be fine with checking for an import > > 3) I have no idea what you mean about consistency checks > Suppose the user misspells a file name or dict key, or they forget a mandatory key. With a dict, all you can do is spit out the entry that you think is corrupt and the user is on their own to figure out where the declaration is in the file. With my model, you immediately get the file and line number where the invalid record was created. With separate files, we can also get more context-sensitive behavior to avoid repeating ourselves so much. > > 4) You can run builder on source anywhere. This is how I check the crazy > things people send us. > > >> Note that my suggestion does not _prevent_ using a global script, but it >> localizes the declaration and would make it possible to run locally. >> >> On Thu, Jul 26, 2012 at 11:37 AM, Matthew Knepley <knepley(a)gmail.com>wrote: >> >>> ./test.py build ex19 >>>> >>> >> $ config/builder2.py buildExample src/snes/examples/tutorials/ex19.c >> Namespace(files=['src/snes/examples/tutorials/ex19.c'], func=<function >> buildExample at 0x1fa56e0>) >> Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >> ERROR IN LINK ****************************** >> >> /usr/bin/ld: cannot find -lpetsc >> >> collect2: error: ld returned 1 exit >> status >> >> (maybe it doesn't work --with-single-library=0) >> > > It does not. I don't see a reason to support this. If its does, it is > accidental. > It's still a supported option in PETSc. I use it in my default PETSC_ARCH because (a) link is one second faster and (b) it keeps us honest about dependencies. > > >> $ PETSC_ARCH=mpich-singlelib config/builder2.py buildExample >> src/snes/examples/tutorials/ex19.c >> Namespace(files=['src/snes/examples/tutorials/ex19.c'], func=<function >> buildExample at 0x25dd6e0>) >> Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >> >> (hmm, where is the executable anyway) >> >> $ ls -ltr | tail -3 >> lrwxrwxrwx 1 jed users 35 Jul 26 11:57 make.log.bkp -> >> /home/jed/petsc/mpich/conf/make.log >> lrwxrwxrwx 1 jed users 45 Jul 26 11:58 make.log -> >> /home/jed/petsc/mpich-singlelib/conf/make.log >> -rw-r--r-- 1 jed users 5271714 Jul 26 11:58 RDict.log >> >> (oh cool, it overwrote my library build with the make.log from this >> example) >> > > It shouldn't. It should move make.log to make.log.bkp first. There must be > a bug. > So the second time I run it, the original make.log is gone. Not better. > > >> $ cat make.log >> Loaded configure to cache: size 298004 >> Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >> Compiling C files ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c'] >> Pushing language C >> /opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include >> -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include >> -I/home/jed/usr/elemental-mpich/include -I/usr/include >> -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >> -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= >> /home/jed/petsc/src/snes/examples/tutorials/ex19.c >> sh: /opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include >> -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include >> -I/home/jed/usr/elemental-mpich/include -I/usr/include >> -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >> -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= >> /home/jed/petsc/src/snes/examples/tutorials/ex19.c >> Executing: /opt/mpich2/bin/mpicc -c >> -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/petsc/include >> -I/home/jed/petsc/mpich-singlelib/include >> -I/home/jed/usr/elemental-mpich/include -I/usr/include >> -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing >> -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= >> /home/jed/petsc/src/snes/examples/tutorials/ex19.c >> sh: >> Popping language C >> Moving ex19.o to >> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o >> Moving ex19.d to >> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.d >> Linking object ['/home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o'] >> into /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 >> Pushing language C >> Pushing language C >> Popping language C >> Pushing language CUDA >> Popping language CUDA >> Pushing language Cxx >> Popping language Cxx >> Pushing language FC >> Popping language FC >> Pushing language C >> Popping language C >> sh: /opt/mpich2/bin/mpicc -o >> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 -fPIC -Wall >> -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline >> -O0 /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o >> -L/home/jed/petsc/mpich-singlelib/lib -lpetsc >> -Wl,-rpath,/home/jed/petsc/mpich-singlelib/lib >> -L/home/jed/petsc/mpich-singlelib/lib -ltriangle -lX11 -lchaco -lparmetis >> -lmetis -Wl,-rpath,/home/jed/usr/elemental-mpich/lib >> -L/home/jed/usr/elemental-mpich/lib -lelemental -lplcg -lpmrrr -lamspub >> -lml -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -lmpichcxx -lstdc++ -lpthread >> -lblacs -lHYPRE -lmpichcxx -lstdc++ -Wl,-rpath,/usr/lib -L/usr/lib >> -lcholmod -lamd -lcolamd -lcamd -lccolamd -lumfpack -lcholmod -lcamd >> -lccolamd -lcolamd -lamd -llapack -lblas -lm -L/usr/local/cuda/lib >> -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -ldl >> -Wl,-rpath,/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt -lgcc_s -ldl >> Executing: /opt/mpich2/bin/mpicc -o >> /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 -fPIC -Wall >> -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline >> -O0 /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o >> -L/home/jed/petsc/mpich-singlelib/lib -lpetsc >> -Wl,-rpath,/home/jed/petsc/mpich-singlelib/lib >> -L/home/jed/petsc/mpich-singlelib/lib -ltriangle -lX11 -lchaco -lparmetis >> -lmetis -Wl,-rpath,/home/jed/usr/elemental-mpich/lib >> -L/home/jed/usr/elemental-mpich/lib -lelemental -lplcg -lpmrrr -lamspub >> -lml -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -lmpichcxx -lstdc++ -lpthread >> -lblacs -lHYPRE -lmpichcxx -lstdc++ -Wl,-rpath,/usr/lib -L/usr/lib >> -lcholmod -lamd -lcolamd -lcamd -lccolamd -lumfpack -lcholmod -lcamd >> -lccolamd -lcolamd -lamd -llapack -lblas -lm -L/usr/local/cuda/lib >> -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib >> -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 >> -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -ldl >> -Wl,-rpath,/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt -lgcc_s -ldl >> sh: >> Popping language C >> >> (the above output loses warnings) >> > > Bug. > > >> $ mpich-singlelib/lib/ex19-obj/ex19 -happy-running >> >> >>> >>>> ./test.py check ex19_fas >>>> >>> >> $ PETSC_ARCH=mpich-singlelib config/builder2.py check --testnum 5 >> src/snes/examples/tutorials/ex19.c >> Namespace(args=[], files=['src/snes/examples/tutorials/ex19.c'], >> func=<function check at 0xfe17d0>, retain=False, testnum=5) >> All tests pass >> >> (edit file, insert syntax error, re-run) >> >> [same output as above] >> >> >>>> ./test.py check ex19_\* # run all the ex19 tests >>>> >>>> ./test.py check -n 16 --if '(X || Fortran) && !Complex' >>>> >>> >> How? >> > > > Internally it knows all these predicates like num processes, Fortran and > complex. > It knows Fortran only in that the source file is Fortran. How does it know whether an example supports complex or whether a given run uses SuperLU, etc? > There is no command line syntax for it. I did > not think there was for make either. > It's manual through TESTEXAMPLES_SUPERLU, etc. > You can do that from the run parameters at the op of builder.py. > I don't think so. I think you have to add another dict key to your example declarations.

1 0