{5} Accepted, Active Tickets by Owner (Full Description) (8 matches)
List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.
eugene (4 matches)
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1090 | psphot should use weight map in calculating background | psphot | defect | 18 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
psphot currently appears to not use the weight map in calculating the background. I was using it on some warped images (warped using SWarp as part of the standard ESSENCE reduction pipeline) where the edges were unfilled and thus represented in the variance map as 1e30. But the background map appears to have fit including those areas. Is this the correct behavior? Did I misinterpret how the background is being fit? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1233 | detselect logic is wrong in some cases | ippTools | defect | 17 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
detselect generates SQL that does not really make sense for the following cases:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1463 | RA and Dec empty in psphotForced (PS1_DV2) | psphot | defect | 15 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The RA and Dec columns are empty in psphotForced-generated PS1_DV2 files. I've run psphot on an image and RA and Dec are populated in the PS1_V3 file, but they are not populated in the psphotForced PS1_DV2 file. This has been reported by Ken Smith over email. Specifically I'm running in Gene's branch psphot version: branches/eam_branches/ipp-20101205/psphot@30492 psphot source: 60eb6cdc-a59c-4636-a4e0-dba66a9721fd but Ken's report would have been from the production branch. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1192 | Why is psphot dependent on libmysql? | psphot | enhancement | 17 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I just had a case where there was a problem with the mysql installation on one of the nodes on a cluster and psphot refused to run. Conceptually this seems wrong. psphot shouldn't know anything about libmysql. Why is it required? I specifically ask because libmsysql is one of the things people have the most trouble compiling and if we'd like the tools in IPP to be as widely used as possible it would be nice to strip mysql and other related functionality that make sense in the standard IPP installation but not just for someone who wants to do photometry. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
heather (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1294 | extsrc/gpcsw requires ginstall | misc | defect | 17 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The new gpcsw package requires ginstall. Is it using anything in particular that's only in ginstall or is standard install fine? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Paul Price (2 matches) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1218 | Debugging ppSub: option to save stamp position used to determine the kernel | ppSub | enhancement | 17 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
One of the key elements of difference imaging is the choice of stamps used to determine the kernel. For debugging and testing, it is important to know: #1 which stamps were rejected #2 which stamps were used #3 all possible stamps (used, rejected, and unused) This information (in particular the x,y position, but also other info liek the reason why a stamp was rejected) could be saved in files, either straight ASCII tables or alternatively ds9 region files. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1243 | Problem with 'sed' again in parsing SVN version info | psconfig | defect | 17 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
/usr/bin/sed -e "s|@PSLIB_VERSION@|\" sed: 1: "/Repository Root:/ { x; ...": extra characters at the end of p command svn: Write error: Broken pipe on Mac OS X 10.5.6, Intel |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
watersc1 (1 match) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1375 | nebulous replication left an empty file behind | Nebulous | defect | 16 years ago | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When updating a chip imfile today I ran into a case where it failed because the burntool table had zero size. This is strange since the file existed at one time since the chip processing had completed successfully once. Investigating further we found that there were two instances. One of which had zero size. This seems to indicate that the replication process failed and left a file behind. For reference the file was neb://ipp042.0/gpc1/20100118/o5214g0235o/o5214g0235o.ota22.burn.tbl I have fixed the zero sized file by copying the good one on top of it. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
