Segmentation fault when combining images

[cdfassnacht]

I am finally using the dev branch code and trying to reduce data on a target. When I get to the data.combine step, it seems to go through OK and drizzles two or three of the input images onto the final grid before crashing out with a segmentation fault. I have hit the same bug on both my MacOS laptop and our linux cluster. I have used the CalcStrehl code before running data.combine, although I am not weighting by the Strehl in the final combination, i.e., I have set weight=None when calling data.combine. Here is the call in my wrapper reduction script:

""" Coadd the frames """ print('') print('Combining the calibrated files') print('------------------------------') data.combine(sci_frames, obsfilt, obsdate, field=target, trim=0, weight=combwht, submaps=submaps, instrument=inst, clean_dirs=clean_dirs)

In this call weight=None, submaps=0, instrument=NIRC2. The output of the code is below. Could this be a memory issue? Any suggestions?

Combining the calibrated files

combine: reference image - /Users/cdf/Sandbox/SHARP/NIRC2N_Kp/2016+112/combo/clean/2016_Kp/c0017.fits
Different PAs found
Rotating frame: 0016
Rotating frame: 0017
Rotating frame: 0018
Rotating frame: 0019
Rotating frame: 0020
Rotating frame: 0021
Rotating frame: 0022
Rotating frame: 0023
Rotating frame: 0024
Rotating frame: 0025
Rotating frame: 0026
Rotating frame: 0027
Rotating frame: 0028
Rotating frame: 0029
Rotating frame: 0030
Rotating frame: 0031
Rotating frame: 0032
Rotating frame: 0033
Rotating frame: 0059
Rotating frame: 0060
combine: registering images
combine: Size of output image is 1970
combine: drizzling images together
/Users/cdf/git/KAI/kai/reduce/weather/cfht-wx.2017.06.dat
Drizzling: 0017
xsh = -0.00
ysh = -0.00
weight = 0.05
outnx = 1970
/Users/cdf/git/KAI/kai/reduce/weather/cfht-wx.2017.06.dat
Drizzling: 0016
xsh = 463.08
ysh = -455.71
weight = 0.05
outnx = 1970
/Users/cdf/git/KAI/kai/reduce/weather/cfht-wx.2017.06.dat
Drizzling: 0029
xsh = 0.06
ysh = 1.61
weight = 0.05
outnx = 1970
Segmentation fault

[cdfassnacht]

Update: I've been trying to figure out what might be causing this segmentation fault so I downloaded the tutorial NIRC2 data on the KAI google drive (17may21) and used the NIRC2 data reduction template to reduce them. Everything worked, including the combination stage. I then tried with my own data that caused the segfault, but this time using the data reduction template and it also worked. Well, the auto-alignment failed, but there was no segfault.

I'm not completely surprised that using the template with my data might work even though my data led to the segfault reported above. This is because I've written my own code that is mostly just a wrapper for the KAI pipeline code, although I have replaced the first part of the functionality of data.clean with my own code (my code takes care of things through the creation of the bpfits files). I will now see if I can test the code using my bpfits but then do everything else within the template. My initial guess of what might be causing the problem is that my wrapper puts in something for the clean_dirs parameter in data.combine, even if all the data come from one night. I'll test that out as well. Stay tuned.

[cdfassnacht]

Update 2: It turns out that one out of the 20 frames in my dataset has a PA of -0.0012 (ROTPOSN is 0.6988) rather than a PA of 0.0 (ROTPOSN = 0.7). Because of this, the files all get rotated to the same PA, as expected. Something about that rotation is screwing things up and causing the segfault when I run my wrapper code, since if I delete the discrepant frame (n0020.fits) from the input file list, my code works just fine. I just checked what happens when I run the reduce.py template code on these data sets and, once again, the different PAs are detected and so the files are rotated. For the template, though, no segfault is caused. Most of my wrapper code is a direct copy-and-paste from the main branch (iraf version). It may be that some change was implemented in the dev version and that not having that particular change in my wrapper code is causing the segfault. I'll investigate more and try to get my wrapper code to work even in the case when there are different PAs. I may very well be able to close end this issue myself, if I can only manage to find what change from the main to the dev version is causing the segfault. Fingers crossed

[jluastro]

We definitely made some changes in the no-iraf version to handle rotation better. But we have also noticed that the rotator encoder is not as accurate as before and we are seeing more small changes in angles (still trying to assess whether they are real or not).On Feb 3, 2026, at 3:02 AM, Chris Fassnacht ***@***.***> wrote:cdfassnacht left a comment (Keck-DataReductionPipelines/KAI#53) Update 2: It turns out that one out of the 20 frames in my dataset has a PA of -0.0012 (ROTPOSN is 0.6988) rather than a PA of 0.0 (ROTPOSN = 0.7). Because of this, the files all get rotated to the same PA, as expected. Something about that rotation is screwing things up and causing the segfault when I run my wrapper code, since if I delete the discrepant frame (n0020.fits) from the input file list, my code works just fine. I just checked what happens when I run the reduce.py template code on these data sets and, once again, the different PAs are detected and so the files are rotated. For the template, though, no segfault is caused. Most of my wrapper code is a direct copy-and-paste from the main branch (iraf version). It may be that some change was implemented in the dev version and that not having that particular change in my wrapper code is causing the segfault. I'll investigate more and try to get my wrapper code to work even in the case when there are different PAs. I may very well be able to close end this issue myself, if I can only manage to find what change from the main to the dev version is causing the segfault. Fingers crossed —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cdfassnacht]

Thanks for the feedback! I'm guessing that the error is now how the *coo files get created. This is because my wrapper code creates these files (once again, using pretty much a straight copy-paste from the iraf version of KAI) but the actual rotation takes place in new dev code that I haven't touched.

As for the small changes in the PA, in looking at the log (see attached screenshot) this was either a true mechanical glitch or a glitch in reading the value, since there is no way that we would have changed the PA by a fraction of a degree for one exposure in the middle of a long sequence. Thanks again!