| Anonymous: Guest |
03/21/2005 11:26PM (Read 1009 times)
|
|
|
|
|
>From zarate@noao.edu Wed Mar 9 11:06:22 2005
From: "Nelson Zarate" <zarate@noao.edu>
Subject: FYI:Fwd: 64 bits
To: fitz
Cc: valdes
Date: Wed, 09 Mar 2005 11:06:20 -0700
Hello;
Besides the information there are 2 X11iraf
questions from this user.Nelson
--- the forwarded message follows -----_===17054647====noao.edu===_
Message-ID: <422EF217.5050808@astro.rug.nl>
Date: Wed, 09 Mar 2005 13:54:47 +0100
From: "N.G. Douglas" <ndouglas@astro.rug.nl>
To: Nelson Zarate <zarate@noao.edu>, Lodovico Coccato <coccato@pd.astro.it>
Subject: Re: 64 bits
References: <421A0D32.2010008@astro.rug.nl> <web-16765431@noao.edu>
In-Reply-To: <web-16765431@noao.edu>
Thanks for the reply. My question was aimed at helping to decide whether to
purchase a 64 bits machine for a new Post-Doc, it seems like the answer is
no, at least as far as IRAF is concerned. Naively, I thought it was just a
matter of recompiling IRAF with a 64 bit (fortran) compiler but this is
evidently not so.Actually, 90% of the gain could be obtained, in our case, by converting one
or two tasks to 64 bits, notably median() and the la_cos cosmic ray removal
script written by a user, P van Dokkum. These routines feature heavily in
our pipeline (and in fact la_cos is probably rate-determined by median() in
turn).So, could one consider one-off conversions or is this a crazy idea?Finally, two questions which may not be IRAF questions, actually,
feel free to ignore them:1. During the operation of GEOMAP and like programs, the "irafterm" window
pops up with nice graphical info on the fit... but for non-interactive use
(eg re-running the pipeline) it'd be nice not to have to keep acknowledging
the fit. Can this be switched off? (I've already tried the obvious ones like
parameters, and the redirection operator) and the results (eg fit errors)
be made accessible to an automatic pipeline?2. under redhat linux (what fraction of users use linux by the way?) the
xgterm seems to switch spontaneously to a mode in which the text is white
against an annoying black box. Certain editors elicit the same response. Can
this be supressed..?Regards, Nigel
Nelson Zarate wrote:> Hello;
>
> The redhat distributions runs fine on Opteron but you cannot
> build application on this machine just yet. You could build on another
> linux machine and run on the AMD one.
>
> We are planning to start a project to port IRAF to the 64 bits
> machine. We do not have a date at this time.
>
> Please let us know if you have any further questions, comments or
> suggestions.
>
>
> Thanks,
>
> Nelson Zarate
> NOAO/Iraf
>
>
> On Mon, 21 Feb 2005 17:32:50 +0100
> "N.G. Douglas" <ndouglas@astro.rug.nl> wrote:
>
>>
>> hi, thanks for the helpful disciussion on shells etc.
>>
>> we are considering buying a 64 bits processor (AMD Opteron) for
>> running our
>> IRAF pipeline. Is IRAF set up to use this, assuming we compile... or
>> can you
>> make binaries...?
>>
>> Regards, Nigel
>>
--_===17054647====noao.edu===_-->From fitz Mon Mar 21 16:14:19 2005
Date: Mon, 21 Mar 2005 16:14:18 -0700 (MST)
From: Mike Fitzpatrick <fitz>
To: ndouglas@astro.rug.nl
Subject: Re: 64 bits
Cc: fitzHi Nigel,
Sorry for the slow reply, I'd forgotten Nelson forwarded this
to me as well.
> Actually, 90% of the gain could be obtained, in our case, by
> converting one or two tasks to 64 bits, notably median() and the la_cos
> cosmic ray removal script written by a user, P van Dokkum. These routines
> feature heavily in our pipeline (and in fact la_cos is probably
> rate-determined
> by median() in turn).
>
> So, could one consider one-off conversions or is this a crazy idea? Tasks are built on interfaces, which in turn are built on the IRAF
kernel. You can't just modify a few tasks without doing the underlying
system and by that time you've done most of the 64-bit port anyway. It
would likely be faster to just reimplement those two tasks using FITSIO
and replace them later once 64-bit iraf is done.> 1. During the operation of GEOMAP and like programs, the "irafterm" window
> pops up with nice graphical info on the fit... but for non-interactive use
> (eg re-running the pipeline) it'd be nice not to have to keep acknowledging
> the fit. Can this be switched off? (I've already tried the obvious ones like
> parameters, and the redirection operator) Are you saying that turning off the 'interactive' parameter still
issues a prompt? Not all tasks have an interactive param but most do. For
those that don't it's often possible to use "cursor files" for input to
automate the task in scripts -- see 'help cursors' for a description of
the format and its use.> and [can] the results (eg fit errors)
> be made accessible to an automatic pipeline? You can always pipe the output to a file (or use the 'results' param
to set a file) and parse it for the numbers desired, but there's no way to
have the task print just that information if it doesn't already do so.> 2. under redhat linux (what fraction of users use linux by the way?) ....probably more than half by now, we quit keeping track.> the xgterm seems to switch spontaneously to a mode in which the text is white
> against an annoying black box. Certain editors elicit the same response. Can
> this be supressed..? Linux brought us some 27 different tty descriptions for an XTerm,
the default setting works nice with the terminals that come w/ redhat but
not things like xgterm. Just use setenv TERM xterm-colorand you'll get a terminfo setting which stops the reverse video switching.
Hope this helps, let us know if you still have questions.
Cheers,
Mike Fitzpatrick
|
| |
|
|
| Anonymous: Guest |
|
03/21/2005 11:26PM
|
|
|
|
|
>From zarate@noao.edu Wed Mar 9 11:06:22 2005
From: "Nelson Zarate" <zarate@noao.edu>
Subject: FYI:Fwd: 64 bits
To: fitz
Cc: valdes
Date: Wed, 09 Mar 2005 11:06:20 -0700
Hello;
Besides the information there are 2 X11iraf
questions from this user.Nelson
--- the forwarded message follows -----_===17054647====noao.edu===_
Message-ID: <422EF217.5050808@astro.rug.nl>
Date: Wed, 09 Mar 2005 13:54:47 +0100
From: "N.G. Douglas" <ndouglas@astro.rug.nl>
To: Nelson Zarate <zarate@noao.edu>, Lodovico Coccato <coccato@pd.astro.it>
Subject: Re: 64 bits
References: <421A0D32.2010008@astro.rug.nl> <web-16765431@noao.edu>
In-Reply-To: <web-16765431@noao.edu>
Thanks for the reply. My question was aimed at helping to decide whether to
purchase a 64 bits machine for a new Post-Doc, it seems like the answer is
no, at least as far as IRAF is concerned. Naively, I thought it was just a
matter of recompiling IRAF with a 64 bit (fortran) compiler but this is
evidently not so.Actually, 90% of the gain could be obtained, in our case, by converting one
or two tasks to 64 bits, notably median() and the la_cos cosmic ray removal
script written by a user, P van Dokkum. These routines feature heavily in
our pipeline (and in fact la_cos is probably rate-determined by median() in
turn).So, could one consider one-off conversions or is this a crazy idea?Finally, two questions which may not be IRAF questions, actually,
feel free to ignore them:1. During the operation of GEOMAP and like programs, the "irafterm" window
pops up with nice graphical info on the fit... but for non-interactive use
(eg re-running the pipeline) it'd be nice not to have to keep acknowledging
the fit. Can this be switched off? (I've already tried the obvious ones like
parameters, and the redirection operator) and the results (eg fit errors)
be made accessible to an automatic pipeline?2. under redhat linux (what fraction of users use linux by the way?) the
xgterm seems to switch spontaneously to a mode in which the text is white
against an annoying black box. Certain editors elicit the same response. Can
this be supressed..?Regards, Nigel
Nelson Zarate wrote:> Hello;
>
> The redhat distributions runs fine on Opteron but you cannot
> build application on this machine just yet. You could build on another
> linux machine and run on the AMD one.
>
> We are planning to start a project to port IRAF to the 64 bits
> machine. We do not have a date at this time.
>
> Please let us know if you have any further questions, comments or
> suggestions.
>
>
> Thanks,
>
> Nelson Zarate
> NOAO/Iraf
>
>
> On Mon, 21 Feb 2005 17:32:50 +0100
> "N.G. Douglas" <ndouglas@astro.rug.nl> wrote:
>
>>
>> hi, thanks for the helpful disciussion on shells etc.
>>
>> we are considering buying a 64 bits processor (AMD Opteron) for
>> running our
>> IRAF pipeline. Is IRAF set up to use this, assuming we compile... or
>> can you
>> make binaries...?
>>
>> Regards, Nigel
>>
--_===17054647====noao.edu===_-->From fitz Mon Mar 21 16:14:19 2005
Date: Mon, 21 Mar 2005 16:14:18 -0700 (MST)
From: Mike Fitzpatrick <fitz>
To: ndouglas@astro.rug.nl
Subject: Re: 64 bits
Cc: fitzHi Nigel,
Sorry for the slow reply, I'd forgotten Nelson forwarded this
to me as well.
> Actually, 90% of the gain could be obtained, in our case, by
> converting one or two tasks to 64 bits, notably median() and the la_cos
> cosmic ray removal script written by a user, P van Dokkum. These routines
> feature heavily in our pipeline (and in fact la_cos is probably
> rate-determined
> by median() in turn).
>
> So, could one consider one-off conversions or is this a crazy idea? Tasks are built on interfaces, which in turn are built on the IRAF
kernel. You can't just modify a few tasks without doing the underlying
system and by that time you've done most of the 64-bit port anyway. It
would likely be faster to just reimplement those two tasks using FITSIO
and replace them later once 64-bit iraf is done.> 1. During the operation of GEOMAP and like programs, the "irafterm" window
> pops up with nice graphical info on the fit... but for non-interactive use
> (eg re-running the pipeline) it'd be nice not to have to keep acknowledging
> the fit. Can this be switched off? (I've already tried the obvious ones like
> parameters, and the redirection operator) Are you saying that turning off the 'interactive' parameter still
issues a prompt? Not all tasks have an interactive param but most do. For
those that don't it's often possible to use "cursor files" for input to
automate the task in scripts -- see 'help cursors' for a description of
the format and its use.> and [can] the results (eg fit errors)
> be made accessible to an automatic pipeline? You can always pipe the output to a file (or use the 'results' param
to set a file) and parse it for the numbers desired, but there's no way to
have the task print just that information if it doesn't already do so.> 2. under redhat linux (what fraction of users use linux by the way?) ....probably more than half by now, we quit keeping track.> the xgterm seems to switch spontaneously to a mode in which the text is white
> against an annoying black box. Certain editors elicit the same response. Can
> this be supressed..? Linux brought us some 27 different tty descriptions for an XTerm,
the default setting works nice with the terminals that come w/ redhat but
not things like xgterm. Just use setenv TERM xterm-colorand you'll get a terminfo setting which stops the reverse video switching.
Hope this helps, let us know if you still have questions.
Cheers,
Mike Fitzpatrick
|
| |
|
|
| |
|
64-bits
