[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