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

Re: [petsc-dev] MPI_Exscan
by Barry Smith 28 Jul '11

28 Jul '11

Ideally code like #if defined(PETSC_HAVE_MPI_EXSCAN) cool C code that uses MPI_EXSCAN #else less cool C code that uses something else in MPI that is in MPI 1 #endif less ideal but ok code #if defined(PETSC_HAVE_MPI_EXSCAN) cool C code that uses MPI_EXSCAN #else SETERRQ(..., "Sorry but this code requires MPI_EXSCAN that doesn't exist on your machine's version of MPI, install a MPI2 with PETSc to get this functionality") #endif Then to make sure PETSC_HAVE_MPI_EXSCAN gets defined when it can add a test for MPI_Exscan() to bottom of config/BuildSystem/config/packages/MPI.py with the other tests for MPI to functions PETSc only requires MPI 1.1 support so any 2.0 or later stuff used needs this kind of protection. Barry On Jul 28, 2011, at 2:24 PM, Mark F. Adams wrote: > Dumb question: How do you protect it? > Mark > > On Jul 28, 2011, at 3:05 PM, Barry Smith wrote: > >> >> On Jul 28, 2011, at 11:55 AM, Jose E. Roman wrote: >> >>> We are getting an undefined reference `MPI_Exscan'. This function is used in src/mat/impls/nest/matnest.c. >>> If I am not wrong, MPI_Exscan was introduced in MPI-2 but was not available in the previous standard. Apparently, the machine where we are compiling is very old and has MPI-1 only. >>> >>> I guess there should be a PETSC_HAVE_MPI_EXSCAN test in configure. >> >> Correct, whoever used that MPI 2 function in PETSc is obligated to protect it. >> >> Barry >> >> >>> >>> Jose >>> >> >> >

1 0

Re: [petsc-dev] MPI_Exscan
by Mark F. Adams 28 Jul '11

28 Jul '11

Dumb question: How do you protect it? Mark On Jul 28, 2011, at 3:05 PM, Barry Smith wrote: > > On Jul 28, 2011, at 11:55 AM, Jose E. Roman wrote: > >> We are getting an undefined reference `MPI_Exscan'. This function is used in src/mat/impls/nest/matnest.c. >> If I am not wrong, MPI_Exscan was introduced in MPI-2 but was not available in the previous standard. Apparently, the machine where we are compiling is very old and has MPI-1 only. >> >> I guess there should be a PETSC_HAVE_MPI_EXSCAN test in configure. > > Correct, whoever used that MPI 2 function in PETSc is obligated to protect it. > > Barry > > >> >> Jose >> > >

1 0

Re: [petsc-dev] MPI_Exscan
by Barry Smith 28 Jul '11

28 Jul '11

On Jul 28, 2011, at 11:55 AM, Jose E. Roman wrote: > We are getting an undefined reference `MPI_Exscan'. This function is used in src/mat/impls/nest/matnest.c. > If I am not wrong, MPI_Exscan was introduced in MPI-2 but was not available in the previous standard. Apparently, the machine where we are compiling is very old and has MPI-1 only. > > I guess there should be a PETSC_HAVE_MPI_EXSCAN test in configure. Correct, whoever used that MPI 2 function in PETSc is obligated to protect it. Barry > > Jose >

1 0

MPI_Exscan
by Jose E. Roman 28 Jul '11

28 Jul '11

