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

Re: [petsc-dev] buildsystem: cusp location
by Satish Balay 25 Mar '12

25 Mar '12

On Sun, 25 Mar 2012, Sean Farley wrote: > On Sun, Mar 25, 2012 at 12:27 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > > On Sun, Mar 25, 2012 at 12:16, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > >> I don't see how the above is abusing --with-cusp-dir= > >> option. --with-package-dir option - by definition is to specify the > >> default install root dir of the given package. [assuming all packages > >> default to PACKAGE_DIR/include is wrong]. > >> > > > > Okay, but apparently we see it installed this way in practice. > > > > To follow-up on this, this is even the practice we have when installing > packages specified with --download. So, why can't we specify > --with-package-dir to have a common structure > (PACKAGE_DIR/{include,lib,lib64,lib32,bin,share,etc}) and if the user > doesn't have that structure, then have them use the > --with-package-{include,lib} options? I'm at a loss for which cases that > doesn't cover. The default organization for --with-package-dir should be the default organization used by the package - not what petsc configure dictates whats suitable for itself. For ex: look at MKL - and the wierd path scheems it has developed over the past many versions. We support most of them. However there is a bit of autodetection in --with-package-dir - and if one wants to skip this [because they know better] - then --with-include,-with-lib is the correct thing to do. We do this when petsc configure builds externalpackages [petsc configure tells the configure of external package exactly what do do - instead of letting it autodetect - stuff petsc configure already detected] etc.. Note1: To some extent --download-package is internal to petsc - so if it changes the default organiztion for packages - its fine by me [aka cusp/thrust] Note2: We might not support 'default organization' for all externalpackages. [for packages that are primarily installed with --download-package option - where we modify internal buildtools - for ex: native lapack from netlib, blacs etc?]. Satish

1 0

Re: [petsc-dev] buildsystem: cusp location
by Jed Brown 25 Mar '12

25 Mar '12

2012/3/25 Satish Balay <balay(a)mcs.anl.gov> > The key here is for the user to be aware that the layout is not normal. > Well, what is "normal"? The way the package recommends and the way all other packages are organized, or the way an unknowing user might lay things out? > > I agree - There is a bit of autodetection with --with-package-dir > option. But if one knows include,lib details and want to specify these > details --with-package-include, --with-package-lib are appropriate > options. > > And with default layout - one should expect both modes to work. > > > > What other package ever uses --prefix=.../include? Every one I know of > > would expect you to say --prefix=/opt/local/ and it would place headers > in > > /opt/local/include. > > Well this package is trying to organize itself within 'cuda include' > package orgainzation. I think this is smilar to the way 'perl' or > 'python' modules organize themselves within their respective trees. > With Python, I say --prefix=/opt/local and it puts things in /opt/local/lib/python3.2/site-packages. There is a PYTHONPATH environment variable that points to the inner directory, but I have always thought --with-foo-dir= should be thought of as matching a --prefix option.

1 0

Re: [petsc-dev] buildsystem: cusp location
by Satish Balay 25 Mar '12

25 Mar '12

On Sun, 25 Mar 2012, Jed Brown wrote: > 2012/3/25 Satish Balay <balay(a)mcs.anl.gov> > > > Cusp installer is nothing but unzip. The recommended installation > > methond is: > > > > https://code.google.com/p/cusp-library/wiki/QuickStartGuide > > > > >>>>>>>> > > Simply download the newest version of Cusp from here and extract the > > contents of each zip file to a directory. We suggest installing Cusp to the > > CUDA include directory, which is usually > > > > /usr/local/cuda/include/ on a Linux and Mac OSX > > C:\CUDA\include\ on a Windows system > > > > If you are unable to install to the CUDA include directory, then you can > > place the files somewhere in your home directory, for example: > > /home/nathan/cuda_libraries/cusp/. > > > > Warning: Do not install Cusp to a standard include path like > > /usr/local/include/. It appears that nvcc treats such paths differently > > than the suggestions above which causes errors like error: expected > > primary-expression before οΏ½<οΏ½ token. > > <<<<<<<<<<< > > > > In the above example --with-cusp-dir=/home/nathan/cuda_libraries/cusp/ > > would have worked. > > > > Would it have been so hard to write > --with-cusp-include=/home/nathan/cuda_libraries/cusp/ if you don't want to > install with a normal layout? The key here is for the user to be aware that the layout is not normal. I agree - There is a bit of autodetection with --with-package-dir option. But if one knows include,lib details and want to specify these details --with-package-include, --with-package-lib are appropriate options. And with default layout - one should expect both modes to work. > > So when one specifies --with-cusp-dir=/opt/local to petsc configure > > and expects -I/opt/local/include to work - the install process was perhaps: > > > > cd /opt/local/include > > unzip cusp.zip > > > > [i.e equivalent to using --prefix=/opt/local/include] > > > > What other package ever uses --prefix=.../include? Every one I know of > would expect you to say --prefix=/opt/local/ and it would place headers in > /opt/local/include. Well this package is trying to organize itself within 'cuda include' package orgainzation. I think this is smilar to the way 'perl' or 'python' modules organize themselves within their respective trees. Satish

