[Dachs-support] SODA error with 3d data
Ixaka Labadie
ixakalab at iaa.es
Wed Mar 29 16:18:12 CEST 2023
Hello Markus,
Sorry, I don't know if I'm not making myself clear or I don't understand
well your answer. The thing is that I don't use fits_makeBANDMeta, so no
BAND parameter. As I see it, fits_makeWCSParams creates with
soda.iterOtherAxisKeys() the parameters or slices to make the cutout;
this function doesn't discern between any unit or type of axis except RA
and DEC axes. Then, fits_doWCSCutout makes the cutout taking those
parameters into account. Is this correct?
As you said, I also thought there was a problem with the negative CDELT3
in the procedure I just described. I will try your instructions in the
following days and comment the outcome.
Thanks and best regards,
Ixaka Labadie
On 2023-03-29 14:10, Markus Demleitner wrote:
> Hi Ixaka,
>
> On Mon, Mar 27, 2023 at 06:22:43PM +0200, Ixaka Labadie wrote:
>> Good to know that the scaling part is expected. It's not important,
>> although
>> I think it's related.
>
> For now, DaCHS will no longer generate a scale parameter from
> fits_standardDLFuncs when there's a third axis[1]. If someone actually
> wants to scale cubes, this limitation can be lifted with moderate (I
> think) effort, but I'll wait for someone to actually request that;
> perhaps cubes with so many spatial pixels that you'll *want* to scale
> them want HiPS rather than on-the-fly scaling anyway.
>
>> I send you the simplest example I've tried, not "fits_standardDLFuncs"
>> (although I tried it and doesn't work either). Here I don't use
>> makeBandMeta
>> or makeBandSlice, but I was expecting to be able to make cutouts in
>> the
>> velocity axis as well (technically it is possible but I have to invert
>> min/max, which is not how it's supposed to be).
>
> I'd still be curious how you got the inverted limits. You see,
> fits_makeBANDMeta should have crapped out on you when it tried to
> figure out the spectral unit (which m/s simply isn't), and then you
> shouldn't have got a BAND parameter in the first place.
>
> So... did you force DaCHS' hands (in which case I'd not feel
> responsible)? Or am I missing a reasonable way around that refusal?
>
> Still, there was a bug. The special magic DaCHS has not coped with is
> a negative CDELT3, which makes the physical minimum the pixel maximum
> and vice versa. Starting with DaCHS 2.7.3, that should be fixed, if
> in a moderately lame way: DaCHS will always use the smaller value as
> the lower limit, which means that for a suitable cube, BAND=4 2 will
> be non-empty.
>
> It wouldn't be hard to fix that in turn, but I'm not quite convinced
> yet that it ought to be fixed in the first place, because in
> particular on the spectral axis there are many fairly tempting ways
> to get that sequence wrong -- and perhaps it's not a disaster if when
> the 4 2 is not a mistake there is data coming back. Hm.
>
>> Sorry, I cannot share the data I'm working with, but I can show you an
>> extract of the header. I also send the equivalent part of the header I
>
> That at least let me track down the problem with the negative CRVAL3.
>
> And I believe I have added support for velocity cubes to
> fits_standardDLfuncs; cf.
> http://docs.g-vo.org/DaCHS/ref.html#soda-fits-standarddlfuncs.
> Basically, things should work if you say
>
> <FEED source="//soda#fits_standardDLFuncs" velocityAxis="3"/>
>
> except that DaCHS does not understand enough of the FITS unit syntax
> (it wants VOUnits) to make sense of the unit in the FITS header, and
> hence in this particular case you have to say
>
> <FEED source="//soda#fits_standardDLFuncs" velocityAxis="3"
> velocityOverride="m/s"/>
>
> I haven't yet written proper prose on extending cutout functionality
> but will do so some time in the next few days.
>
> Meanwhile, could you try the stuff out? It's in the latest DaCHS
> beta (version 2.7.3). To get it, add the DaCHS beta (and, if you
> don't already have it, stable) repos as per
> http://soft.g-vo.org/repo, and then say apt update && apt upgrade.
>
> If you then type dachs --version, you should see
>
> $ dachs --version
> Software (2.7.3) Schema (33/33)
>
> With that, the velocityAxis thing above should hopefully do what you
> want or should at least reasonably simple to fix. If the latter turns
> out to be necessary, cf. //soda.rd, fits_makeVELOCITYMeta and
> fits_makeVELOCITYSlice; when installed from package, that file is in
>
> /usr/lib/python3/dist-packages/gavo/resources/inputs/__system__/soda.rd
>
> -- and you'll have to restart the server to make it see updates to
> that. Debug advice is at
> <http://docs.g-vo.org/DaCHS/tutorial.html#debugging>.
>
> In case you actually apply fixes, would you feed them back to me?
>
> Thanks,
>
> Markus
>
>
> [1] As I write this, I notice I of course forgot to take into account
> the velocity axis in I've just released as beta. If this bothers you,
> can patch soda.rd like this:
>
> Index: soda.rd
> ===================================================================
> --- soda.rd (revision 8896)
> +++ soda.rd (working copy)
> @@ -927,7 +927,7 @@
> </metaMaker>
> <dataFunction procDef="//soda#fits_makeHDUList" name="makeHDUList"/>
> <metaMaker procDef="//soda#fits_makeSCALEMeta">
> - <bind name="thirdaxes">"\spectralAxis"</bind>
> + <bind name="thirdaxes">"\spectralAxis\velocityAxis"</bind>
> </metaMaker>
> <dataFunction procDef="//soda#fits_doSCALE"/>
More information about the Dachs-support
mailing list