This will add the executables folder to the users PATH when the package is set up. Should also migrate to bin.src.

My first attempt to read in the Run3 First40 data sadly ended in failure. I believe the problem was due to my running in a directory where I didn't have write access. I lost the error message, but it was definitely complaining about write permissions. However, writing to the DB seems to have worked, but it was incomplete since the ingest failed in the middle.
I've since re-run the ingest successfully using another project name: "Twinkles Run3 First40 Redo" and that looks ok as far as I know.
I'd like to go back and remove the first attempt "Twinkles Run3 First40" - but at heart I'm a chicken.. and maybe it is fine to leave it. So I'm filing this issue and will confer with @jchiang87 when he returns.

This will enable user-defined tables, queries, etc..

@jbkalmbach needs to use Pserv for his SL investigtaions in Twinkles, so can help write a note that a) introduces the software and b) shows it working in practice. Let's write this as an ipynb format Note, in its own branch.

The code is currently just writing the values directly from the forced source catalogs which have units of DN.

@drphilmarshall Can you please expand the README.md and add any other documentation that's appropriate at this point? I'll add code, etc. over the next few days. Thanks!

I tried to setup a cloned copy of pserv on cori after setting up the stack and got the following:

brycek@cori12:~> source pserv/setup/setup.sh 
eups declare: I'm unable to declare Pserv as tablefile ups/Pserv.table does not exist
Unable to find an acceptable version of Pserv

When I went into the setup script and changed the Pserv to pserv throughout then it worked. Is there a reason we have them capitalized? But I've definitely set this up before on my own computer and not had that problem, so I'm not sure if it's something specific about cori?

Currently, only the object id, coord_ra, coord_dec, and parent are being extracted from the coadd catalog files. In particular, it would be good to know which objects have non-null fluxes for any given band.

Admittedly this was my first attempt to use the load_db.py script, however I ran into a problem trying to use the --dry_run parameter. I was using the Twinkles Run3 First40 data in: /global/cscratch1/sd/desc/twinkles/work/4/output
Later I was able to run the ingest after I gave up trying to use the --dry_run to test things out. Was I doing something wrong? Or were my expectations about "dry_run" inappropriate?

Ingest registry file /global/cscratch1/sd/desc/twinkles/work/4/output/_parent/registry.sqlite3                                                                      
Ingest calexp info
Ingest object catalog output/deepCoadd-results/merged/0/0,0/ref-0-0,0.fits
Processing band u for 0 visits.
Processing band g for 10 visits.
Processing v250-fg R2,2 S1,1
Traceback (most recent call last):
 File "/global/common/cori/contrib/lsst/pserv/20161111/pserv/bin/load_db.py", line 104, in <module>
   dry_run=args.dry_run)
 File "/global/common/cori/contrib/lsst/pserv/20161111/pserv/bin/load_db.py", line 38, in ingest_forced_catalogs
   lambda c: [x[0] for x in c][0])
 File "/global/common/cori/contrib/lsst/pserv/20161111/pserv/python/desc/pserv/Pserv.py", line 91, in apply
   results = cursorFunc(cursor)
 File "/global/common/cori/contrib/lsst/pserv/20161111/pserv/bin/load_db.py", line 38, in <lambda>
   lambda c: [x[0] for x in c][0])
IndexError: list index out of range```

This will ordinarily be done via the bin/load_db.py script.

I noticed these when I was reading the code to understand how the bit packing works and following along testing some of the things with my Python 3 interpreter. I just wanted to note them here for future reference.

• zip is now an iterator
• long() no longer exists.