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

Re: Patch to fix warnings in petscblaslapack_stdcall.h
by Satish Balay 22 Dec '08

22 Dec '08

Ok -I'll add it in the next patchtarball anyway.. [windows build ran fine with the patch] Satish On Mon, 22 Dec 2008, Jose E. Roman wrote: > > On 22/12/2008, Satish Balay wrote: > > > Sorry - I missed adding this for the 3.0 release. Will add it for the > > next patch update. > > > > However - I don't remember seeing any warnings on windows builds with > > the current petscblaslapack_stdcall.h file. Under what circumstances > > do you get warnings? > > > > thanks, > > Satish > > > > On Wed, 17 Dec 2008, Jose E. Roman wrote: > > > > > The attached file is a patch that fixes petscblaslapack_stdcall.h > > > The change consists in adding "const" to all char* arguments (as in > > > petscblaslapack.h). > > > Jose > > > > > > Well, we did not try compiling in Windows, we just forced the compiler to use > petscblaslapack_stdcall.h and got those warnings (on a MacOSX system). > > Thanks, > Jose >

1 0

Re: Patch to fix warnings in petscblaslapack_stdcall.h
by Jose E. Roman 22 Dec '08

22 Dec '08

On 22/12/2008, Satish Balay wrote: > Sorry - I missed adding this for the 3.0 release. Will add it for the > next patch update. > > However - I don't remember seeing any warnings on windows builds with > the current petscblaslapack_stdcall.h file. Under what circumstances > do you get warnings? > > thanks, > Satish > > On Wed, 17 Dec 2008, Jose E. Roman wrote: > >> The attached file is a patch that fixes petscblaslapack_stdcall.h >> The change consists in adding "const" to all char* arguments (as in >> petscblaslapack.h). >> Jose >> Well, we did not try compiling in Windows, we just forced the compiler to use petscblaslapack_stdcall.h and got those warnings (on a MacOSX system). Thanks, Jose

1 0

Re: Patch to fix warnings in petscblaslapack_stdcall.h
by Satish Balay 22 Dec '08

22 Dec '08

Sorry - I missed adding this for the 3.0 release. Will add it for the next patch update. However - I don't remember seeing any warnings on windows builds with the current petscblaslapack_stdcall.h file. Under what circumstances do you get warnings? thanks, Satish On Wed, 17 Dec 2008, Jose E. Roman wrote: > The attached file is a patch that fixes petscblaslapack_stdcall.h > The change consists in adding "const" to all char* arguments (as in > petscblaslapack.h). > Jose >

1 0

Important reminder for petsc-dev maintainers
by Barry Smith 20 Dec '08

20 Dec '08

For everyone providing patches and fixes for PETSc, please remember to make the patches on PETSc 3.0.0 and then pull them into petsc-dev. Please do not make simple fixes only in petsc-dev, it is best to fix petsc- release-3.0.0 (and BuildSystem-release-3.0.0) because those fixes will automatically get into the next patch and into petsc-dev. Do the following hg clone ssh://[email protected]//hg/petsc/petsc-release-3.0.0 petsc-3.0.0 cd petsc-3.0.0/config hg clone ssh://[email protected]//hg/petsc/BuildSystem-release-3.0.0 BuildSystem Thanks Barry For those without write access to petsc-dev you can clone from http://petsc.cs.iit.edu/petsc/petsc-release-3.0.0 and http://petsc.cs.iit.edu/petsc/BuildSystem-release-3.0.0

1 0

Re: where should config/configure.py put its log
by Barry Smith 18 Dec '08

18 Dec '08

Great, thanks Barry On Dec 18, 2008, at 12:53 PM, Satish Balay wrote: > I pushed this change. [moves logs to PETSC_ARCH/conf - and keeps > correct links in PETSC_DIR]. > > If configure process aborts before PETSC_ARCH is determined, the > logfiles remain in $PETSC_DIR. > > So the stuff in PETSC_DIR is always correct - but the ones in > PETSC_ARCH/conf are latest - only if configure goes beyond setting > PETSC_ARCH. > > One way to improve on this is to force 'framework' to do > utilities.arch.py much earlier.. [but the current dependencies on > petscdir,languages,compilerflags probably prevents this..]. > > Satish > > On Wed, 17 Dec 2008, Barry Smith wrote: > >> >> I guess having a link for both at the end would be ok. Just need to >> make sure the link is cleaned up (removed) at the beginning of the >> next run. >> >> Moving at the end for configure.py is fine also. You just need to >> move >> the code that does the file move after the catching of the exceptions >> in Configure.py >> >> Please try out making the changes, >> >> Barry >

1 0

Re: where should config/configure.py put its log
by Satish Balay 18 Dec '08

18 Dec '08

I pushed this change. [moves logs to PETSC_ARCH/conf - and keeps correct links in PETSC_DIR]. If configure process aborts before PETSC_ARCH is determined, the logfiles remain in $PETSC_DIR. So the stuff in PETSC_DIR is always correct - but the ones in PETSC_ARCH/conf are latest - only if configure goes beyond setting PETSC_ARCH. One way to improve on this is to force 'framework' to do utilities.arch.py much earlier.. [but the current dependencies on petscdir,languages,compilerflags probably prevents this..]. Satish On Wed, 17 Dec 2008, Barry Smith wrote: > > I guess having a link for both at the end would be ok. Just need to > make sure the link is cleaned up (removed) at the beginning of the next run. > > Moving at the end for configure.py is fine also. You just need to move > the code that does the file move after the catching of the exceptions > in Configure.py > > Please try out making the changes, > > Barry

