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

Re: adding better support for petsc4py in core PETSc
by Barry Smith 30 May '08

30 May '08

Lisandro, Go ahead and add it. Barry On May 30, 2008, at 10:55 AM, Lisandro Dalcin wrote: > I want to ask all you for adding better support for petsc4py in core > PETSc. > > All what I need to to add to opaque pointers in the base PetscObject > structure, like this > > void *pycontext > PetscErrorcode (*pydestroy)(void*) > > As you see, this will not make core PETSc depend on Python in any way. > Additionally, the extra memory overhead is small, just to pointers.. > > My intention is to put a Python dictionary in the pycontext pointer, > and call pydestroy function pointer (I'll set if when needed) at the > time PetscHeaderDestroy is called. > > Such a feature is currently being emulated with PetscContainer and > PetscObjectCompose, but I would really like to cleanup this hackery > and implement things the right way. > > I've started to migrate my SWIG-based wrappers to use Cython. This is > preliminar and not yet ready for public consumption, but at firts I > anticipate this approach if far easier to understand, extend, and > maintain than the previous one. In the near future, making petsc4py > interoperate with C/C++/Fortran user code will be possible and easy. > > For example, I saw the new Picard implementation in SNES. Such a > feature could be implemented with a few lines of pure Python code, no > point to have to write a full SNES type implementation (unless it is > really needed). Just write in Python a custom nonlinear solver, and > now run your C/C++/Fortran code with an special option in the command > line, and PETSc picks-up and used the Python code implementing your > solver. > > > -- > 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

adding better support for petsc4py in core PETSc
by Lisandro Dalcin 30 May '08

30 May '08

I want to ask all you for adding better support for petsc4py in core PETSc. All what I need to to add to opaque pointers in the base PetscObject structure, like this void *pycontext PetscErrorcode (*pydestroy)(void*) As you see, this will not make core PETSc depend on Python in any way. Additionally, the extra memory overhead is small, just to pointers.. My intention is to put a Python dictionary in the pycontext pointer, and call pydestroy function pointer (I'll set if when needed) at the time PetscHeaderDestroy is called. Such a feature is currently being emulated with PetscContainer and PetscObjectCompose, but I would really like to cleanup this hackery and implement things the right way. I've started to migrate my SWIG-based wrappers to use Cython. This is preliminar and not yet ready for public consumption, but at firts I anticipate this approach if far easier to understand, extend, and maintain than the previous one. In the near future, making petsc4py interoperate with C/C++/Fortran user code will be possible and easy. For example, I saw the new Picard implementation in SNES. Such a feature could be implemented with a few lines of pure Python code, no point to have to write a full SNES type implementation (unless it is really needed). Just write in Python a custom nonlinear solver, and now run your C/C++/Fortran code with an special option in the command line, and PETSc picks-up and used the Python code implementing your solver. -- 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: HTML editor sucks
by Lisandro Dalcin 23 May '08

23 May '08

On 5/23/08, Satish Balay <balay(a)mcs.anl.gov> wrote: > I guess the problem is - each of us use different editors. > > I guess we have to converge to a single editor to avoid this > issue. Also I believe we have to redesign PETSc web page to make it > more attractive :) [with Beth - MCS/web developer's help] Have you ever considered the option of moving from maintaining static html files, to something more advances, like a 'dynamic' webserver (ala, Zope, Plone, Wiki, or something like that?) Other way would be to move to something like reStructuredText, perhaps also using (and adapting is needed) the infraestruture (a tool called Sphinx) that supports the documentation system for Python 2.6 and 3.0. This way, actual sources are plain, easy to edit and follow text files with wiki-like markup, and the output are still plain html files you can put in some dir and served with Apache. If you ever want to take a look at the later option, Brian Granger (IPython developer) started a few days ago the process of converting some docs for mpi4py yo the reStructuredText+Sphinx . So I have a working example of sources that are be converted to html. -- 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: HTML editor sucks
by Barry Smith 23 May '08

23 May '08

Is there any such thing as a html differ, instead of just a text differ? On May 23, 2008, at 8:56 AM, Satish Balay wrote: > I guess the problem is - each of us use different editors. > > The first time an editor is used - it does its own formatting - > without any changes. Subsequently - if the same editor is used - then > the diff is sane. > I use Nvu > I sometimes use emacs - and at times use seamonkey editor [new name > for mozilla]. > I've given up on just raw Emacs for editing our html, it is just too painful to get decent formating. > I guess we have to converge to a single editor to avoid this > issue. That may be asking to much. > Also I believe we have to redesign PETSc web page to make it > more attractive :) [with Beth - MCS/web developer's help] I think that PETSc's web pages are pretty good, so we should only have Beth improve them; not change them just to change them. Barry > > > Satish > > On Fri, 23 May 2008, Matthew Knepley wrote: > >> Does anyone else think it is crazy that a small 5 line edit in our >> html >> files creates an enormous diff, and it takes me 10min to find the >> little >> edit someone made? This is crazy. >> >> Matt >> >> > >

1 0

Re: HTML editor sucks
by Satish Balay 23 May '08

23 May '08

I guess the problem is - each of us use different editors. The first time an editor is used - it does its own formatting - without any changes. Subsequently - if the same editor is used - then the diff is sane. I sometimes use emacs - and at times use seamonkey editor [new name for mozilla]. I guess we have to converge to a single editor to avoid this issue. Also I believe we have to redesign PETSc web page to make it more attractive :) [with Beth - MCS/web developer's help] Satish On Fri, 23 May 2008, Matthew Knepley wrote: > Does anyone else think it is crazy that a small 5 line edit in our html > files creates an enormous diff, and it takes me 10min to find the little > edit someone made? This is crazy. > > Matt > >

1 0

HTML editor sucks
by Matthew Knepley 23 May '08

23 May '08

Does anyone else think it is crazy that a small 5 line edit in our html files creates an enormous diff, and it takes me 10min to find the little edit someone made? This is crazy. 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: PCView_MG
by Matthew Knepley 21 May '08

21 May '08

Cool, I will fix it. Matt On Wed, May 21, 2008 at 9:34 AM, Dave May <dave.mayhem23(a)gmail.com> wrote: > Hey guys, > I just noticed a strange inconsistency within PCView_MG. > This function reports > pre-smooths=%D, post-smooths=%D > using the the values from > mg[0]->default_smoothd,mg[0]->default_smoothu. > However, the values on level 0 are not modified by calls to > PCMGSetNumberSmoothDown/Up(). > Hence mg[0]->default_smoothd,mg[0]->default_smoothu are always the default > value of 1. > > The value of the relaxation sweeps is clear from the value of max_it defined > on the ksp at each level, so it seem unnecessary (and confusing) to report > that the pre/post-smooths based solely on the values of > default_smoothd/default_smoothu obtained from level 0. > > 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

PCView_MG
by Dave May 21 May '08

21 May '08

Hey guys, I just noticed a strange inconsistency within PCView_MG. This function reports pre-smooths=%D, post-smooths=%D using the the values from mg[0]->default_smoothd,mg[0]->default_smoothu. However, the values on level 0 are not modified by calls to PCMGSetNumberSmoothDown/Up(). Hence mg[0]->default_smoothd,mg[0]->default_smoothu are always the default value of 1. The value of the relaxation sweeps is clear from the value of max_it defined on the ksp at each level, so it seem unnecessary (and confusing) to report that the pre/post-smooths based solely on the values of default_smoothd/default_smoothu obtained from level 0. Cheers, Dave.

1 0

vacation Thursday May 22
by Barry Smith 21 May '08

21 May '08

I will be taking a vacation day Thursday May 22. Benjamin is having a bronchoscopy that day. Thank you, Barry

1 0

Re: Couple of requests.
by Matthew Knepley 15 May '08

15 May '08

On Wed, May 14, 2008 at 9:44 PM, Dave May <dave.mayhem23(a)gmail.com> wrote: > 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 ) Done. > 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? Done. Matt > > Thanks in advance. > > 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