Starlink / starlink

Starlink Software Collection
162 stars 53 forks source link

Retire ECHWIND and KAPRH #45

Closed timj closed 9 years ago

timj commented 9 years ago

There doesn't seem to be any reason to keep echwind and kaprh in the main tree. I asked on the Starlink list about echwind and no-one responded. No-one can seriously recommend using anything from kaprh at this point (the only issue being some old documents referring to old commands).

dsberry commented 9 years ago

I probably agree...

sfgraves commented 9 years ago

@dsberry -- only probably?

timj commented 9 years ago

If @sfgraves wants to work on the JSA legacy paper and @dsberry wants to work on the AST paper I can do the removal :smile:

timj commented 9 years ago

The only question is whether @MalcolmCurrie would prefer to do it immediately after the 2015A release.

sfgraves commented 9 years ago

I'm always happy to remove things :-)

sfgraves commented 9 years ago

I've pushed two commits, one removing kaprh and one removing echwind (including their updates to applications/configure.ac, the Makefile.dependencies and their entires in componentset.xml file, and their lines in Makefile.in)

Doing a git grep 'kaprh' I noticed that a couple of lines in polpack may need some work, in files

applications/polpack/Polka_procs.tcl applications/polpack/Polka.tcl.in

timj commented 9 years ago

Thanks. @sfgraves the lengths you'll go to to avoid writing the paper... I'm not sure why you reassigned the ticket to me. I'm going to reassign it to @dsberry because I have no idea why POLPACK depends on kaprh:

   2610 # Only report ADAM errors on the last attempt.
   2611          if { $ntry < 2 } {
   2612             set ok [Obey kaprh trantrace "transform=$map logfile=$logfile" noreport]
   2613          } {
   2614             set ok [Obey kaprh trantrace "transform=$map logfile=$logfile"]
   2615          }

There's a whole chunk of code using TRANTRACE. Either we are meant to be supporting TRANSFORM HDS structures (so TRANTRACE should be in KAPPA) or else we need to do this another way. I'm out of ideas.

dsberry commented 9 years ago

I knew there was some good reason why I only probably agreed...

dsberry commented 9 years ago

HDS TRANSFORM structures are only used by polka if the user choose to use a full 6 coefficient linear transformation to align the images. But... this facility has been thoroughly broken since 15-NOV-1999 when Mark modified ccdpack:register to remove the option of writing the results as a TRANSFORM structure. So I presume that no one has used the full 6 coefficient fit in polka since at last that date (and probably never :-( ). So I propose simply removing that option from polka since it is clearly not needed.

timj commented 9 years ago

I'm happy to make the attempt.

timj commented 9 years ago

Actually, I have no idea how to test that polka still runs so it's probably a bad idea.

dsberry commented 9 years ago

Done. See 1cfe219ee96