We are getting an undefined reference `MPI_Exscan'. This function is used in src/mat/impls/nest/matnest.c. If I am not wrong, MPI_Exscan was introduced in MPI-2 but was not available in the previous standard. Apparently, the machine where we are compiling is very old and has MPI-1 only. I guess there should be a PETSC_HAVE_MPI_EXSCAN test in configure. Jose

1 0

Re: [petsc-dev] [petsc-maint #80119] Re: make install broken on unix?
by Jed Brown 25 Jul '11

25 Jul '11

On Mon, Jul 25, 2011 at 10:16, Ethan Coon <ecoon(a)lanl.gov> wrote: > It's not really a stand-alone script though, so it shouldn't get the > hashbang or lose the extension. But it's not a full-fledged package of > libraries either. I don't think it should be anywhere in the default path > -- it's the kind of code that you should have to explicitly include (either > via sys.path manipulation or via PYTHONPATH) because too many little scripts > of utility code makes for a nasty, polluted namespace. There just isn't a > good place (that I know of) in the standard file system hierarchy for this > kind of stuff. Making the user/scripts do manual sys.path or PYTHONPATH manipulation makes it nearly impossible to make portable scripts that depend on these functions. Should we start a "proper" Python package containing PETSc utilities? Then scripts could rely on from petsc.io import binary_read or whatever working. Of course it might only contain two functions right now, but I could add my "petscplot" (makes various types of convergence and scaling plots from convergence monitors and -log_summary output), and I'm sure the community has other useful scripts.

1 0

Re: [petsc-dev] [petsc-maint #80119] Re: make install broken on unix?
by Sean Farley 25 Jul '11

25 Jul '11

> > Because directories are a useful way to organize categories of software > (for example the bin/matlab directory has all the Matlab scripts). Why not > just not use subdirectories in PETSc and just stick all PETSc files directly > into the PETSc root directory? Sorry, I wasn't clear. I meant when doing a prefix install. Sean

1 0

Re: [petsc-dev] [petsc-maint #80119] Re: make install broken on unix?
by Ethan Coon 25 Jul '11

25 Jul '11

On Mon, 2011-07-25 at 17:06 +0000, Matthew Knepley wrote: > On Mon, Jul 25, 2011 at 4:56 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > I disagree with this completely. There's a tendency > to think of everything python as a package -- this is > NOT a package. It has no __init__.py, it has no > __all__, it has no submodules, and it doesn't need any > of that. It simply does a one-off task -- it's bits > of code to be used in a script. Putting this sort of > code in site-packages is what makes site-packages the > nightmare of ignored dependencies and overlapping > versions it is today. > > If you want to make it into a package, you're welcome > to do so. With that includes registration with the > cheeseshop to make sure the namespace is unique, > placing the single file within a folder that includes > an __init__ (and then likely just gets imported within > that __init__), writing a setup.py, etc etc. It's > just complete overkill. > > > Then why put it in bin/python at all? Just drop the .py > extension and put it in bin (with a 'correct' [whatever that > may be] python hashbang)? > > > I am for this, although I do not give a crap what the extension is. > Barry didn't want it in bin if it was going to have multiple files. Maybe it should just go in bin/PetscBinaryIO.py and when I get around to adding the "write" functionality it can be included in the same file? It's not really a stand-alone script though, so it shouldn't get the hashbang or lose the extension. But it's not a full-fledged package of libraries either. I don't think it should be anywhere in the default path -- it's the kind of code that you should have to explicitly include (either via sys.path manipulation or via PYTHONPATH) because too many little scripts of utility code makes for a nasty, polluted namespace. There just isn't a good place (that I know of) in the standard file system hierarchy for this kind of stuff. Ethan > > Matt > > Sean > > > > -- > 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 -- ------------------------------------ Ethan Coon Post-Doctoral Researcher Applied Mathematics - T-5 Los Alamos National Laboratory 505-665-8289 http://www.ldeo.columbia.edu/~ecoon/ ------------------------------------

1 0

Re: [petsc-dev] [petsc-maint #80119] Re: make install broken on unix?
by Barry Smith 25 Jul '11

25 Jul '11

On Jul 25, 2011, at 12:06 PM, Matthew Knepley wrote: > On Mon, Jul 25, 2011 at 4:56 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > I disagree with this completely. There's a tendency to think of everything python as a package -- this is NOT a package. It has no __init__.py, it has no __all__, it has no submodules, and it doesn't need any of that. It simply does a one-off task -- it's bits of code to be used in a script. Putting this sort of code in site-packages is what makes site-packages the nightmare of ignored dependencies and overlapping versions it is today. > > If you want to make it into a package, you're welcome to do so. With that includes registration with the cheeseshop to make sure the namespace is unique, placing the single file within a folder that includes an __init__ (and then likely just gets imported within that __init__), writing a setup.py, etc etc. It's just complete overkill. > > Then why put it in bin/python at all? Just drop the .py extension and put it in bin (with a 'correct' [whatever that may be] python hashbang)? Because directories are a useful way to organize categories of software (for example the bin/matlab directory has all the Matlab scripts). Why not just not use subdirectories in PETSc and just stick all PETSc files directly into the PETSc root directory? Barry > > I am for this, although I do not give a crap what the extension is. > > Matt > > Sean > > > > -- > 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] [petsc-maint #80119] Re: make install broken on unix?
by Matthew Knepley 25 Jul '11

25 Jul '11

On Mon, Jul 25, 2011 at 4:56 PM, Sean Farley <sean(a)mcs.anl.gov> wrote: > I disagree with this completely. There's a tendency to think of everything >> python as a package -- this is NOT a package. It has no __init__.py, it has >> no __all__, it has no submodules, and it doesn't need any of that. It >> simply does a one-off task -- it's bits of code to be used in a script. >> Putting this sort of code in site-packages is what makes site-packages the >> nightmare of ignored dependencies and overlapping versions it is today. >> >> If you want to make it into a package, you're welcome to do so. With that >> includes registration with the cheeseshop to make sure the namespace is >> unique, placing the single file within a folder that includes an __init__ >> (and then likely just gets imported within that __init__), writing a >> setup.py, etc etc. It's just complete overkill. > > > Then why put it in bin/python at all? Just drop the .py extension and put > it in bin (with a 'correct' [whatever that may be] python hashbang)? > I am for this, although I do not give a crap what the extension is. Matt > Sean > -- 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] [petsc-maint #80119] Re: make install broken on unix?
by Sean Farley 25 Jul '11

25 Jul '11

> > I disagree with this completely. There's a tendency to think of everything > python as a package -- this is NOT a package. It has no __init__.py, it has > no __all__, it has no submodules, and it doesn't need any of that. It > simply does a one-off task -- it's bits of code to be used in a script. > Putting this sort of code in site-packages is what makes site-packages the > nightmare of ignored dependencies and overlapping versions it is today. > > If you want to make it into a package, you're welcome to do so. With that > includes registration with the cheeseshop to make sure the namespace is > unique, placing the single file within a folder that includes an __init__ > (and then likely just gets imported within that __init__), writing a > setup.py, etc etc. It's just complete overkill. Then why put it in bin/python at all? Just drop the .py extension and put it in bin (with a 'correct' [whatever that may be] python hashbang)? Sean

1 0