1 0

Re: [petsc-dev] buildsystem: cusp location
by Jed Brown 25 Mar '12

25 Mar '12

2012/3/25 Satish Balay <balay(a)mcs.anl.gov> > Cusp installer is nothing but unzip. The recommended installation > methond is: > > https://code.google.com/p/cusp-library/wiki/QuickStartGuide > > >>>>>>>> > Simply download the newest version of Cusp from here and extract the > contents of each zip file to a directory. We suggest installing Cusp to the > CUDA include directory, which is usually > > /usr/local/cuda/include/ on a Linux and Mac OSX > C:\CUDA\include\ on a Windows system > > If you are unable to install to the CUDA include directory, then you can > place the files somewhere in your home directory, for example: > /home/nathan/cuda_libraries/cusp/. > > Warning: Do not install Cusp to a standard include path like > /usr/local/include/. It appears that nvcc treats such paths differently > than the suggestions above which causes errors like error: expected > primary-expression before ‘<’ token. > <<<<<<<<<<< > > In the above example --with-cusp-dir=/home/nathan/cuda_libraries/cusp/ > would have worked. > Would it have been so hard to write --with-cusp-include=/home/nathan/cuda_libraries/cusp/ if you don't want to install with a normal layout? > > So when one specifies --with-cusp-dir=/opt/local to petsc configure > and expects -I/opt/local/include to work - the install process was perhaps: > > cd /opt/local/include > unzip cusp.zip > > [i.e equivalent to using --prefix=/opt/local/include] > What other package ever uses --prefix=.../include? Every one I know of would expect you to say --prefix=/opt/local/ and it would place headers in /opt/local/include.

1 0

Re: [petsc-dev] buildsystem: cusp location
by Sean Farley 25 Mar '12

25 Mar '12

On Sun, Mar 25, 2012 at 12:27 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Sun, Mar 25, 2012 at 12:16, Satish Balay <balay(a)mcs.anl.gov> wrote: > >> I don't see how the above is abusing --with-cusp-dir= >> option. --with-package-dir option - by definition is to specify the >> default install root dir of the given package. [assuming all packages >> default to PACKAGE_DIR/include is wrong]. >> > > Okay, but apparently we see it installed this way in practice. > To follow-up on this, this is even the practice we have when installing packages specified with --download. So, why can't we specify --with-package-dir to have a common structure (PACKAGE_DIR/{include,lib,lib64,lib32,bin,share,etc}) and if the user doesn't have that structure, then have them use the --with-package-{include,lib} options? I'm at a loss for which cases that doesn't cover.

1 0

Re: [petsc-dev] buildsystem: cusp location
by Satish Balay 25 Mar '12

25 Mar '12

