May 2008 - petsc-dev - mailman3.cels.anl.gov

Couple of requests.
by Dave May 14 May '08

14 May '08

Hello, Could the follow items be added into petsc-dev please. 1) Object: PCMG If the MGType is multiplicative*, *could PCView_MG(), report the value of mg[0]->cyclesperpcapply (set by -pc_mg_multiplicative_cycle ) 2) Object: SNESPicard Could the lines /* Call general purpose update function */ if (snes->ops->update) { ierr = (*snes->ops->update)(snes, snes->iter);CHKERRQ(ierr); } be included within the Picarad iteration like it is in SNESTR and SNESLS? Thanks in advance. Cheers, Dave.

1 0

Re: Reporting cpu times to profile KSPSolve (and others)
by Barry Smith 12 May '08

12 May '08

Dave, At the moment we'll leave this as something the user can easily do by creating their own custom KSP/SNES monitors. Barry On May 9, 2008, at 1:09 AM, Dave May wrote: > Hey Matt, > All I want to be able to do is generate plots of |r|/|r0| vs cpu > time. I presumed that such information is commonly required when > profiling the performance of solvers, so I thought it might be > something you'd consider adding support for. > > Cheers, > Dave > > > On Fri, May 9, 2008 at 1:19 PM, Matthew Knepley <knepley(a)gmail.com> > wrote: > On Thu, May 8, 2008 at 10:09 PM, Dave May <dave.mayhem23(a)gmail.com> > wrote: > > Hey petsc folk, > > What is the best way to obtain timing information to profile the > > performance > > of KSPSolve (or SNESSolve)? Currently I have written some specific > KSP > > monitors, > > but it I think it would be useful to have access to this > information all the > > time without > > having to go through the monitor. It seems like each object > should know how > > to time > > some of its operations. > > > > It would be very useful to have functions such as > > KSPGetCPUTime(KSP ksp,PetscLogDouble *time) > > to report the total solution time required by the KSPSolve() and > > KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na) > > which is like KSPGetResidualHistory() but returns the accumulated > cpu time > > for each > > iterate > > > > It would also be useful to have a default KSP monitor which could > report the > > time per iterate > > or accumulate time. For example something like > > 40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03 > > 41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02 > > > > Is there a better approach to what I've been doing and are there > plans to > > add any > > additional features to help profile individual operations on each > object? > > Maybe you could motivate it by giving a use case? So far, I have > never needed > anything but the KSPSolve() event and stages to separately aggregate > different > types of solves. > > Matt > > > Cheers, > > Dave > -- > 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: initialization of XXX_COOKIE in C source files
by Barry Smith 11 May '08

11 May '08

> > Now I am a little worried. Don't some compilers dislike > unintialized, file scope > variables in shared libraries (I am thinking AIX). > > Matt If the need arises I will put all the = 0 back in. We never got AIX shared libraries to work anyways :-) Barry On May 11, 2008, at 7:07 AM, Matthew Knepley wrote: > On Sat, May 10, 2008 at 7:49 PM, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: >> >> On May 10, 2008, at 6:08 PM, Lisandro Dalcin wrote: >> >> >>> I've noticed that in 2.3.3 all PETSc cookies are initialized to zero >>> in sources, but in DEV they are not initialized. What's the reason >>> of >>> >> ^^^^^^^^^^^^^^^^ >> You are quick, I just pushed the >> change >> last night. >> >> The reason why they where all initialized to zero was because >> - a very long time ago all the cookies where hardwired numbers that >> we >> chose for each new class >> - then we added the ability to request a cookie, but still support >> the old >> hardwired version. Passing in a pointer to a zero value meant you >> were >> requesting one, passing in a pointer to a nonzero one meant that the >> cookie >> had a hardwired value. >> - over time all the hardwired ones were unhardwired, but the >> convention >> of initializing them to zero before hand was never changed. >> >> There was some convoluted logic for why the PetscEvent values were >> all initialized to zero also. When fixing up the events I also >> fixed the >> cookies >> The reason is Barry's rule # 54, "nothing should be done in a code >> without >> a reason, otherwise it will be confusing to others looking at the >> code." >> For example, >> even now, whenever anybody made some new events they initialized them >> to zero, why? Not because they need to be, but simply because they >> were in >> code the developer copied from. >> >> Were you taking advantage of their initialization to zero? If so, >> rather >> than depending >> on each cookie being initialized to zero I would suggest handling >> this type >> of "check if initialized" stuff at a package by package level or >> library by >> library level. >> Please let me know what you need. > > Now I am a little worried. Don't some compilers dislike > unintialized, file scope > variables in shared libraries (I am thinking AIX). > > Matt > >> Barry >> >> >> >> >>> >>> this change? >>> >>> -- >>> >>> Lisandro Dalcï¿½n >>> --------------- >>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >>> (CIMEC) >>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >>> (INTEC) >>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>> Tel/Fax: +54-(0)342-451.1594 >>> >>> >> >> > > > > -- > 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: initialization of XXX_COOKIE in C source files
by Matthew Knepley 11 May '08

