I suggest we embed in the PETSc library a mechanism that does not allow an
untested PETSc code to be run on machines like BlueGene and Cray (or even if
possible clusters with batch systems). After a program has been successfully
run a number of times on an easy to use machine (including
Reran ./configure but then cmake made me trouble. Sending the configure.log
only to Jed
Barry
xxx=xxx
Configure stage complete. Now build PETSc libraries with:
make PETSC_DIR=/Users/barrysmith/Src/petsc-dev
/pipermail/petsc-dev/attachments/20110708/ea1192df/attachment.html
?
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110708/aa5fde68/attachment.html
Seems to have worked, thanks.
Barry
On Jul 8, 2011, at 3:54 PM, Jed Brown wrote:
On Fri, Jul 8, 2011 at 14:28, Barry Smith bsmith at mcs.anl.gov wrote:
cd /Users/barrysmith/Src/petsc-dev; make -j2 -C
/Users/barrysmith/Src/petsc-dev/arch-gnu
Scanning dependencies of target petsc
Jed,
Are we planning on making the VecScatter the communications central for
PETSc?
I can add a VecScatterGetFromRank() (ugly name) that returns the rank for
each received entry; there might be enough information to do this without any
additional communication. There could
I am revisiting the idea of a new configuration/compile system for PETSc
(with the prototype cll: ssh://petsc at petsc.cs.iit.edu//hg/petsc/cll) and am
currently trying to see if we can come up with a list of requirements that
satisfies all our needs and everyone's ambitions. I have added
/pipermail/petsc-dev/attachments/20110708/a2b7d1bc/attachment.html
When you say Portability to Windows, do you mean native Windows,
without Cygwin?
I agree that cmake is less than cool.
Suppose there is a package we need already installed on the system
(e.g., hdf5 installed in hdf5_dir),
which depends on another package we need, which is also already
installed