On Sun, 25 Mar 2012, Jed Brown wrote: > On Sun, Mar 25, 2012 at 12:16, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > I don't see how the above is abusing --with-cusp-dir= > > option. --with-package-dir option - by definition is to specify the > > default install root dir of the given package. [assuming all packages > > default to PACKAGE_DIR/include is wrong]. > > > > Okay, but apparently we see it installed this way in practice. Cusp installer is nothing but unzip. The recommended installation methond is: https://code.google.com/p/cusp-library/wiki/QuickStartGuide >>>>>>>> Simply download the newest version of Cusp from here and extract the contents of each zip file to a directory. We suggest installing Cusp to the CUDA include directory, which is usually /usr/local/cuda/include/ on a Linux and Mac OSX C:\CUDA\include\ on a Windows system If you are unable to install to the CUDA include directory, then you can place the files somewhere in your home directory, for example: /home/nathan/cuda_libraries/cusp/. Warning: Do not install Cusp to a standard include path like /usr/local/include/. It appears that nvcc treats such paths differently than the suggestions above which causes errors like error: expected primary-expression before οΏ½<οΏ½ token. <<<<<<<<<<< In the above example --with-cusp-dir=/home/nathan/cuda_libraries/cusp/ would have worked. So when one specifies --with-cusp-dir=/opt/local to petsc configure and expects -I/opt/local/include to work - the install process was perhaps: cd /opt/local/include unzip cusp.zip [i.e equivalent to using --prefix=/opt/local/include] Note: one case where users stumble with specifying cusp to cuda is: - unzip at say /home/nathan/soft [but this creates stuff like /home/nathan/soft/cusp/*.h] - Now use --with-cusp-dir=/home/nathan/soft/cusp [but this is wrong - and broken] Satish

1 0

Re: [petsc-dev] buildsystem: cusp location
by Jed Brown 25 Mar '12

25 Mar '12

On Sun, Mar 25, 2012 at 12:16, Satish Balay <balay(a)mcs.anl.gov> wrote: > I don't see how the above is abusing --with-cusp-dir= > option. --with-package-dir option - by definition is to specify the > default install root dir of the given package. [assuming all packages > default to PACKAGE_DIR/include is wrong]. > Okay, but apparently we see it installed this way in practice.

1 0

Re: [petsc-dev] buildsystem: cusp location
by Barry Smith 25 Mar '12

25 Mar '12

