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

efficient small matrix solver
by Matt 26 Jan '06

26 Jan '06

Hi, We use PETSc and noticed on the web site that you built (from linpack) some routines to factor/solve small dense matrices efficiently. What are those routines? I'd like to get the bottom level routines as I want to modify them just a bit more. (I want to set the matrix size as a constant to help the compiler, and possibly add some pragmas to help the compiler.) Thanks, Matt

1 0

Re: WARNING: be careful before pulling petsc-dev!
by Matthew Knepley 20 Jan '06

20 Jan '06

Barry Smith <bsmith(a)mcs.anl.gov> writes: > Yes, these code cleanups are painful, but they are > also crucial to the long-term viability of PETSc. The day we lose the courage to rewrite is the day to pack it in. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

WARNING: be careful before pulling petsc-dev!
by Barry Smith 20 Jan '06

20 Jan '06

I have made a major change to the Vec and Mat internal data structures. PetscMap() is NO LONGER a PETSc object, it is now a simply data structure in the Vec and Mat objects. The m,M,n,N, rowners,rstart,rend, cstart and cstart fields in the Vec and Mat objects are removed, instead the fields in the map data structure inside the Mat and Vec are used. Aside from the missing PetscMap, this has not introduced any API interfaces. Making this change, almost for sure, introduced some errors (making the substantial code changes was painful and prone to error). Please track down the problems or let me know about them so we can eliminate the introduced problems. The external matrix packages have NOT been tested (they will be tested in nightly builds). Thus, if you are trying to get work done, instead of tracking down our bugs, I recommend not pulling petsc-dev for several days. Thanks for all your patience, Barry Yes, these code cleanups are painful, but they are also crucial to the long-term viability of PETSc.

1 0

Re: configure updates
by Satish Balay 17 Jan '06

17 Jan '06

On Tue, 10 Jan 2006, Matthew Knepley wrote: > Satish Balay <balay(a)mcs.anl.gov> writes: > > > I've pushed a new option to configure [appears to be required by a few > > external packages] > > > > --download-netlib-blas-lapack=1 > > Yes, this is fine. This opton is now removed. f-blas-lapack now has all the blas/lapack sources [so the separate option is not necessary] Satish

1 0

Re: configure updates
by Matthew Knepley 10 Jan '06

10 Jan '06

Satish Balay <balay(a)mcs.anl.gov> writes: > I've pushed a new option to configure [appears to be required by a few > external packages] > > --download-netlib-blas-lapack=1 Yes, this is fine. > Also - I'd like to push the following change > > chnage: > --with-f90-header=f90_rs6000.h --with-f90-source=f90_rs6000.c > to: > --with-f90-interface=rs6000 > > With the following help string: > --with-f90-interface=<type> : Specify compiler type for eg: intel8,solaris,rs6000,IRIX,win32,absoft,t3e,dec,cray_x1,hpux I think this sounds fine. It should use the vendor names we already use for compilers (and already have mapped to source/header names). Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

configure updates
by Satish Balay 10 Jan '06

10 Jan '06

I've pushed a new option to configure [appears to be required by a few external packages] --download-netlib-blas-lapack=1 Also - I'd like to push the following change chnage: --with-f90-header=f90_rs6000.h --with-f90-source=f90_rs6000.c to: --with-f90-interface=rs6000 With the following help string: --with-f90-interface=<type> : Specify compiler type for eg: intel8,solaris,rs6000,IRIX,win32,absoft,t3e,dec,cray_x1,hpux Satish

1 0

Re: Translator
by Richard Tran Mills 22 Dec '05

22 Dec '05

Matt, I agree with Barry that this might cause more grief than it would save, and it would also be quite difficult to do this correctly with Fortran. That said =), I am a minor participant in an LDRD project here that is working on developing and applying source-to-source translation tools (e.g., stuff like ROSE -- http://www.llnl.gov/CASC/rose/) This might be something that I could try under the auspices of that project. I'll discuss this with the other folks on the project. There are some other areas wher source-to-source translation tools might be useful as well. To port the PFLOTRAN code to machines where the compiler doesn't support VeGetArrayF90() interfaces, I ended up hacking together a very crude Python program to convert those calls into the F77-style VecGetArray() ones. Doing it using real parsing tools would be much better, though. Cheers, Richard Matthew Knepley wrote: > It seems many problems could be fixed if we could just get people to > translate their code to the next version. Is it worth it to invest time in > a Python translator that would try to auto-upgrade software to the newest > interface? I was thinking a sed-like thing at first, but we do have a partial > C parser available as well. However, that version is somewhat bad in that it > blows away spaces. > > Matt

1 0

Re: Translator
by Barry Smith 16 Dec '05

16 Dec '05

Seems likely to cause more grief then to save grief. Fortran would be terribly difficult and fortran users are the most stubborn about not keeping up to date. The problem comes from codes that have no true owner. That is, a person who feels connected to the code and obligated to keep it in good shape. People who write the initial code generally make good owners, but if they leave and someone else "takes over" this person (1) is scared of changing anything because they don't know the code and (2) does not have much personal investment in the code so just doesn't care like an author cares. Alas, I do not know what can be done about these people. Barry On Fri, 16 Dec 2005, Matthew Knepley wrote: > It seems many problems could be fixed if we could just get people to > translate their code to the next version. Is it worth it to invest time in > a Python translator that would try to auto-upgrade software to the newest > interface? I was thinking a sed-like thing at first, but we do have a partial > C parser available as well. However, that version is somewhat bad in that it > blows away spaces. > > Matt >

1 0

Translator
by Matthew Knepley 16 Dec '05

16 Dec '05

It seems many problems could be fixed if we could just get people to translate their code to the next version. Is it worth it to invest time in a Python translator that would try to auto-upgrade software to the newest interface? I was thinking a sed-like thing at first, but we do have a partial C parser available as well. However, that version is somewhat bad in that it blows away spaces. Matt -- "Failure has a thousand explanations. Success doesn't need one" -- Sir Alec Guiness

1 0

Re: PIC
by Barry Smith 15 Dec '05

15 Dec '05

Satish, Thanks, we'll have to live with this fix. Barry On Thu, 15 Dec 2005, Satish Balay wrote: > Barry, > > I'm attaching the relavent logfiles for this failure case. Looks like > there is an exception raised for this case - so I can trap it in > MPI.py - and error out. [other case returns a '0' - which is ok for > PETSc sharedlibs] > > So with this change to MPI.py, configure give a nice error message: > > ********************************************************************************* > UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details): > --------------------------------------------------------------------------------------- > PETSc shared libraries cannot be built using MPI provided. > Either rebuild PETSc with --with-shared=0 or rebuild MPI with shared library support > ********************************************************************************* > > I'll push this change. > > Satish > > > On Wed, 14 Dec 2005, Barry Smith wrote: > > > > > > This also succeeds, unless I misunderstand greatly the error. > > > > The libraries get built, fine. Now you generate the executable. > > That FAILS! As I have been saying all the time! It fails NOT > > because the library is not shared but because one cannot use > > that library WITH shared libraries! > > > > The new test is suppose to check that it can link and generate > > the executable, BUT not run the executable to see what message > > you get. > > > > The new test could be called checkCanBeUsedWithSharedLibrary() and > > it would shared almost all the code with checkShared() except actually > > running the executable and checking the result. > > > > Is it clear now, or am I still messed up?

1 0