1 0

Re: where should config/configure.py put its log
by Barry Smith 17 Dec '08

17 Dec '08

I guess having a link for both at the end would be ok. Just need to make sure the link is cleaned up (removed) at the beginning of the next run. Moving at the end for configure.py is fine also. You just need to move the code that does the file move after the catching of the exceptions in Configure.py Please try out making the changes, Barry On Dec 17, 2008, at 9:12 PM, Satish Balay wrote: > On Wed, 17 Dec 2008, Barry Smith wrote: > >> >> Currently, make all results in the log file in $PETSC_ARCH/conf >> regardless of >> whether the >> make is good or bad >> >> Meanwhile config/configure.py puts the running logfile into >> configure.log and >> ON SUCCESS >> it moves the result to $PETSC_ARCH/conf >> >> I don't think this is best. I propose that configure.log be built >> directly in >> $PETSC_ARCH/conf >> Reasons: >> 1) When we tell people to send us configure.log we don't have to >> say: "if >> config/configure.py failed >> send us configure.log if it succeeded send us $PETSC_ARCH/conf/ >> configure.log" >> This will be confusing >> to people who may not even understand if it succeeded or not. >> 2) consistency, it is confusing to have it done differently from >> the make. >> >> Any good reasons why this is a bad idea? > > I've had issues with the 2 locations for configure.log [for eg: in the > nightly builds] - so 1 location $PETSC_ARCH/conf is good for me. > > But one potential problem: I don't think it can be directly built in > $PETSC_ARCH/conf as $PETSC_ARCH is sometimes determined quarter-way > through the configure process [and the dir $PETSC_ARCH/conf is created > then..] > > So the logfile should get copied over at the end... [I'd like to keep > a link in PETSC_DIR to the latest configure.log - and perhaps make_log > aswell] > > Satish >

1 0

Re: where should config/configure.py put its log
by Satish Balay 17 Dec '08

17 Dec '08

On Wed, 17 Dec 2008, Barry Smith wrote: > > Currently, make all results in the log file in $PETSC_ARCH/conf regardless of > whether the > make is good or bad > > Meanwhile config/configure.py puts the running logfile into configure.log and > ON SUCCESS > it moves the result to $PETSC_ARCH/conf > > I don't think this is best. I propose that configure.log be built directly in > $PETSC_ARCH/conf > Reasons: > 1) When we tell people to send us configure.log we don't have to say: "if > config/configure.py failed > send us configure.log if it succeeded send us $PETSC_ARCH/conf/configure.log" > This will be confusing > to people who may not even understand if it succeeded or not. > 2) consistency, it is confusing to have it done differently from the make. > > Any good reasons why this is a bad idea? I've had issues with the 2 locations for configure.log [for eg: in the nightly builds] - so 1 location $PETSC_ARCH/conf is good for me. But one potential problem: I don't think it can be directly built in $PETSC_ARCH/conf as $PETSC_ARCH is sometimes determined quarter-way through the configure process [and the dir $PETSC_ARCH/conf is created then..] So the logfile should get copied over at the end... [I'd like to keep a link in PETSC_DIR to the latest configure.log - and perhaps make_log aswell] Satish

1 0

where should config/configure.py put its log
by Barry Smith 17 Dec '08

17 Dec '08

Currently, make all results in the log file in $PETSC_ARCH/conf regardless of whether the make is good or bad Meanwhile config/configure.py puts the running logfile into configure.log and ON SUCCESS it moves the result to $PETSC_ARCH/conf I don't think this is best. I propose that configure.log be built directly in $PETSC_ARCH/conf Reasons: 1) When we tell people to send us configure.log we don't have to say: "if config/configure.py failed send us configure.log if it succeeded send us $PETSC_ARCH/conf/ configure.log" This will be confusing to people who may not even understand if it succeeded or not. 2) consistency, it is confusing to have it done differently from the make. Any good reasons why this is a bad idea? Barry

1 0

Re: possible bug?
by Barry Smith 17 Dec '08

17 Dec '08

The code is correct in petsc-dev. Barry On Dec 17, 2008, at 3:05 PM, David Fuentes wrote: > > > working with petsc-2.3.3-p13 > > in file $PETSC_DIR/src/vec/vec/impls/mpi/pdvec.c > > possible bug in VecSetValues_MPI > > ?? > > > > DIPWS019$ diff $PETSC_DIR/src/vec/vec/impls/mpi/pdvec.c pdvec.c > 878c878 > < if (ix[i] > xin->map.N) > SETERRQ2(PETSC_ERR_ARG_OUTOFRANGE,"Out > of range index value %D maximum %D",ix[i],xin->map.N); > --- >> if (ix[i] >= xin->map.N) >> SETERRQ2(PETSC_ERR_ARG_OUTOFRANGE,"Out of range index value %D >> maximum %D",ix[i],xin->map.N); > > > >

1 0