Side note. We should remove the --download-thrust and --download-cusp options. Barry On Mar 25, 2012, at 12:16 PM, Satish Balay wrote: > On Sun, 25 Mar 2012, Jed Brown wrote: > >> On Sun, Mar 25, 2012 at 11:59, Satish Balay <balay(a)mcs.anl.gov> wrote: >> >>> When configure is doing --download-cusp - it can determine how cusp is >>> organized. [I think we try to place in PETSC_DIR/PETSC_ARCH/include. >>> But since cusp decides how it installs itself [say user installs and >>> installs manually] - we try to support that mode using >>> --with-cusp-dir= option. There is no 'include/' dir in that mode of >>> install. >>> >> >> Well isn't that what --with-cusp-include= is for? >> >> I even wouldn't object to being lenient, > > you mean detect all possible locations related to user specified > --cups-dir option? This is a fine aproach - I guess we should fix > cusp/thrust to do this. [i.e sean's option(1) ]. > >> but I don't think it makes sense to abuse the meaning of >> --with-cusp-dir=. > > I don't see how the above is abusing --with-cusp-dir= > option. --with-package-dir option - by definition is to specify the > default install root dir of the given package. [assuming all packages > default to PACKAGE_DIR/include is wrong]. > >>> Yes - currently the situation is not ideal. The ideal situation is >>> folks install cusp thrust - the recommended way - i.e along with cuda >>> in cuda includes. One has to do this with thrust anyway - otherwise >>> nvcc will always pick up thrust bundled with cuda - and now what you >>> specify with -I/path-to-thrust. > > Even if we sort out the previous issue - this conflict with default thrust > will continue to exist [I'll say this as nvcc bug.] > > Satish > >>> The other problem currently with cusp/thrust is - we've been using dev >>> snapshot of cusp/thrust for a while. I don't know if there is a >>> release snapshot of these packages that we can switch to now [or not]. >>> >> >

1 0

Re: [petsc-dev] Petsc functions must ALWAYS return error codes
by Barry Smith 25 Mar '12

25 Mar '12

Mark, Complicated iterators are fine in languages like C++ and Python that can handle error conditions via exceptions. In C we are stuck using returned values to indicate errors so yes you have to do iterators, for example, in your second example below where you still check error codes for everything (including get next value from iterators). Thanks Barry On Mar 25, 2012, at 10:53 AM, Mark F. Adams wrote: > Barry, > > The iterators are a problem. THe code now looks like: > > for(pos=PetscCDGetHeadPos(agg_llists,kk) ; > pos ; > pos=PetscCDGetNextPos(agg_llists,kk,pos)){ > .... > } > > I could use: > > ierr = PetscCDGetHeadPos(agg_llists,kk, &pos); > while( pos ){ > > ... > > ierr = PetscCDGetNextPos(agg_llists, kk, &pos ); > } > > Is this what you would like or do you have another API suggestion? > > Mark > > On Mar 24, 2012, at 11:21 PM, Barry Smith wrote: > >> >> There are a bunch of these functions that don't return error codes and need to be fixed. >> >> Barry >> >> PetscInt LLNGetID( const PetscCDIntNd *a_this ); >> PetscErrorCode PetscCDAppendID( PetscCoarsenData *ail, PetscInt a_idx, PetscInt a_gid ); >> PetscErrorCode PetscCDAppendRemove( PetscCoarsenData *ail, PetscInt a_destidx, PetscInt a_srcidx ); >> PetscErrorCode PetscCDAppendNode( PetscCoarsenData *ail, PetscInt a_idx, PetscCDIntNd *a_n ); >> PetscErrorCode PetscCDRemoveNextNode( PetscCoarsenData *ail, PetscInt a_idx, PetscCDIntNd *a_last ); >> PetscErrorCode PetscCDRemoveAllAt( PetscCoarsenData *ail, PetscInt a_idx ); >> PetscInt PetscCDSizeAt( const PetscCoarsenData *ail, PetscInt a_idx ); >> PetscErrorCode PetscCDSetChuckSize( PetscCoarsenData *ail, PetscInt a_sz ); >> PetscErrorCode PetscCDPrint( const PetscCoarsenData *ail, MPI_Comm comm ); >> PetscErrorCode PetscCDGetMIS( PetscCoarsenData *ail, IS * ); >> PetscErrorCode PetscCDGetMat( const PetscCoarsenData *ail, Mat * ); >> PetscErrorCode PetscCDSetMat( PetscCoarsenData *ail, Mat ); >> typedef PetscCDIntNd* PetscCDPos; >> const PetscCDPos PetscCDGetHeadPos( const PetscCoarsenData *ail, PetscInt idx ); >> const PetscCDPos PetscCDGetNextPos( const PetscCoarsenData *ail, PetscInt idx, PetscCDPos cpos); >> >> >> >> >

1 0

Re: [petsc-dev] buildsystem: cusp location
by Satish Balay 25 Mar '12

25 Mar '12

On Sun, 25 Mar 2012, Jed Brown wrote: > On Sun, Mar 25, 2012 at 11:59, Satish Balay <balay(a)mcs.anl.gov> wrote: > > > When configure is doing --download-cusp - it can determine how cusp is > > organized. [I think we try to place in PETSC_DIR/PETSC_ARCH/include. > > But since cusp decides how it installs itself [say user installs and > > installs manually] - we try to support that mode using > > --with-cusp-dir= option. There is no 'include/' dir in that mode of > > install. > > > > Well isn't that what --with-cusp-include= is for? > > I even wouldn't object to being lenient, you mean detect all possible locations related to user specified --cups-dir option? This is a fine aproach - I guess we should fix cusp/thrust to do this. [i.e sean's option(1) ]. > but I don't think it makes sense to abuse the meaning of > --with-cusp-dir=. I don't see how the above is abusing --with-cusp-dir= option. --with-package-dir option - by definition is to specify the default install root dir of the given package. [assuming all packages default to PACKAGE_DIR/include is wrong]. > > Yes - currently the situation is not ideal. The ideal situation is > > folks install cusp thrust - the recommended way - i.e along with cuda > > in cuda includes. One has to do this with thrust anyway - otherwise > > nvcc will always pick up thrust bundled with cuda - and now what you > > specify with -I/path-to-thrust. Even if we sort out the previous issue - this conflict with default thrust will continue to exist [I'll say this as nvcc bug.] Satish > > The other problem currently with cusp/thrust is - we've been using dev > > snapshot of cusp/thrust for a while. I don't know if there is a > > release snapshot of these packages that we can switch to now [or not]. > > >

1 0