11 May '08

On Sat, May 10, 2008 at 7:49 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On May 10, 2008, at 6:08 PM, Lisandro Dalcin wrote: > > > > I've noticed that in 2.3.3 all PETSc cookies are initialized to zero > > in sources, but in DEV they are not initialized. What's the reason of > > > ^^^^^^^^^^^^^^^^ > You are quick, I just pushed the change > last night. > > The reason why they where all initialized to zero was because > - a very long time ago all the cookies where hardwired numbers that we > chose for each new class > - then we added the ability to request a cookie, but still support the old > hardwired version. Passing in a pointer to a zero value meant you were > requesting one, passing in a pointer to a nonzero one meant that the > cookie > had a hardwired value. > - over time all the hardwired ones were unhardwired, but the convention > of initializing them to zero before hand was never changed. > > There was some convoluted logic for why the PetscEvent values were > all initialized to zero also. When fixing up the events I also fixed the > cookies > The reason is Barry's rule # 54, "nothing should be done in a code without > a reason, otherwise it will be confusing to others looking at the code." > For example, > even now, whenever anybody made some new events they initialized them > to zero, why? Not because they need to be, but simply because they were in > code the developer copied from. > > Were you taking advantage of their initialization to zero? If so, rather > than depending > on each cookie being initialized to zero I would suggest handling this type > of "check if initialized" stuff at a package by package level or library by > library level. > Please let me know what you need. Now I am a little worried. Don't some compilers dislike unintialized, file scope variables in shared libraries (I am thinking AIX). Matt > Barry > > > > > > > > this change? > > > > -- > > > > Lisandro Dalcï¿½n > > --------------- > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > Tel/Fax: +54-(0)342-451.1594 > > > > > > -- 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: initialization of XXX_COOKIE in C source files
by Barry Smith 10 May '08

10 May '08

On May 10, 2008, at 6:08 PM, Lisandro Dalcin wrote: > I've noticed that in 2.3.3 all PETSc cookies are initialized to zero > in sources, but in DEV they are not initialized. What's the reason of ^^^^^^^^^^^^^^^^ You are quick, I just pushed the change last night. The reason why they where all initialized to zero was because - a very long time ago all the cookies where hardwired numbers that we chose for each new class - then we added the ability to request a cookie, but still support the old hardwired version. Passing in a pointer to a zero value meant you were requesting one, passing in a pointer to a nonzero one meant that the cookie had a hardwired value. - over time all the hardwired ones were unhardwired, but the convention of initializing them to zero before hand was never changed. There was some convoluted logic for why the PetscEvent values were all initialized to zero also. When fixing up the events I also fixed the cookies The reason is Barry's rule # 54, "nothing should be done in a code without a reason, otherwise it will be confusing to others looking at the code." For example, even now, whenever anybody made some new events they initialized them to zero, why? Not because they need to be, but simply because they were in code the developer copied from. Were you taking advantage of their initialization to zero? If so, rather than depending on each cookie being initialized to zero I would suggest handling this type of "check if initialized" stuff at a package by package level or library by library level. Please let me know what you need. Barry > > this change? > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: initialization of XXX_COOKIE in C source files
by Matthew Knepley 10 May '08

10 May '08

