iraf.net

Hi. I have a questions regarding removal of cosmic ray events from solo
exposures. I have tried using the [noao.imred.ccdred.cosmicrays] task but
I find it does not do well with the elongated, multipixel events that
occur on HST-WFCP2 images.Is [noao.imred.generic.cosmicrays] the same task as I mentioned above?Is there another task or script that will work better than what I have
used.Thanks,
jeff

Hi Jeff,Yes the COSMICRAYS task in both CCDRED and GENERIC are the same thing.
Dealing with cosmic rays in a single exposure is very difficult and no
task will work in all situations. COSMICRAYS was designed to handle
small 1-2 pixel CRs without clipping cores of stars. Over the years
there have been many algorithms proposed or used. HST and the ECF have
developed some things for HST data. I read about them in their newsletters.Within the NOAO realm I recently gathered together what tools might be useful
for CRs (both multiimage and single image algorithms) in an external
package called CRUTIL. You can find it atftp://iraf.noao.edu/iraf/extern/crutil.[readme,tar]This includes the same COSMICRAYS task you know about and a script based
on median filtering. I'm not sure how well that would work on your data.Other than that I suggest you look at the newsletters I mentioned above
and contact those authors or try help@stsci.edu.Cheers,
Frank Valdes

Hello --I was wondering if you could help us with a mystery. We have
been collecting spectra (at Las Campanas) and reducing them with
onedspec. We have recently sent extracted 1-D spectra to someone
else and they are having problems displaying them with the appropriate
wavelength scale. Upon examination of the .imh header, we note the
following:APNUM1 = '1 1 38.09 43.09'
WCSDIM = 1
CTYPE1 = 'LINEAR '
CRVAL1 = 3.6526330680831
CRPIX1 = 1.
CDELT1 = 8.53620932929730E-5
CD1_1 = 8.53620932929730E-5
LTM1_1 = 1.
WAT0_001= 'system=equispec'
WAT1_001= 'wtype=linear label=Wavelength units=angstroms'
DC-FLAG = 1
DCLOG1 = 'REFSPEC1 = ccd153.ms'It is clear that, while the spectra go from Hbeta to Halpha, the
problem this other group is having is with the CRVAL1 and CRDELT1,
which are way off, and give a scale from 3.65 to 3.83! We have never
noticed this weird keywords before because when we splot things,
they come up with the correct wavelength scale from 4500-6700 A.
SO, how is it that our splot command knows what the correct
wavelength scale is, despite the apparently wrong keywords which
do affect another group's interpretation of the wavelength scale??Any insight you can offer would be most appreciated.Steve Majewski

Hi Steve,I don't know whether you are doing it on purpose or accidentally but
when you run DISPCOR you are resampling to a log-linear wavelength
scale; i.e. equal increments of log(lambda). The parameter
dispcor.log=yes in what you are doing. This option is available for
people who do cross-correlation radial velocities and want to only
resample once or use a non-IRAF cross-correlation program that requires
a log wavelenth axis.In this case you will also find a keyword DC-FLAG=1 in the header: DC-FLAG=-1 No dispersion calibration
DC-FLAG=0 Linear dispersion calibration
DC-FLAG=1 Log-linear dispersion calibration
DC-FLAG=2 Non-linear dispersion calibration

SPLOT displays spectra in wavelength (by default) in all the last three
cases. So tell the other party that for the data you sent log(lambda) = CRVAL1 + CD1_1 * (pixel - CRPIX1)

