On 19 January 2011 19:06, Tim Jenness <[log in to unmask]> wrote:
> On Jan 19, 2011, at 6:00 AM, Malcolm J. Currie wrote:
>
>> After numerous attempts interrupted by networks and failing drives I finally was able to complete a big run of ORAC-DR applying the ARY changes. Before these I was either filling the hard drive or exhausting HDS resources. By completion kappa_mon generates a 1.3G scratch file (i.e. a few thousand times smaller), smurf_mon a 0.9G scratch, but cupid_mon that's relatively lightly used by the recipe accretes to 25G. This appears to grow on each iteration, so I wonder if there is something in CUPID hanging on to scratch resources. I'll attempt to create an ICL script that demonstrates this so Brian can see what's being added to the scratch file.
>
> CUPID didn't have leak detection in it so would not report leftover locators. I've copied the code over from SMURF so next time you run CUPID should complain if it has an open temp locator. Of course all that could should really go in the fixed part so that every monolith can test for leaks.
No reports of anything being leaked when I run findclumps. Maybe
Malcolm could try it in case its a data dependent problem.
David
|