March 2011 - petsc-dev - mailman3.cels.anl.gov

Help
by Matthew Knepley 25 Mar '11

25 Mar '11

Now you can print specific help sections: ./configure --help hypre mumps 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] Updated src/sys/examples/tutorials/ex5.c
by Jed Brown 25 Mar '11

25 Mar '11

On Thu, Mar 24, 2011 at 21:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Unless Jed figures out a way to do it the current model is that with quad > they are printed wrong and you need to manage their display yourself. So libquadmath introduces the Q type qualifier so you can use %Qe, %Qf, %Qg. Unfortunately libc is behind the times unless you have a bleeding-edge version (inconvenient without disrupting the rest of your system). To deal with not having a new enough libc, you can use quadmath_snprintf: char buf[256]; quadmath_snprintf(buf,sizeof buf,"%Qg",my_float128);

1 0

Re: [petsc-dev] Updated src/sys/examples/tutorials/ex5.c
by Richard Katz 25 Mar '11

25 Mar '11

> The order you call the register routines should not matter. Only the order they are listed in the struct matters. Did you get something breaking if you didn't call the register routines in order? Yes, originally I fixed the problem just by changing the order of the register calls. Bizarrely, I can't recreate the error now, regardless of the order of the entries in the struct or the order of the register calls. This goes for my test-code as well as src/sys/examples/tutorials/ex5.c I have pulled and recompiled petsc-dev since submitting that issue to petsc-maint Rich > > I know the ascii view prints "incorrect" values. This is a universal problem with working with quad precision. C provides no portable (or even nonportable) way of handling format statements for different precisions builds. > > Unless Jed figures out a way to do it the current model is that with quad they are printed wrong and you need to manage their display yourself. > > Barry > > I try to handle the problem with %G format that we manually map to different "standard" C formats, but quad doesn't have a "standard" C format that works. > > > On Mar 24, 2011, at 12:30 PM, Richard Katz wrote: > >> Attached is a diff file updating >> src/sys/examples/tutorials/ex5.c >> which is an example of PetscBag use. >> >> I've changed the order of the parameter registrations to put the Real values first, as required with quad precision. >> >> If you run the new version with quad precision, you'll see that when the bag is viewed to stdout, the Real numerical values are incorrectly displayed. >> >> Cheers >> Rich >> >> >> <ex5.diff> > ________________________________ Richard Foa Katz Dept Earth Sciences, Univ Oxford http://www.earth.ox.ac.uk/katz

1 0

Re: [petsc-dev] subrepositories
by Satish Balay 24 Mar '11

24 Mar '11

A few comments about the model and expectations [valid or invalid] [a] Barry's concers [latest buildsystem with latest petsc-dev] assumes no incompatible changes [to BuildSystem are pushed]. This assumtion is correct only if buildsystem chages are always done in sync with petsc-dev and always tested with petsc-dev - before pushed. In this case a single repo is the correct model. However Matt likes to keep BuildSystem separate to support potentially other projects. 2 cases here: [b] someone else [not using petsc] is making change to buildsystem and testing & commiting to BuildSystem. In this case - such changes can break petsc-dev - [so always latest changes as Barry would want- is the wrong thing here]. Here subrepo model [where Matt has a different master for BuildSystem and petsc-dev has its own subrep of buildsystem - and they get synced frequently] is appropriate. [c] Matt is the only person making fixes for the 'other projects' i.e all changes do get tested in petsc-dev context. In this again a single repo is the correct thing. The 'other project' users who need buildsystem [without petsc-dev] could get it with perhaps some auto-generated buildsystem-other repo - with perhaps some triggers [that does equivalent of 'bk csetprune' perhaps with hg convert'] Currently we are using [b] as the reason for split repo - but using the workflow from [c] - giving rise to expectations of [a] Satish On Thu, 24 Mar 2011, Barry Smith wrote: > My concern is simple. (1) Someone adds some fixes to BuildSystem, > commits and pushes. (2) Someones uses PETSc with the BuildSystem > subrepository does a pull in PETSc and NEVER gets the stuff that > was put into BuildSystem. Given this I don't care how great it is > that you can get consistent rollbacks and all kinds of good stuff > by having a subrepository, nor do I care how hard it would be to > get my model to work; this one flaw ruins all the great stuff you > do get. > On Mar 24, 2011, at 5:11 PM, Jed Brown wrote: > > To really have a single repository view without "redundant" > > commits to both BuildSystem and PETSc, and with some useful > > rollback semantics, you would have to really make one > > repository. As I understand it, Matt is rather opposed to directly > > importing BuildSystem into PETSc. I don't know how many people use > > BuildSystem without PETSc, there is certainly no > > backward-compatibility so it would be awfully hard to recommend.

