[petsc-dev] Show download URL

Matthew Knepley knepley at gmail.com
Fri Feb 14 03:11:28 CST 2014


On Feb 13, 2014 9:59 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
>
>
>   Damn, damn, damn, and this was a known problem but both Satish and I
now have grey hair and terrible memory! This is a screwup on our part, we
did not properly institutionalize our knowledge by imbedding it into the
code.
>
>   I have pushed to maint and next two changes
>
> 1) When using the Sandia tar ball you will now get
>
> ~/Src/petsc  barry/fix-chaco $ ./configure
--download-chaco=/Users/barrysmith/Downloads/Chaco-2.2.tar.gz
--download-mpich
>
===============================================================================
>              Configuring PETSc to compile on your system
>
===============================================================================
>
===============================================================================

                                                Compiling chaco; this may
take several minutes


 ===============================================================================

                                          TESTING: check from
config.libraries(config/BuildSystem/config/libraries.py:145)


 *******************************************************************************
>          UNABLE to CONFIGURE with GIVEN OPTIONS    (see configure.log for
details):
>
-------------------------------------------------------------------------------
> You cannot use Chaco package from Sandia as it contains an incorrect
ddot() routine that conflicts with BLAS
> Use --download-chaco
>
*******************************************************************************
>
> 2)  Your first request. ./configure will print the location of the
download tar ball it is getting before trying to get it
>
> ~/Src/petsc  barry/fix-chaco $ ./configure --download-chaco
--download-mpich
>
===============================================================================
>              Configuring PETSc to compile on your system
>
===============================================================================
>
===============================================================================

                                                Trying to download
http://ftp.mcs.anl.gov/pub/petsc/externalpackages/Chaco-2.2-p1.tar.gz for
CHACO

 ===============================================================================


===============================================================================

                                                Compiling chaco; this may
take several minutes
>
>
> Your second request is harder, configure doesn't know everything it is
doing in advance (before it has successfully done everything up to that
point) so just getting ./configure to dump the locations of all the tar
balls is not trivial. The easiest way is with
>
> grep "self.download " config/PETSc/packages/*.py
>
>   I'm sorry we wasted so much of your time and embarrassed ourselves in
front of the important company.

I should have fixed the download mechanism long ago. The logic for
retrieval can be moved to setup() so it is done on the fast first pass.

   Matt
>   Barry
>
> Needless to say their refusal to give access to the internet from their
"HPC" systems is a silly non-productive way of trying to protect their
(probably worthless anyway) IP and much better strategies can be used to
protect themselves.
>
>
> On Feb 13, 2014, at 9:33 AM, Blaise A Bourdin <bourdin at lsu.edu> wrote:
>
> > Hi,
> >
> > I recently came across an issue with a segfault in ddot. It turns out
that the problem was not at all in petsc, but rather that the machine I was
compiling PETSc from had no direct access to the internet (quite common in
industry HPC clusters), and that the admin was downloading chaco from
sandia directly instead of the patched tarball hosted on petsc servers. (I
could also elaborate on the sanity of redefining ddot in a LIBRARY...)
> >
> > This brings my first request: the chaco tarball on MCS and sandia have
the same name. Would it make sense to clearly indicate when a packaged
hosted by petsc is different from the upstream package? It would have made
it clear from the beginning that the admin was not using the PETSc patched
tarball.
> >
> > Secondly: right now, short of knowing that the url are in the python
config files in $PETSC_DIR/config/PETSc/packages (or
config/BuildSYstem/config/packages, for some reason), the workflow to
download packages on a machine with no direct internet access is to
configure with --download-coolpackage, wait a long time for configure to
run, wait until download fails, and a message
> > Unable to download package Chaco from:
http://ftp.mcs.anl.gov/pub/petsc/externalpackages/coolpackage.tar.gz
> > to pop up
> >
> > Would it be possible to
> > 1. print the download url _before_ trying to download a package
> > 2. add a configure options that would print the url of all packages for
which a download has been requested?
> >
> > Not understanding the logic of BuildSystem, I don't know if 2. is even
possible, but it sure would be nice...
> >
> >
> > Regards,
> >
> > Blaise
> >
> > --
> > Department of Mathematics and Center for Computation & Technology
> > Louisiana State University, Baton Rouge, LA 70803, USA
> > Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276
http://www.math.lsu.edu/~bourdin
> >
> >
> >
> >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140214/65e154e8/attachment.html>


More information about the petsc-dev mailing list