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

recompile all after next pull
by Barry Smith 08 Dec '05

08 Dec '05

I have added another field to the petscheader (the common base shared by all PETSC objects). Thus the next time you pull you will need to recompile all of your PETSc libraries. Barry

1 0

changed location of todo list
by Barry Smith 28 Nov '05

28 Nov '05

I have removed the petsc-dev/todo file and put all the (many, many) entries into the src/docs/website/developers/projects.html file. Barry

1 0

Re: release soon?
by Hong Zhang 23 Nov '05

23 Nov '05

Fine with me. The superlu_dist has memory leak. I'm still working on it, and hopefully get it fix soon. Hong On Tue, 22 Nov 2005, Barry Smith wrote: > > Satish, Matt and Hong, > > Can we aim for a new release Friday Dec 2? > These means no new major feature additions before then > and lots of time checking nightly builds. Also as many > new nightly build variants as possible (for example > --with-precision=longdouble, --download- various packages > and testing of --with-petsc-shared and --with-petsc-dynamic) > > Doable? > > Barry > >

1 0

release soon?
by Barry Smith 22 Nov '05

22 Nov '05

Satish, Matt and Hong, Can we aim for a new release Friday Dec 2? These means no new major feature additions before then and lots of time checking nightly builds. Also as many new nightly build variants as possible (for example --with-precision=longdouble, --download- various packages and testing of --with-petsc-shared and --with-petsc-dynamic) Doable? Barry

1 0