2008/5/10 Lisandro Dalcin <dalcinl(a)gmail.com>: > I've noticed that in 2.3.3 all PETSc cookies are initialized to zero > in sources, but in DEV they are not initialized. What's the reason of > this change? Not sure, but I would guess some compiler probably did not like it. Matt > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > -- 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

initialization of XXX_COOKIE in C source files
by Lisandro Dalcin 10 May '08

10 May '08

I've noticed that in 2.3.3 all PETSc cookies are initialized to zero in sources, but in DEV they are not initialized. What's the reason of this change? -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

changes to petsc-dev may require you to update your source, previously Re: How come it is PetscEvent but all the routines that act on it are PetscLogEventXXXX()?
by Barry Smith 09 May '08

09 May '08

I have made the following changes to Petsc-dev that may require you to update your source code: <ul> <li>The int stage used in the PetscLogStageXXX() routines is now a PetscLogStage</li> <li>PetscEvent is now PetscLogEvent</li> <li>PetscLogEventRegister() and PetscLogStageRegister() now return the result in the final argument instead of the first</li> <li>PetscLogClassRegister() is changed to PetscCookieRegister() and returns the cookie in the final argument, not the first</li> </ul> Please let petsc-maint know immediately if you find a problem, and feel free to curse me out for the changes Barry I realized that I was the one who made the initial mistake. I introduced PetscEvent because I did not like the int that make was using for events. I should have, at that time, introduced PetscLogEvent, not PetscEvent. I also didn't fix the stage like I should have. On May 7, 2008, at 10:48 AM, Richard Tran Mills wrote: > Barry, > > I like the the suggestion to change PetscLogEvent* to PetscEvent*, > but to be consistent with naming then I think we would also need to > change PetscLogStage* to PetscStage*, etc. > > Just my 0.5 cents. > > --Richard > > Barry Smith wrote: >> On May 5, 2008, at 7:39 PM, Matthew Knepley wrote: >>> Actually, I would argue that these methods do not actually act on >>> PetscEvent >>> at all (which is just an integer), but rather on a PetscLog. That >>> is why I named >>> them that way. >> The namage has to be consistent with any normal Joe's thinking >> about the usage, >> not based on some implementation issue that only you know about. >> Names are for >> users, not for the guru developers. Guru developers could name >> their variables and >> functions a1 to a2303 and have no problem maintaining the code. >> I think the macro names should be changed to PetscEventBegin.... not >> PetscLogEventBegin.... based on the policy in PETSc that "methods" >> on "objects" >> start with the name of the objects: e.g. MatMult(Mat,....) The user >> shouldn't know >> or care that PetscEvent is an int and not a PetscEvent or >> PetscLogEvent object. >> Barry >> We could instead change PetscEvent to PetscLogEvent but I think >> PetscEvent >> is clear enough without the Log in it. >>> >>> >>> Matt >>> >>> On Sat, May 3, 2008 at 6:26 PM, Barry Smith <bsmith(a)mcs.anl.gov> >>> wrote: >>>> >>>> Doesn't seem right. >>>> >>>> Barry >>>> >>>> >>> >>> >>> >>> -- >>> 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 >>> > > > -- > Richard Tran Mills, Ph.D. | E-mail: rmills(a)climate.ornl.gov > Computational Scientist | Phone: (865) 241-3198 > Computational Earth Sciences Group | Fax: (865) 574-0405 > Oak Ridge National Laboratory | http://climate.ornl.gov/~rmills >

1 0

Re: Reporting cpu times to profile KSPSolve (and others)
by Matthew Knepley 09 May '08

09 May '08

