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

Re: [petsc-dev] Reminder planning release soon
by Jed Brown 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 3:48 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Likely some allegedly smart person figured -b is short for branch so > everyone will instinctively know that that -b means create a new branch. Of > course to new users who don't know git they would never think -b meant > create a new branch. The problem is that the developers of git have > absolutely no taste in user interface design and likely consider any time > spent thinking about user interface issues is wasted and just use the first > stupid thing that pops into their head. It is very common to want to create a new branch starting from a particular commit. What syntax would you suggest for this combination? Or leave it to the user to write their own alias that does both?

1 0

Re: [petsc-dev] Reminder planning release soon
by Barry Smith 20 Mar '13

20 Mar '13

For some bizarre reason, most likely to confuse new users, the git checkout -b name means git branch name (which makes a new branch) followed by git checkout name Likely some allegedly smart person figured -b is short for branch so everyone will instinctively know that that -b means create a new branch. Of course to new users who don't know git they would never think -b meant create a new branch. The problem is that the developers of git have absolutely no taste in user interface design and likely consider any time spent thinking about user interface issues is wasted and just use the first stupid thing that pops into their head. Barry On Mar 20, 2013, at 2:11 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > On Wed, Mar 20, 2013 at 2:01 PM, Paul Mullowney <paulm(a)txcorp.com> wrote: > Ok. Being a git novice, I don't know how to pull from my branch. I tried: > > git clone https://bitbucket.org/petsc/petsc.git/ > cd petsc > git checkout -b pm/aijcusparse-icc > > This created a new branch, but you want to check out an existing branch. > > To get yourself back in a "clean" state, use > > $ git checkout master > $ git branch -d pm/aijcusparse-icc > > Then checkout the existing branch using > > $ git checkout pm/aijcusparse-icc > > > Or, if you want to be more explicit, > > $ git checkout -b pm/aijcusparse-icc origin/pm/aijcusparse-icc > > > However, I don't see the changes which include the ICC functionality. What am I doing wrong? I also tried the following which didn't work. > git checkout -b remotes/origin/pm/aijcusparse-icc > > What am I doing wrong? > >

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Jed Brown 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 3:19 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > Yes, I know that this is a heavy operation. On the other hand, it only > occurs after a reconfigure, so it's not supposed to happen too often. > Anyway, with CUDA enabled I can deterministically reproduce the error in > `next`: > >gt; rm -rf PETSC_ARCH/CMake* > >gt; PETSC_ARCH/conf/reconfigure-**xxx.py # Fine, generates CMake > build > >gt; PETSC_ARCH/conf/reconfigure-**xxx.py # Fine, generates CMake > build > >gt; make ... all # compiles > >gt; PETSC_ARCH/conf/reconfigure-**xxx.py # Hangs, legacy fallback > > However, the problem does not show up without CUDA. > It would be friendly to track down the actual problem and report it as a bug for them to save in their tracker and close when there has been no action for years (and why is an infinite loop a problem anyway). ;-) I guess I would add this CUDA work-around to cmakeboot.py.

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Karl Rupp 20 Mar '13

20 Mar '13

