Problem with lsst_dm_stack_demo-11.0 under El Capitain

Support
#1

I would like to test my stack installation, I have tried to run the lsst_dm_stack_demo-11.0.
After

setup obs_sdss
```
bin/demo.sh gives:
```
Setting up: astrometry_net_data             Flavor: DarwinX86  Version: 
LOCAL:/Users/dadoun/LSST/lsst/lsst_dm_stack_demo-11.0/astrometry_net_data
Could not import lsstcppimport; please ensure the base package has been built 
(not just setup).
Traceback (most recent call last):
...
Referenced from: /Users/dadoun/LSST/lsst/DarwinX86/pex_policy/
2015_10.0-1-gd4eb80a+2/python/lsst/pex/policy/_policyLib.so
  Reason: image not found
```
Any idea ?
#2

v11.0 of the demo does not work on El Capitan. You need to use the version of demo that matches the release that you have installed. The most recent weekly has tagged the demo with the same tag. Since this is a pre-release you will need to clone the demo repository from github and checkout the corresponding tag for testing.

with tag w.2016.12.

#3

Thanks for your answer.
With lsst_dm_stack_demo-w.2016.12 I still have some problems :

Traceback (most recent call last):
  File "lsst/DarwinX86/pipe_tasks/
2015_10.0-5-g343945c/bin/processCcd.py", line 25, in <module>
    ProcessCcdTask.parseAndRun()
...
  File "lsst/DarwinX86/pex_config/2015_10.0-1-gc006da1+1/python/
lsst/pex/config/config.py", line 692, in __setattr__
    raise AttributeError
("%s has no attribute %s"%(_typeStr(self), attr))
AttributeError: lsst.pipe.tasks.processCcd.ProcessCcdConfig 
has no attribute loadSdssWcs
```
#4

The config parameter loadSdssWcs is from an outdated SDSS-specific version of processCcd.py called processSdssCcd.py. This looks like a version mismatch. Could you please post the results of eups list -s (after you set up for a run)? This shows all packages that are setup.

Also, please post bin/demo.sh from your version of lsst_dm_stack_demo, or at least the line that runs processCcd.py (approximately line 60).

#5

``èups list -s````

http://pastebin.com/PGQJacGL
line 60 from bin/demo.sh

processCcd.py input --id run=4192 filter=$FILTER_SET_4192
camcol=4 field=300 --id run=6377 filter=$FILTER_SET_6377
 camcol=4 field=399 --config 
calibrate.detectAndMeasure.doDeblend=False 
--output output$SIZE_EXT
#6

These packages are not from the w_2016_12 that you think you are using.

#7

You are right :slight_smile:
I have tried to install the good stack version:

eups distrib install -t w_2016_12 lsst_apps

During the mysql python I had this error:

[ 13/56 ]  mysqlpython 1.2.3.lsst1-1-g120147b+4 
***** error: from /Users/dadoun/LSST/lsst/EupsBuildDir/DarwinX86/mysqlpython-1.2.3.lsst1-1-g120147b+4/build.log
sh: mysql_config: command not found
Traceback (most recent call last):
File "setup.py", line 15, in <module>
...
```
It seems that mysql isn't present in the package unlike  the standard version ...
(I have tried to install my own mysql version but after I had some 'mysql/mysql.h' file not found problem during  daf_persistence installation)
#8

That is provided by the mariadbclient package which I assume built okay for you (and therefore EUPS setup should have placed that in the path). I haven’t seen that error before.

MariaDB is a drop in replacement for MySQL.

#9

I just tried building the stack on El Capitan and it seems to be working fine for me (10.11.4 with XCode 7.3):

$ source loadLSST.bash 
$ eups distrib install -t w_2016_12 lsst_apps
   [  1/56 ]  cfitsio 3360.lsst4                                         done. 
   [  2/56 ]  doxygen 1.8.5.lsst1 (already installed)                    done. 
   [  3/56 ]  eigen 3.2.5-1-g70497dd                                     done. 
   [  4/56 ]  fftw 3.3.4.lsst2                                           done. 
   [  5/56 ]  gsl 1.16.lsst3                                             done. 
   [  6/56 ]  mariadbclient 10.1.11-2-gd04d8b7                           done. 
   [  7/56 ]  minuit2 5.28.00.lsst2-1-gdae2fb7                           done. 
   [  8/56 ]  python 0.0.3 (already installed)                           done. 
   [  9/56 ]  python_d2to1 0.2.12.lsst1                                  done. 
   [ 10/56 ]  swig 3.0.2.lsst1                                           done. 
   [ 11/56 ]  xpa 2.1.15.lsst3                                           done. 
   [ 12/56 ]  boost 1.59.lsst5                                           done. 
   [ 13/56 ]  mysqlpython 1.2.3.lsst1-1-g120147b+4                       done. 
  [ 14/56 ]  numpy 0.0.2 ... 
             Using externally provided numpy v1.10.4.
   [ 14/56 ]  numpy 0.0.2                                                done. 
   [ 15/56 ]  pyyaml 3.11.lsst1                                          done. 
   [ 16/56 ]  scons 2.3.5 (already installed)                            done. 
   [ 17/56 ]  stsci_distutils 0.3.7-1-gb22a065+1                         done. 
   [ 18/56 ]  wcslib 5.13.lsst1                                          done. 
   [ 19/56 ]  astrometry_net 0.50.lsst2+6                                done. 
  [ 20/56 ]  matplotlib 0.0.2 ... 
             Using externally provided matplotlib v1.5.1.
   [ 20/56 ]  matplotlib 0.0.2                                           done. 
   [ 21/56 ]  pyfits 3.4.0+2                                             done. 
   [ 22/56 ]  sconsUtils 2016_01.0-4-g49bc714 (already installed)        done.
#10

I updated OS X and Xcode.
No the stack crash at

[ 33/56 ]  daf_persistence 2016_01.0-6-g27ca0e9

with this reason

ld: file not found: libz.1.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [python/lsst/daf/persistence/_persistenceLib.so] Error 1
scons: building terminated because of errors.

Do you have any idea ? Thank you.

#11

That was a mistake :smile: (see DM-5753).

I think a new weekly will be needed to fix that one. I’m a bit surprised because I thought DM-5595 fixed that specific problem (by telling mariadbclient not to look in the minconda library directory) but I am somewhat confused because looking back at my eups distrib install output it seems that it’s really installing commit d04d8b7 from 7 weeks ago but should be using 2ac29f1 from 3 weeks ago. I am unsure as to how the weekly from a couple of weeks back managed to miss that commit from 3 weeks back.

Sorry about that. @frossie can a new weekly be made sooner rather than later?

#12

Can you please try w_2016_15 weekly tag? That should have the mariadbclient fix.

#13

Everything works fine now, the stack (w_2016_15) and lsst_dm_stack_demo (w.2016.12).
Thank you very much :grinning:

#14

Fantastic. Although obviously the demo should also have the _15 tag (but it does indeed seem to be missing).