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.
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 <[email protected]> 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
>
>
>
>
>
>
>
