Hmm, seems I have found another issue. Wanted to check how the lack of
file mapping impacts GAIA, so I thought I'd display a big image that can
be handled by the old HDS with comfort, especially at startup, this comes
in at 5.9G with dimensions 43440 x 36241.
First attempt to hcopy this to HDF format fails with (DEBUG_HDS 1):
Bad status from datNew (v5): 147358883
Enter HDS routine: datFind [147358883]
Enter HDS routine: datStruc [147358883]
Enter HDS routine: datState [147358883]
Enter HDS routine: datAnnul [147358883]
Enter HDS routine: datIndex [147358883]
Enter HDS routine: datName [147358883]
....
So I tried to just create an NDF directly with KAPPA CREFRAME:
Bad status from datNew (v5): 147358883
Enter HDS routine: datFind [147358883]
Enter HDS routine: datNew1I [147358883]
Enter HDS routine: datAnnul [147358883]
Enter HDS routine: datName [0]
....
!! HDF5-DIAG #000: H5D.c line 194 in H5Dcreate2(): unable to create dataset
! HDF5-DIAG major: Dataset; minor: Unable to initialize object
! HDF5-DIAG unable to create and link to dataset
! HDF5-DIAG unable to create new link to object
! HDF5-DIAG can't insert link
! HDF5-DIAG internal path traversal failed
! HDF5-DIAG traversal operator failed
! HDF5-DIAG unable to create object
! HDF5-DIAG unable to open object
! HDF5-DIAG unable to create dataset
! HDF5-DIAG unable to construct layout information
! HDF5-DIAG chunk size must be < 4GB
! Error placing the data space in the file for DATA
! datNew: Error in call to HDS (v5)
! ARY_NEW: Error creating a new simple array.
! NDF_NEW: Error creating a new simple NDF.
! Unable to get an NDF identifier for 'temp'.
! CREFRAME: Failed to create a test NDF.
! Application exit status DAT__NOMSG, error 147358883 (fac=200,messid=148)
! message number not found
That "HDF5-DIAG chunk size must be < 4GB" looks a little alarming. Seems
there are some tuning parameters in H5Pset_layout that might apply to
this, or you may need to create the files with a larger chunk size
(clearly better if the file mapping idea works).
Cheers,
Peter.
On Thu, 6 Nov 2014, Peter W. Draper wrote:
> On Wed, 5 Nov 2014, Tim Jenness wrote:
>
>> On Wed, Nov 5, 2014 at 5:15 AM, Peter W. Draper <[log in to unmask]>
>> wrote:
>> On Tue, 4 Nov 2014, Peter W. Draper wrote:
>>
>> Additional info on display issues. Seems I only get
>> the DAT__UNSET
>> error if I use HDS v4 parameter files. If I switch
>> to HDF5 parameters
>> I see:
>>
>> > display mosaic.sdf
>> DEVICE - Name of display device /@xwindows/ >
>> !! datGet: Primitive object is undefined. Nothing to
>> get
>> ! datGet0I: Error in call to HDS (v5)
>> ! DISPLAY: Failed to display an image of a one- or
>> two-dimensional data set.
>> ! Application exit status DAT__UNSET, Primitive
>> data undefined
>> ! mosaic.sdf
>>
>> Attached the two outputs with the debug flag
>> switched on. Not sure if it is helpful but if I set
>> the output device=ps_p then that works.
>>
>>
>> After the nights fixes, this problem seems to be resolved and I
>> can now display images. DISPLAY sometimes says:
>>
>> !! datGet: Primitive object is undefined. Nothing to get.
>> ! datGet: Error reading data from primitive object AGI_3800_1
>> as type _REAL
>> ! (internally type is _REAL)
>> ! datMapV: Error in call to HDS (v5)
>> ! Failed to load the current device colour palette.
>> Continuing anyway...
>>
>> So clearly an issue with AGI and palettes (that I think you're
>> aware of).
>>
>>
>> I think I am going to commit my fix for the palette writing -- I think it
>> is
>> nominally the correct thing to do to explicitly annul the locator in the
>> routine. Starlink Fortran is not meant to be relying on behind the scenes
>> garbage collection.
>>
>> I assume your tests involved David's ARY fix as well. I haven't
>> cherry-picked that to the branch because my assumption is that at some
>> point
>> I'll just rebase and merge.
>
> No to that one. My tests mustn't have touched that issue.
>
>> Otherwise I've also popped up cubes and images (hcopy'd to new
>> format) in GAIA and that all seemed OK,
>>
>>
>> Great.
>>
>>
>> just if I accidentally mixed old and new files that things
>> seemed a bit unstable.
>>
>>
>> That worries me a little. I'll see if I can reproduce it but a v4 locator
>> should always be in v4 calls and v5 should never be involved. I would like
>> to know if the complaints come from ADAM parameter files, AGI files or v4
>> data files. If you get a chance it would be helpful to run with the
>> DEBUG_HDS flag set in the hds_select.c build.
>
> Nothing to worry about it seems. The issue was a couple of genuine bugs in
> the new EXTRACTOR (wasn't handling the case when no WCS was present and WCS
> columns were requested). Nothing else has turned up yet.
>
> Cheers,
>
> Peter.
>
--
Peter W. Draper, http://astro.dur.ac.uk/~pdraper
|