Re: [PETSC #13812] Feature request: "long double" support
by Barry Smith 21 Nov '05

21 Nov '05

Roy, Number of Newton iterations = 4 lid velocity = 0.0204082, prandtl # = 1, grashof # = 1 0 SNES Function norm 1.461936698223e-01 1 SNES Function norm 2.507018921541e-05 2 SNES Function norm 5.123354965471e-13 3 SNES Function norm 1.676580470503e-28 4 SNES Function norm 5.094694802293e-32 Nonlinear solve converged due to CONVERGED_FNORM_RELATIVE I have added preliminary support for compiling PETSc using long doubles (128 bit on some systems like the Apple). The config/configure.py flag is --with-precision=longdouble Current limitations: 1) have not added support for using Fortran (I think this is doable assuming they use the same floating point representation) 2) no support for binary IO (this is doable, just need work arrays, etc. like the code for --with-precision=float) 3) must use --download-c-blas-lapack (assuming you have native BLAS/LAPACK for 128 bit (I think IBM does) we could add support to use it.) 4) some systems don't support %Lg for ASCII formating (for example, Apple doesn't support it, but it does support long double :-(). 5) no support for complex I won't work on 1,2 or 3 until there is a user who needs it. Barry On Fri, 14 Oct 2005, Roy Stogner wrote: > On Fri, 14 Oct 2005, Barry Smith wrote: > > > Yes I think it would be reasonable, and maybe possible :-). > > > > The kicker will be the BLAS calls, we'd either need to 1) write the > > name translations if your system has some long double BLAS > > I'm afraid it doesn't. I'm using the BLAS provided with Fedora Core, > which has s/d/c/z versions of every call and no more. I've seen > proposals to add versions "k" for long double and "q" for long double > complex, but I don't know if this has been coded or widely adopted > yet. > > > or 2) compile f2cblaslapack or blaslapack in long double or > > I'd be worried about portability between F77 and C code. I know on > gcc/x86 for example the ABI for 80 bit long doubles can be padded out > to 96 bits or 128 bits based on compiler flags. I'm not sure if the > 96 bit version corresponds to Fortran's REAL*12, and I don't think the > 128 bit version corresponds to REAL*16. > > You could probably start with the double f2cblaslapack routines and > get working code out of 's/double/long double/g', though. Trying to > maintain code that came out of a wizard or autotranslator is a > nightmare, but it should be fine for code that doesn't require a lot > of updates. This is probably the way to go. > > > 3) turn on PETSc with Fortran kernels to replace all the BLAS (and > > compile the Fortran with long double). > > This wouldn't work unless I'm wrong about the incompatibility between > Fortran and C/C++ extended precision datatypes. > > > None of these are theoretically difficult, but the process could be > > a little messy. > > That's about what I thought. If it wasn't going to be messy I would > have sent you a patch, not a feature request. ;-) > > > Changes to the rest of PETSc would be (in theory) trivial. > > That's what I hoped, but there's so many places in PETSc where > "double" is used literally rather than indirectly through PetscScalar; > I don't know just how much of that would have to be extended. > > For a code you're already familiar with it's not hard. I've been > checking libMesh for float and long double compatibility, and the only > unexpected problems were some *printf format strings and tolerance > constants that need to be precision dependent. The only hard problem > is interfacing with outside libraries - it might be reasonable to > throw away precision and truncate to double before interacing with I/O > code, but if there's a third party library handling intermediate > calculations where you need that precision, then the only solution is, > well, to pester their email address like this. > > Thanks, > --- > Roy Stogner > >

1 0

Re: plone
by Satish Balay 04 Nov '05

04 Nov '05

Justin, Thanks for the info. Satish On Sat, 5 Nov 2005, Justin Bedo wrote: > Hi Satish, > > > Le 05/11/2005 ï¿½ 1:41 AM, Satish Balay a ï¿½crit : > > > > > Is the bugtracker internal to plone or is it an external package? > > The bugtracker in an product for plone written by Andreas Jung. The product > is called "PloneCollectorNG". > > > > > Looks like plone is a complete web-site management package for > > individual projects like PETSc. > > > > But we already moved from storing our web content in frontpage to 'bk' > > - and I'm not sure if we want to move to a differnet system. [and > > convince our system admins to install/maintain plone on our web > > servers] > > > > BTW: does it have some kind of version control for the 'content'? I'm > > guessing it uses a database at the backend to store > > content/bug-tracker data? > > Plone works on top of Zope, which stores all its data in the ZODB, the Zope > Object Data Base. There is not really any version control as such, but you > can roll back changes easily. > > > > > Also - how does account management work? i.e do all users for > > mailing-lists/bugtracking/content-changers etc. need an account? > > This depends how the bugtracker is set up. It can be set up so that you need > an account to submit bugs, but we have it set up so bugs can be submitted > anonymously. You do need an account, with appropriate permissions, to > manipulate/add content. > > > > > And does it have an e-mail gateway for bugtracker? Currently anyone > > can send email to petsc-maint(a)mcs.gov - and We'd like to keep this > > user interface > > I'm not aware of any feature such as this in PloneCollectorNG. > > Cheers > Justin >

1 0

Re: plone
by Satish Balay 04 Nov '05

04 Nov '05

On Fri, 4 Nov 2005, S V N Vishwanathan wrote: > One thing I can highly recommend (based on our experiences so far) is to > use plone. It has all the right combination of tools viz. > > * bug tracker > * mailing lists > * release managers Is the bugtracker internal to plone or is it an external package? Looks like plone is a complete web-site management package for individual projects like PETSc. But we already moved from storing our web content in frontpage to 'bk' - and I'm not sure if we want to move to a differnet system. [and convince our system admins to install/maintain plone on our web servers] BTW: does it have some kind of version control for the 'content'? I'm guessing it uses a database at the backend to store content/bug-tracker data? Also - how does account management work? i.e do all users for mailing-lists/bugtracking/content-changers etc. need an account? And does it have an e-mail gateway for bugtracker? Currently anyone can send email to petsc-maint(a)mcs.gov - and We'd like to keep this user interface Any additional info would be great.. thanks, Satish

1 0

Re: tracking petsc
by S V N Vishwanathan 03 Nov '05

03 Nov '05

Hi! Satish> But currently petsc-dev list archives are available only locally. And Satish> petsc-maint is a 'bug-tracker' - not a mailing list. The archives of Satish> this are also available locally only. Satish> I'm checking if we can upgrade to a better bug tracker - with both Satish> public/private entries [like bugzilla]. But.... One thing I can highly recommend (based on our experiences so far) is to use plone. It has all the right combination of tools viz. * bug tracker * mailing lists * release managers etc. which can make you life rather easy. We have switched completely to plone (http://lineal.developer.nicta.com.au which will be live in a day or two once our legal dept has drafted a fat disclaimer :) ) and are rather happy with it. If you guys are interested we can provide you with more information/help on setting things up. Justin is our local expert on this. vishy ----- The only skills I have the patience to learn are those that have no real application in life. -- Calvin

1 0

Re: more inlining ?
by Matthew Knepley 03 Nov '05

03 Nov '05

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Should we inline VecSetValues, MatSetValues, and friends? If 1) at least gcc supports it (we will have to maintain the #define for those that are not C99 I think) 2) gdb handles it I also have another proposal. Dmitry and I are going to convert the prior code gen framework from ASE to pure Python. I consider ASE a failed experiment, but the code gen is still useful. I think we can handle some of these situations that do not occur in user code with a generation framework. For instance, stuff for different block sizes. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: tracking petsc
by Barry Smith 03 Nov '05

03 Nov '05

Simon, We are planning a new release real soon. I recommend very much tracking petsc-dev, then after the release 2.3.1 you can stick with that for a while (we'll patch problems that come up, but won't be constantly changing things). Barry On Fri, 4 Nov 2005, Simon Burton wrote: > On Thu, 03 Nov 2005 17:49:46 -0600 > Matthew Knepley <knepley(a)mcs.anl.gov> wrote: > > > > > Simon Burton <simon(a)arrowtheory.com> writes: > > > > This was patched in 2.3.0, but maybe you have an unpatched version. It is > > easy to check. The symbol comes from > > We have been tracking your bitkeeper repository. I don't know if this is > sane or not because we want to release something (in a few weeks) > and that basically means it is up to us to somehow stabilize PETSc, > or at least "bless" some particular version of PETSc. > > No, that doesn't sound right either: fixes that you guys make will go into > the bk repository, so... I guess what I am asking is, are we just insane to > try and do this ? Or, is it possible to maybe branch your repository so > we can stabilize PETSc for some kind of beta release ? > > Sounds like we just need to make it clear that petsc is on the move > and that you guys are completely responsive to bug reports, etc. > > We are going to build a "petsc doesn't work" FAQ, but, gee i wish your email > list (petsc-maint) was archived somewhere... > > If you start getting 10 more support queires a day can you handle that ? > What about 50 ? Maybe I can also act as a gateway, if I tell our users to come to > me first. > > Simon. > > >

1 0