lambda = 10. ** (CRVAL1 + CD1_1 * (pixel - CRPIX1)

where the units are Angstroms in your data.Cheers,
Frank Valdes

>From srm4n@astsun.astro.virginia.edu Wed Aug 18 10:01:40 1999
Date: Wed, 18 Aug 1999 13:01:37 -0400 (EDT)
From: "Steven R. Majewski" <srm4n@astsun.astro.virginia.edu>
To: Frank Valdes <valdes@noao.edu>
Subject: Re: questionOf course! Ok, now I understand. Thanks. Since the data
had been reduced by someone else I had not thought abuot the
log(linear) scale switch. Thanks!Steve

I have another question. I would like to know how to scan a string for
substrings. Much like the function strstr() does (intrinsic to C). Thanks,
jeff

What version of Red Hat Linux will be required to run PC-IRAF 2.11.2?James Bryan

Hi James,
V2.11.2 supports both RedHat 5 and 6 systems but note the upgrade
for PC-IRAF isn't out yet. The current V2.11.1 system also supports either
system, let us know if you still have questions.Cheers,
-Mike

Hi Jeff,
If you're asking how to do this within the CL or a CL script then
unfortunately there is no capability similar to strstr(). To do this
you could write a foreign task that returns some value that could be read
into a script variable, another method would be a brute force approach
that uses the substr/stridx/strlen functions, e.g. s1 = "testing"
s2 = "ing"
i = stridx (s2, s1)
j = i + strlen (s2) - 1
if (s2 == substr (s1,i,j)) {
printf ("substring found starting at position %d\n", i)
} else {
printf ("no substring found\n")
}Hope this helps, write back if you still have questions.Cheers,
Mike Fitzpatrick

Hi,I have just installed V2.11.2 on our public Solaris machines here
at Cornell. The installation was very easy (as usual) and we are back
up and running.However, I've found a problem in some of our home-grown scripts that
I don't understand, though I can work around it. It arises, I think,
because there is now some confusion caused by the existence of two CURFIT
definitions, one a routine and one a package. The help files are also
confused, so that's why I'm writing. My code is a call to CURFIT inside a script
as follows: curfit ( histlist, func="legendre", weight="instrumental", order=4, \
inter-, power+, list-, verbose=no, > fitfile)It DOES NOT work unless interactive above is set to yes because of a
segmentation violation. A call to curfit also does not work outside the
script either, unless I set interactive=yes. If I do that, and merely hit "q"
in the graphics display, it all works fine.So you see, I can work around it, but I don't
understand the problem, and sometimes want to process
in batch mode without the need for interactive
intervention.I also noticed that there are two different help files for
CURFIT depending on how math$ is defined:
iraf$lib/math/
and
iraf$math/
because in the first case, it thinks it is a routine, and in the second
a package. The first help file is relevant to the needed input parameters.I'd appreciate a work-around to allow non-interactive curfitting, if you
know of one.Thanks,Martha Haynes
haynes@astrosun.tn.cornell.edu

Martha,First, I apoligize for taking so long to get back to you.
On Sun, 12 Sep 1999, Martha Haynes wrote:> curfit ( histlist, func="legendre", weight="instrumental", order=4, \
> inter-, power+, list-, verbose=no, > fitfile)
>
> It DOES NOT work unless interactive above is set to yes because of a
> segmentation violation. A call to curfit also does not work outside the
> script either, unless I set interactive=yes. If I do that, and merely hit "q"
> in the graphics display, it all works fine.This is indeed a bug. I won't go into details here, but you can read
about it in our buglog reports if you're interested. There is an
acceptable workaround. You can run this task in interactive mode, but
have the cursor commands come from a file instead of from having to use
the keyboard. In the CL, you'd do this like: cl> curfit dev$pix inter+ cursor=commandsWhere the 'commands' file can be as simple as having a 'q' in it.However, there were some other things added to this task to support GUI
features, so this isn't enough. You'll also need to redirect the
graphical output to dev$null (or /dev/null) as well as the output of the
task itself (the fitting parameters) to a separate file. So from the CL,
a complete command would be: cl> curfit dev$pix inter+ cursor=commands >G dev$null >>& infoThe file 'info' will contain some junk at the top, but otherwise contains
the usual data.>
> I also noticed that there are two different help files for
> CURFIT depending on how math$ is defined:
> iraf$lib/math/
> and
> iraf$math/
> because in the first case, it thinks it is a routine, and in the second
> a package. The first help file is relevant to the needed input parameters.That is correct. The CURFIT task is in the UTILITIES package, while the
CURFIT package is part of the math libraries. If you want to call the
CURFIT task in UTILITIES, you can do a utilities.curfit (...)in your script.So the entire thing would look like this:utilities.curfit (input="dev$pix", func="legendre", weight="instrumental",
order=4, inter+, power+, list-, cursor="commands", verbose=no, >G
"dev$null", >>& "fitfile")Let us know if you continue to have problems with this or have additional
questions.Regards,Matt Cheselka