April 24, 2015 at 1:47 pm #876
I seem to have found a couple of bugs in the ureka 1.5.1 release of the v1.13 Gemini IRAF package for Mac OSX. Specifically, gprepare crashes with an error claiming the parameter “mdf_suffix” is not found. It looks like “mdf_suffix” is a local parameter and is not defined along with the other local parameters, and just needs to be added as a “string” variable.
At this point, it cannot find the MDF file since it generates an MDF file name which has an extra “.fits” on the end. The problem here seems to be that gprepare generates an “mdf_suffix” that always includes “.fits”, but then generates a filename which includes both the “mdf_suffix” and the “.fits” at the end. Based on the way the filename is constructed, the best fix seems to be to remove the “.fits” from each of the “mdf_suffix” choices.
People will want to confirm that these changes are correct, but I have fixed these in my local copy of gprepare.cl, and it seems to work. I am attaching the file. As per usual, just replace the old version in your gmos$ directory.
Attachments:May 4, 2015 at 11:20 pm #884
Thanks for reporting that. What you describe certainly looks like a regression and I’m re-testing it with the changes you suggested.
I believe this bit of code should not get run though, unless you’re working with very old data — is that the case, or do you have the key_mdf parameter set to something other than the default “MASKNAME”?
James.00July 14, 2015 at 7:15 pm #945
I too have had a problem in gprepare. I’m reducing flats at the moment from gemini north from 2013(If that is considered old or not). It would pop up with an error about mdf_suffix is not recognized and so i went into to the code and found that it is not preallocated so it just needs to be added to the list of variables. But then it gave me that the Mdf could not be found or does not exist, even though I see can see it. I found that in the if statements that pertain to mdf_suffix in the gprepare.cl at the bottom of the if statement it essentially is looking for a “.fits.fits”. i fixed it by getting rid of the //.”fits” since there is already a .fits extension in the if statements above.00August 11, 2015 at 3:34 pm #956
Thanks, Ben. I believe this is the same problem addressed by Peter’s version above and we will be including his suggested fix in the next release.
By “very old”, I did not mean 2013 (more like 10yrs earlier). When I read the code previously, it looked like you must have key_mdf set to a non-standard keyword if this happens on 2013 data — unless I overlooked something, which is starting to seem more likely. Anyway, I think you’ve both taken care of it for now.
You must be logged in to reply to this topic.