1 0

Re: [petsc-dev] subrepositories
by Barry Smith 24 Mar '11

24 Mar '11

On Mar 24, 2011, at 6:47 PM, Sean Farley wrote: > My concern is simple. (1) Someone adds some fixes to BuildSystem, commits and pushes. (2) Someones uses PETSc with the BuildSystem subrepository does a pull in PETSc and NEVER gets the stuff that was put into BuildSystem. > > Huuuuuuuuuuh? How would they "NEVER" get the stuff put into BuildSystem? The solution would be to "cd into Buildsystem and do an 'hg pull' there." How is that any different from our current advice of "pull the newest BuildSystem changes?" Because you would always have to do both, pull in petsc-dev and pull in Buildsystem (to get all the things pushed into BuildSystem not from petsc-dev). No different than today. Barry > > Sean

1 0

Re: [petsc-dev] subrepositories
by Sean Farley 24 Mar '11

24 Mar '11

> > My concern is simple. (1) Someone adds some fixes to BuildSystem, commits > and pushes. (2) Someones uses PETSc with the BuildSystem subrepository does > a pull in PETSc and NEVER gets the stuff that was put into BuildSystem. Huuuuuuuuuuh? How would they "NEVER" get the stuff put into BuildSystem? The solution would be to "cd into Buildsystem and do an 'hg pull' there." How is that any different from our current advice of "pull the newest BuildSystem changes?" Sean

1 0

Re: [petsc-dev] subrepositories
by Jed Brown 24 Mar '11

24 Mar '11

On Fri, Mar 25, 2011 at 01:30, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > My concern is simple. (1) Someone adds some fixes to BuildSystem, commits > and pushes. (2) Someones uses PETSc with the BuildSystem subrepository does > a pull in PETSc and NEVER gets the stuff that was put into BuildSystem. > Given this I don't care how great it is that you can get consistent > rollbacks and all kinds of good stuff by having a subrepository, nor do I > care how hard it would be to get my model to work; this one flaw ruins all > the great stuff you do get. This scheme is necessarily more fragile, but I admit that it may be convenient the way we use BuildSystem (which is basically as a part of PETSc). Who ever commits to BuildSystem without PETSc around? (It looks like nobody according to the history.) Is there harm in just always committing from petsc root instead of from "inside" BuildSystem? Then you could just pretend that there was only one repository. Maybe even add a BuildSystem commit hook to prevent accidental committing from inside when it is being used as part of PETSc.

1 0

Re: [petsc-dev] subrepositories
by Barry Smith 24 Mar '11

24 Mar '11