On Fri, May 9, 2008 at 1:09 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > Hey Matt, > All I want to be able to do is generate plots of |r|/|r0| vs cpu time. I > presumed that such information is commonly required when profiling the > performance of solvers, so I thought it might be something you'd consider > adding support for. Here is what I do right now: You could use any event (like KSPSolve) ALE::LogStagePush(stage); ierr = PetscLogEventBegin(restrictEvent,0,0,0,0); <Do stuff> ierr = PetscLogEventEnd(restrictEvent,0,0,0,0); ALE::LogStagePop(stage); StageLog stageLog; EventPerfLog eventLog; ierr = PetscLogGetStageLog(&stageLog); ierr = StageLogGetEventPerfLog(stageLog, stage, &eventLog); EventPerfInfo eventInfo = eventLog->eventInfo[restrictEvent]; CPPUNIT_ASSERT_EQUAL(eventInfo.count, 1); CPPUNIT_ASSERT_EQUAL((int) eventInfo.flops, 0); if (this->_debug) { ierr = PetscPrintf(this->_section->comm(), " Average time per restrictPoint: %gs\n", eventInfo.time/(numPoints*this->_iters)); } CPPUNIT_ASSERT((eventInfo.time < maxTimePerRestrict * numPoints * this->_iters)); I hesitate to add the history thing because it seems to put redundant info into the KSP, and it woul dbe meaningless if logging is turned off. Maybe there should be a history mechanism in the logging. Right now it is completely based upon aggregation. Matt > Cheers, > Dave > > On Fri, May 9, 2008 at 1:19 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > > > > > > > > On Thu, May 8, 2008 at 10:09 PM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > > Hey petsc folk, > > > What is the best way to obtain timing information to profile the > > > performance > > > of KSPSolve (or SNESSolve)? Currently I have written some specific KSP > > > monitors, > > > but it I think it would be useful to have access to this information all > the > > > time without > > > having to go through the monitor. It seems like each object should know > how > > > to time > > > some of its operations. > > > > > > It would be very useful to have functions such as > > > KSPGetCPUTime(KSP ksp,PetscLogDouble *time) > > > to report the total solution time required by the KSPSolve() and > > > KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na) > > > which is like KSPGetResidualHistory() but returns the accumulated cpu > time > > > for each > > > iterate > > > > > > It would also be useful to have a default KSP monitor which could report > the > > > time per iterate > > > or accumulate time. For example something like > > > 40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03 > > > 41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02 > > > > > > Is there a better approach to what I've been doing and are there plans > to > > > add any > > > additional features to help profile individual operations on each > object? > > > > Maybe you could motivate it by giving a use case? So far, I have never > needed > > anything but the KSPSolve() event and stages to separately aggregate > different > > types of solves. > > > > Matt > > > > > Cheers, > > > Dave > > -- > > 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

1 0

Re: Reporting cpu times to profile KSPSolve (and others)
by Dave May 09 May '08

09 May '08

Hey Matt, All I want to be able to do is generate plots of |r|/|r0| vs cpu time. I presumed that such information is commonly required when profiling the performance of solvers, so I thought it might be something you'd consider adding support for. Cheers, Dave On Fri, May 9, 2008 at 1:19 PM, Matthew Knepley <knepley(a)gmail.com> wrote: > On Thu, May 8, 2008 at 10:09 PM, Dave May <dave.mayhem23(a)gmail.com> wrote: > > Hey petsc folk, > > What is the best way to obtain timing information to profile the > > performance > > of KSPSolve (or SNESSolve)? Currently I have written some specific KSP > > monitors, > > but it I think it would be useful to have access to this information all > the > > time without > > having to go through the monitor. It seems like each object should know > how > > to time > > some of its operations. > > > > It would be very useful to have functions such as > > KSPGetCPUTime(KSP ksp,PetscLogDouble *time) > > to report the total solution time required by the KSPSolve() and > > KSPGetCPUTimeHistory(KSP ksp,PetscLogDouble *time[],PetscInt *na) > > which is like KSPGetResidualHistory() but returns the accumulated cpu > time > > for each > > iterate > > > > It would also be useful to have a default KSP monitor which could report > the > > time per iterate > > or accumulate time. For example something like > > 40 KSP Residual norm 1.519638506430e-01 Time 1.000000000000e-03 > > 41 KSP Residual norm 1.510346481853e-01 Time 1.510346481853e-02 > > > > Is there a better approach to what I've been doing and are there plans to > > add any > > additional features to help profile individual operations on each object? > > Maybe you could motivate it by giving a use case? So far, I have never > needed > anything but the KSPSolve() event and stages to separately aggregate > different > types of solves. > > Matt > > > Cheers, > > Dave > -- > 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