Hi Jed, On 03/20/2013 02:09 PM, Jed Brown wrote: > > On Wed, Mar 20, 2013 at 2:03 PM, Karl Rupp <rupp(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > I also found that in some occasions one should issue > >gt; rm -rf PETSC_ARCH/CMake* > prior to running a reconfigure in order to circumvent a bug [1] in > CMake. > > @Jed, Matt: The current cmakeboot.py removes > PETSC_ARCH/CMakeFiles/{__version_string}, which does not seem to > even exist on my machine (CMake 2.8.7). Can we instead just delete > the whole CMakeFiles-folder and probably CMakeCache.txt? > > > AFAIK, the bug did not exist in earlier versions of CMake. I don't want > to delete all of CMakeFiles because it implies that _everything_ would > have to be recompiled after re-running cmakeboot.py. Yes, I know that this is a heavy operation. On the other hand, it only occurs after a reconfigure, so it's not supposed to happen too often. Anyway, with CUDA enabled I can deterministically reproduce the error in `next`: $> rm -rf PETSC_ARCH/CMake* $> PETSC_ARCH/conf/reconfigure-xxx.py # Fine, generates CMake build $> PETSC_ARCH/conf/reconfigure-xxx.py # Fine, generates CMake build $> make ... all # compiles $> PETSC_ARCH/conf/reconfigure-xxx.py # Hangs, legacy fallback However, the problem does not show up without CUDA. > Did you encounter another bug or just the one cited? I don't know yet what precisely is causing the problem. It may also be due to FindCUDA.cmake. > BTW, what sort of project introduces an infinite-loop bug in a subminor > release and then is incredulous that you would expect to be able to run > the tool more than once? How dare you actually try to really *use* the tool? ;-) Best regards, Karli

1 0

Re: [petsc-dev] Add natural-to-global and global-to-natural operations for DM?
by Matthew Knepley 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 9:49 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Richard, > > Once you have the vector in the "natural order" what do you do with > it? > Also, I am not sure that making an ordering is the best way to do this. I just do it on the fly for Plex when outputting to VTK. Matt > 1) visualize it? > 2) store to disk? > 3) send to one process so you can do something on it? > 3) ??? > > Note that VecView() on DMDA vectors automatically manage the mapping > to natural ordering when saving to disk so the user does not ever need to > apply globaltonatural themselves. > > I would argue that the only "legitimate" use of > DMDAGlobalToNatural/NaturalToGlobal() is for IO (or similarly transferring > a DMDA vector between two MPI communicators of different sizes) so my > inclination is to make DMDAGlobalToNatural() less public, not bring it down > to the DM level. > > If you are using GlobalToNatural in your IO I would argue that better > approach is to imbed the mapping inside the VecLoad and VecView for your DM > unstructured then you do not need need a universal DMGlobalToNatural(); > > I do not object to a DMLocalToLocalBegin/End(), though local is not > universal we do have the local concept at the DM level already and it will > remain there. > > Barry > > > > On Mar 19, 2013, at 9:54 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> wrote: > > > Hi Barry, > > > > What we call the "natural" ordering in PFLOTRAN is what is referred to > as the "application" ordering in PETSc parlance. In the structured grid > case this "application" ordering is the natural ordering used by the DMDA > routines like DMDANaturalToGlobalBegin()/End(), and in the unstructured > case it is whatever ordering was used to assign cell IDs when the > unstructured grid was created. Rather than having code for two cases, I > would prefer to be able to just call DMNaturalToGlobalBegin()/End() for > either case. I do realize, of course, that for the DMDA case there is > always a default meaning for the "natural" ordering, whereas for the case > of a general DM the notion of "natural" will be application dependent and > will have to be specified by user code (which I'd like to do in this case > by having a DMShellSetNaturalToGlobalVecScatter()). > > > > Obviously, there may be subtypes of DM for which no "natural to global" > operation makes sense. What I'm saying is that I nonetheless would like to > have a general DMNaturalToGlobalBegin()/End() that will do the appropriate > thing if it makes sense for that DM and complain otherwise. I guess this > is a question of what the PETSc philosophy is regarding such things. I > note that there is at least one example of a current DMDA method that ought > to just be a DM one: I don't see why we should have > DMDALocalToLocalBegin()/End() and not just DMLocalToLocalBegin()/End(), and > I'd like to go ahead and change this. But LocalToLocal makes sense for > lots of DMs, and NaturalToGlobal may not. > > > > --Richard > > > > On 3/7/13 10:51 PM, Barry Smith wrote: > >> On Mar 7, 2013, at 9:46 PM, Richard Tran Mills <rtm(a)eecs.utk.edu> > wrote: > >> > >>> Continuing on my quest to be able to wrap all of the unstructured grid > operations in PFLOTRAN inside a DM: Would it be OK to add > DMGlobalToNaturalBegin()/End() and DMNatualToGlobalBegin()/End()? These are > currently DMDA routines, not DM ones. We do something that we call > natural-to-global and global-to-natural operations with our unstructured > grid cases in PFLOTRAN (though I'm not sure if "natural" is quite the thing > to call it... I always think of that in terms of a structured grid layout). > I would like to just call DMGlobalToNaturalBegin()/End(), etc., on our DM, > whether it is a DMDA or a DMShell. > >>> > >>> I had already mentioned that I plan to add DM interface routines for > local-to-local operations. I am thinking that global-to-natural, etc., > also ought to be added, though I'm not sure if the concept of "natural" > ordering necessarily makes sense in some cases. > >> What does natural mean for you on anything but a DA in what you do > with pflotran? Once we all understand than we can come up with ideas on how > that fits with DM. > >> > >> Barry > >> > >>> --Richard > >>> > >>> -- > >>> Richard Tran Mills, Ph.D. > >>> Computational Earth Scientist | Joint Assistant Professor > >>> Hydrogeochemical Dynamics Team | EECS and Earth & Planetary > Sciences > >>> Oak Ridge National Laboratory | University of Tennessee, Knoxville > >>> E-mail: rmills(a)ornl.gov V: 865-241-3198 > http://climate.ornl.gov/~rmills > >>> > > > > > > -- > > Richard Tran Mills, Ph.D. > > Computational Earth Scientist | Joint Assistant Professor > > Hydrogeochemical Dynamics Team | EECS and Earth & Planetary Sciences > > Oak Ridge National Laboratory | University of Tennessee, Knoxville > > E-mail: rmills(a)ornl.gov V: 865-241-3198 http://climate.ornl.gov/~rmills > > > > -- 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: [petsc-dev] Reminder planning release soon
by Jed Brown 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 2:01 PM, Paul Mullowney <paulm(a)txcorp.com> wrote: > Ok. Being a git novice, I don't know how to pull from my branch. I tried: > > git clone https://bitbucket.org/petsc/petsc.git/ > cd petsc > git checkout -b pm/aijcusparse-icc > This created a new branch, but you want to check out an existing branch. To get yourself back in a "clean" state, use $ git checkout master $ git branch -d pm/aijcusparse-icc Then checkout the existing branch using $ git checkout pm/aijcusparse-icc Or, if you want to be more explicit, $ git checkout -b pm/aijcusparse-icc origin/pm/aijcusparse-icc > > However, I don't see the changes which include the ICC functionality. What > am I doing wrong? I also tried the following which didn't work. > git checkout -b remotes/origin/pm/aijcusparse-icc > > What am I doing wrong? >

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Jed Brown 20 Mar '13

20 Mar '13

On Wed, Mar 20, 2013 at 2:03 PM, Karl Rupp <rupp(a)mcs.anl.gov> wrote: > I also found that in some occasions one should issue > >gt; rm -rf PETSC_ARCH/CMake* > prior to running a reconfigure in order to circumvent a bug [1] in CMake. > > @Jed, Matt: The current cmakeboot.py removes PETSC_ARCH/CMakeFiles/{**version_string}, > which does not seem to even exist on my machine (CMake 2.8.7). Can we > instead just delete the whole CMakeFiles-folder and probably CMakeCache.txt? > AFAIK, the bug did not exist in earlier versions of CMake. I don't want to delete all of CMakeFiles because it implies that _everything_ would have to be recompiled after re-running cmakeboot.py. Did you encounter another bug or just the one cited? BTW, what sort of project introduces an infinite-loop bug in a subminor release and then is incredulous that you would expect to be able to run the tool more than once?

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Karl Rupp 20 Mar '13

20 Mar '13

Hi Dave, I also found that in some occasions one should issue $> rm -rf PETSC_ARCH/CMake* prior to running a reconfigure in order to circumvent a bug [1] in CMake. @Jed, Matt: The current cmakeboot.py removes PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even exist on my machine (CMake 2.8.7). Can we instead just delete the whole CMakeFiles-folder and probably CMakeCache.txt? Best regards, Karli [1] http://www.mail-archive.com/[email protected]/msg44765.html On 03/20/2013 10:17 AM, Nystrom, William D wrote: > Hi Karli, > > I ran a test build last night and it failed. It was a relatively simple configuration where > I was downloading mpich and cmake and building with threads, cuda and the txpetscgpu > package. I was building on a Fedora 17 machine with Cuda 5. The failure seem to be > associated with cmake. When I get home this evening, I could send you the configure > and make logs. I did not have time this morning before leaving for work. I wanted to > give you some early feedback even though the logs will have to wait till this evening. > > Thanks, > > Dave > > -- > Dave Nystrom > LANL HPC-5 > Phone: 505-667-7913 > Email: wdn(a)lanl.gov > Smail: Mail Stop B272 > Group HPC-5 > Los Alamos National Laboratory > Los Alamos, NM 87545 > > > ________________________________________ > From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > Sent: Tuesday, March 19, 2013 4:04 PM > To: petsc-dev(a)mcs.anl.gov > Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready > > Hi Dave, > > perfect, thanks! > I should add that a reconfigure is needed. It won't work with re-running > make only. > > Best regards, > Karli > > > On 03/19/2013 04:59 PM, Nystrom, William D wrote: >> Hi Karli, >> >> I will try this soon and report back when I have results. >> >> Thanks, >> >> Dave >> >> ________________________________________ >> From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] >> Sent: Tuesday, March 19, 2013 3:58 PM >> To: For users of the development version of PETSc >> Subject: [petsc-dev] CMake-assisted CUDA builds ready >> >> Dear all, >> >> I just merged the CMake-based builds for CUDA-packages into 'next', >> reducing compilation times considerably compared to the old legacy >> builds. While the legacy builds print something like >> 'libfast in <DIR>' >> the new CMake-based builds print the usual percentage counters in front. >> >> Any feedback on the proper functionality (both positive and negative) >> are appreciated. >> >> Thanks and best regards, >> Karli >> >

1 0

Re: [petsc-dev] Reminder planning release soon
by Paul Mullowney 20 Mar '13

20 Mar '13

Ok. Being a git novice, I don't know how to pull from my branch. I tried: git clone https://bitbucket.org/petsc/petsc.git/ cd petsc git checkout -b pm/aijcusparse-icc However, I don't see the changes which include the ICC functionality. What am I doing wrong? I also tried the following which didn't work. git checkout -b remotes/origin/pm/aijcusparse-icc What am I doing wrong? -Paul > On Wed, Mar 20, 2013 at 10:05 AM, Paul Mullowney <paulm(a)txcorp.com > <mailto:[email protected]>> wrote: > > Is my aijcusparse-icc branch going to get merged into next? Do I > need to do this? Do I have permissions? > > > Looking at our previous discussion, there were still a number of > points that were commented on in the email thread, but not addressed. > You didn't send an updated patch or a new pull request. > > I put what you had in a branch here, and fixed a couple more things. > You should checkout this branch and make sure all points from the > email thread have been addressed. Then push it to your fork and make a > pull request. We'll comment on the pull request if anything else is > needed, otherwise we'll merge it into 'next'. > > https://bitbucket.org/petsc/petsc/compare/pm/aijcusparse-icc..master#diff > > Thanks, > -Paul > > This is a reminder that we are planning a release soon > thus one should start testing and moving completed work over > to the git next branch for nightly testing and then on to master. > > Barry > > >

1 0

Re: [petsc-dev] CMake-assisted CUDA builds ready
by Karl Rupp 20 Mar '13

20 Mar '13

Hi Dave, thanks for the first piece of feedback. I'll wait for the logs in order to get an idea whether BuildSystem, FindCUDA.cmake, or any other component is causing the troubles. Best regards, Karli On 03/20/2013 10:17 AM, Nystrom, William D wrote: > Hi Karli, > > I ran a test build last night and it failed. It was a relatively simple configuration where > I was downloading mpich and cmake and building with threads, cuda and the txpetscgpu > package. I was building on a Fedora 17 machine with Cuda 5. The failure seem to be > associated with cmake. When I get home this evening, I could send you the configure > and make logs. I did not have time this morning before leaving for work. I wanted to > give you some early feedback even though the logs will have to wait till this evening. > > Thanks, > > Dave > > -- > Dave Nystrom > LANL HPC-5 > Phone: 505-667-7913 > Email: wdn(a)lanl.gov > Smail: Mail Stop B272 > Group HPC-5 > Los Alamos National Laboratory > Los Alamos, NM 87545 > > > ________________________________________ > From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] > Sent: Tuesday, March 19, 2013 4:04 PM > To: petsc-dev(a)mcs.anl.gov > Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready > > Hi Dave, > > perfect, thanks! > I should add that a reconfigure is needed. It won't work with re-running > make only. > > Best regards, > Karli > > > On 03/19/2013 04:59 PM, Nystrom, William D wrote: >> Hi Karli, >> >> I will try this soon and report back when I have results. >> >> Thanks, >> >> Dave >> >> ________________________________________ >> From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Karl Rupp [rupp(a)mcs.anl.gov] >> Sent: Tuesday, March 19, 2013 3:58 PM >> To: For users of the development version of PETSc >> Subject: [petsc-dev] CMake-assisted CUDA builds ready >> >> Dear all, >> >> I just merged the CMake-based builds for CUDA-packages into 'next', >> reducing compilation times considerably compared to the old legacy >> builds. While the legacy builds print something like >> 'libfast in <DIR>' >> the new CMake-based builds print the usual percentage counters in front. >> >> Any feedback on the proper functionality (both positive and negative) >> are appreciated. >> >> Thanks and best regards, >> Karli >> >

1 0