My concern is simple. (1) Someone adds some fixes to BuildSystem, commits and pushes. (2) Someones uses PETSc with the BuildSystem subrepository does a pull in PETSc and NEVER gets the stuff that was put into BuildSystem. Given this I don't care how great it is that you can get consistent rollbacks and all kinds of good stuff by having a subrepository, nor do I care how hard it would be to get my model to work; this one flaw ruins all the great stuff you do get. Barry On Mar 24, 2011, at 5:11 PM, Jed Brown wrote: > On Fri, Mar 25, 2011 at 00:59, Satish Balay <balay(a)mcs.anl.gov> wrote: > I might be paraphrasing here - but Barry would like an 'equivalent' of > a single repo view [wrt commit, pull, push, location of invocation of hg] > > Here is the commit problem: > > If you commit from BuildSystem with PETSc not in the picture, then there is no way for the PETSc repository to automatically know that it should pull the most recent version. In order for PETSc to "know" which version of BuildSystem is associated with a given version of PETSc, it has to store the SHA1 somewhere. The implementation puts this in .hgsubstate. Of course, being a version control system, this file is versioned. When you commit to BuildSystem from inside PETSc, it updates this file and checks it into PETSc. This way, external commits to BuildSystem are not visible to PETSc and you can always "hg update" to an old version and know that the combination was actually tested (assuming the committed version was tested). If the PETSc repository did not store any .hgsubstate, there would be no way to keep track of which version of BuildSystem was used when a certain version of PETSc was tested. > > This is the closest thing to a single repository view that can actually be robust if BuildSystem is ever modified externally (otherwise comparing dates and hoping that everyone has a sufficiently calibrated clock and did not make any mistakes could be viable). To really have a single repository view without "redundant" commits to both BuildSystem and PETSc, and with some useful rollback semantics, you would have to really make one repository. As I understand it, Matt is rather opposed to directly importing BuildSystem into PETSc. I don't know how many people use BuildSystem without PETSc, there is certainly no backward-compatibility so it would be awfully hard to recommend.

1 0

Re: [petsc-dev] subrepositories
by Jed Brown 24 Mar '11

24 Mar '11

On Fri, Mar 25, 2011 at 00:59, Satish Balay <balay(a)mcs.anl.gov> wrote: > I might be paraphrasing here - but Barry would like an 'equivalent' of > a single repo view [wrt commit, pull, push, location of invocation of hg] > Here is the commit problem: If you commit from BuildSystem with PETSc not in the picture, then there is no way for the PETSc repository to automatically know that it should pull the most recent version. In order for PETSc to "know" which version of BuildSystem is associated with a given version of PETSc, it has to store the SHA1 somewhere. The implementation puts this in .hgsubstate. Of course, being a version control system, this file is versioned. When you commit to BuildSystem from inside PETSc, it updates this file and checks it into PETSc. This way, external commits to BuildSystem are not visible to PETSc and you can always "hg update" to an old version and know that the combination was actually tested (assuming the committed version was tested). If the PETSc repository did not store any .hgsubstate, there would be no way to keep track of which version of BuildSystem was used when a certain version of PETSc was tested. This is the closest thing to a single repository view that can actually be robust if BuildSystem is ever modified externally (otherwise comparing dates and hoping that everyone has a sufficiently calibrated clock and did not make any mistakes could be viable). To really have a single repository view without "redundant" commits to both BuildSystem and PETSc, and with some useful rollback semantics, you would have to really make one repository. As I understand it, Matt is rather opposed to directly importing BuildSystem into PETSc. I don't know how many people use BuildSystem without PETSc, there is certainly no backward-compatibility so it would be awfully hard to recommend.

1 0

Re: [petsc-dev] subrepositories
by Satish Balay 24 Mar '11

24 Mar '11

I might be paraphrasing here - but Barry would like an 'equivalent' of a single repo view [wrt commit, pull, push, location of invocation of hg] Satish On Fri, 25 Mar 2011, Jed Brown wrote: > Barry, could you explain what is so wrong about subrepos and what semantics > you desire? > > On Fri, Mar 25, 2011 at 00:02, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > Satish explained how hg sub repositories work. They are moronic, we don't > > want to use them. > > > > > > Is there any way with "triggers" or some other technique to rig it so if > > I do hg xxx in petsc-dev it automatically runs it also in BuildSystem. For > > example hg pull triggers a pull in both petsc-dev and BuildSystem? > > > > Barry > > > > >

1 0