iraf.net

Hi All,

I am having problems to run FITCOORDS task after successful IDENTIFY and REIDENTIFY tasks (Linux Mageia 5, KDE). This is the
unfortunate output:

longslit\$this->_split2($m[0]) fitcoords
Images whose coordinates are to be fit (mArc):
Fit mArc interactively (yes):

NOAO/IRAF V2.16.1 ovince@oliver-pc.aob.rs Sun 21:40:00 07-Jan-2018
Longslit coordinate fit name is mArc.
Longslit database is database.
Features from images:
mArc
ERROR: segmentation violation



The setup is according to "User's Guide to Reducing slit Spectra with IRAF" by Phil Massey et al. which is:

unlearn fitcoords
fitcoords.images="mArc" #Images whose coordinates are to be fit
fitcoords.fitname="" #Name for coordinate fit in the database
fitcoords.interactive=yes #Fit coordinates interactively?
fitcoords.combine=no #Combine input coordinates for a single fit?
fitcoords.database="database" #Database
fitcoords.deletions="deletions.db" #Deletion list file (not used if null)
fitcoords.function="chebyshev" #Type of fitting function
fitcoords.xorder=2 #X order of fitting function
fitcoords.yorder=2 #Y order of fitting function
fitcoords.logfiles="STDOUT,logfile" #Log files
fitcoords.plotfile="plotfile" #Plot log file
fitcoords.graphics="stdgraph" #Graphics output device
fitcoords.cursor="" #Graphics cursor input
fitcoords.mode="ql" #
fitcoords


I read previous post on FITCOORDS issues and none of them seems to me represents this one.


Thank you for help in advance
Oliver

What version if IRAF do you use? The package that comes (came?) with Mageia? Astroconda? Or the original tarball from NOAO? 32 or 64 bit?

It would also be helpful if you could pit the mArc file somewhere so that one could try to reproduce the problem.

Cheers

Ole

thank for reply.

I use original NOAO IRAF 64bit version 2.16.1.

You may download mArc.fits along with 'steps.inf' file containing all the steps I perform which can copy-pasted directly to cl

https://www.dropbox.com/sh/ziefbx5v9mv8424/AAA1aTL2PrPXEJvBxHMDw-jxa?dl=0

Could you also put the "database" file there?

yes, it is there ...

Hmm, this doesn't look like the "database" file?

At least, it is not called "database", while your parameter refers to a file called "database". And using it as database for me just results in "Warning: No coordinates found in database".

sorry, in which task and what parameter is referred to file called 'database'?

And I get an error message

Maybe this is your problem?

I am using a heavily fixed version, including a number of segmentation fault fixes; so your version may not properly handle the missing database.

maybe I am wrong, but I think that

fitcoords.database="database" #Database


refer to the name of the folder (not a file) where some files are stored. I my case, database folder was created automatically after running the identify task and 'idmArc' file (that I have attached in dropbox for you) was written into it.

After moving the file idmArc to a database subdir,, the file names do not match:

and when I rename idmArc to idmArc.fits, I still get "Warning: No coordinates found in database".
IMO something is wrong with the database file.

I am confused that your and my IRAF provide different error report.

Could you please check permissions for "database" folder and "idmArc" file (do not rename into idmArc.fits please)?

Permissions of both are OK. My problem was that I used "mArc.fits" as image name. Using "mArc" without extension also shows the crash, which is for sure a bug. Maybe fitz can check this? I have no idea here.

could you please copy-paste the std output.

Thank you for help.

Same as your:

OK, I have been looking into this to some detail.

Your file has basically the following header:



The value I would question here is WCSDIM=3, which IMO makes no sense for a NAXIS=2 image.
Is there a good reason to have this value?
If you change that to WCSDIM=2, it seems to work.

What I however do not understand here is the code in noao$twodspec/longslit/transform/fcgetcoords.x, which basically causes the crash: The marked lines extract the number of dimensions from the image, but takes this number as the basis to operate on arrays (ltm, ltv) with the fixed length 2. I see no good reason for this; probably one should at least set i=2 if i\$this->_split2($m[0])2, if such files seem to be legal.

thank you for the solution, It works indeed for WCSDIM=2. I have no idea from where 3 comes from. In some of the IRAF reduction steps I have done previously.