 |
 |
Jacek, > I noticed one more thing... imgserv is using by default this path > > /lsst7/releaseW13EP/ That's the repository it was configured for. You should be able to point that to your new STRIPE82L/v2 repository. If the path was hard-coded in the prototype, you'll need to change it. > and that is another 194GB. At this point I am totally lost. > > I generated some catalog based on a subset of > > /raid/lauren/rerun/LSST/STRIPE82L/v2 > > when producing the catalog I used something from _parent, We don't currently expect repositories to be moved or copied, in whole or in part. We don't have tooling for doing that. But you can do it manually. You need to move the parts that contain the data you want (which you did) as well as the parts that define the repository structure itself (currently _mapper). For certain dataset types, you also need the registry (registry.sqlite3). You don't need to copy the _parent symlink; that's just a way of dividing the "effective" repository into physical pieces. You also don't need to copy datasets that you're not using (like CALIB -- unless you want to access calibrations or reconstitute calexps from raw images). > That feels so convoluted I have no clue which subset I should > be copying over. K-T, do you know? Should I ask Laurie or Paul? Lauren, not Laurie. I think you're almost there. You may also need to modify the imgserv code/configuration to retrieve the proper dataset type (deepCoadd_calexp for /raid/lauren/... vs. deepCoadd for /lsst7/releaseW13EP). > Should I just give up and run the whole thing on lsst-dev? No, you shouldn't need to. -- Kian-Tat Lim, LSST Data Management, [log in to unmask] ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1