2008/7/18 Tim Jenness <[log in to unmask]>:
> I've just had a quick look at the inter dependencies of the kaplibs sub
> libraries in preparation for breaking them out into their own libraries.
>
> AIF - no kaplibs dependencies
> IRA - ditto
> IRQ - ditto
> CTG - ditto
> LPG - uses CTG
>
> FTS - use AIF + KPG1_SGDIG KPG1_SSAZ[RD]
>
> KGS - uses kpg1_nmcol
>
> KPG - uses IRA, IRQ
> + FTS1_FTWCS FTS1_RNANR and FTS1_RNAND
>
> So the main issue is that FTS and KPG have circular dependencies. All the
> others have a nice hierarchy (KGS is *almost* stand alone)
>
>
> On the assumption that KPG is higher up in the hierarchy than FTS and so is
> *allowed* to call FTS then that means that the 2 routines used by FTS need
> another home (although the RNANx routines in FTS1 are clearly out of place -
> nothing to do with fits headers and all to do with replacement of NaN and
> Inf with VAL__BADx so should arguably be in primdat somewhere)
>
> So we have
>
> SGDIG - number of significant digits (primdat?)
> SSAZx - scale an axis (BZERO/BSCALE)
>
> Any thoughts?
The poblem is that kpg contains both high level functions such as
kpg1_gtwcs and low level functions such as kpg1_sgdig. No doubt the
correct solution would be to split kpg up into a library of low level
utilities, and another of high level routines. But that sounds like
quite a bit of work.
On the other hand, the only uses of SGDIG I can find are in
fts1_rfmod.f, fts1_qtype.f and fitsmod.f. So it could be considered a
fits things and moved into FTS. Unfortunately the same is not true of
SSAZx, which is used by various non-fits kappa routines. Snookered, I
think...
Options could include:
1) Split up kpg into multiple libraries
2) Include a copy of KPG1_SSAZx in FTS, renamed to FTS_SSAZx (cough)
3) Leave FTS and KPG together in a single package as they are at the moment
David
|