On Tue, 29 Mar 2005, McIlwrath, BK (Brian) wrote:

> This bug is now fixed on the HDS64 branch in CVS.

Hi Brian,

thanks, that seems to work for me.

> Note that I am on leave from tomorrow until Monday week (11th April) -
> after which I intend to have a concerted effort at finally tidying up
> HDS64 with a view to making it the default.
>
> Keep the bugs coming!

OK, I've spent a couple of days (on and off) playing around with HDS64 and
have fixed a couple of problems and have a couple of test programs, for
other problems that I've uncovered, for you to look at.

The problems I've fixed are trivial, one was a long-standing issue with
handling errors when file mapping fails (this caused HDS to go into a
while(1) loop forever), the other was just transferring some patches you
made to HDS back in 2000 to HDS64 (the ones for file mapping mode changes
that caused problems in CCDPACK). Once I'd made those corrections Linux
(and Solaris oddly) became much more stable and can now pass all the
CCDPACK exercise scripts.

Unfortunately the same cannot be said for Tru64, CCDPACK seems quite flaky
under that (in HDS3 or HDS4 mode). I've tried to come up with a test case
that shows the problems I see, but it's proven quite difficult, if you
haven't yet run the HDS test suite under Tru64 that would seem like a good
idea. Having said that I do have one test program for you. Try the ADAM
task "hds_test_alpha" out.  For me this goes into some CPU bound loop (or
crashes if I run it from within dbx, that doesn't seem to be useful as all
the addresses are lost). It's really just a call to PAR_GET1D, so there
maybe more vector parameter issues.

Under Linux (i386/RH9) there still seems to be some sort of design issue
that stops NDFs opened for write access being larger than 1Gb(+/-),
sometimes.  I guess that the file is being mapped twice, so this is just
half the possible mmap-ping address space. Try the "hds_test" program. If
you play around with the dimensions of the array it maps you should see
this (the values are those that fail on my machine, but I've seen those
change slightly under different OS versions, presumably just to do with
the exact memory layouts).

In general as you approach the 2Gb limit under i386 it seems that our
programs behave quite differently. All too many seem to enter CPU bound
states (this may be down to atask signal handling) the others generally
make some garbled response showing a negative integer as the amount of
memory not mapped, or crash.

On the bright-side under x86_64, I have created and mapped in HDS
components at addresses beyond 1.6Gb in an NDF, and GAIA has displayed an
NDF of size 3.2Gb, nothing else seemed to want to look at that, however!

Cheers,

Peter.



      SUBROUTINE HDS_TEST_ALPHA( STATUS )

      IMPLICIT NONE             ! No implicit typing

      INCLUDE 'SAE_PAR'         ! Standard SAE constants

      INTEGER STATUS            ! Global status

      INTEGER NLOOP             ! Number of frame generating loops

      INTEGER NRET              ! Number of returns

      DOUBLE PRECISION ORG( 2 * 1000 ) ! Origin coords for output frames



      IF ( STATUS .NE. SAI__OK ) RETURN



      NLOOP = 4



      CALL PAR_GET1D( 'ORIGINS', NLOOP * 2, ORG, NRET, STATUS )



      END



interface HDS_TEST_ALPHA

 

   parameter ORIGINS

      type        _DOUBLE

      access      'READ'

      vpath       'PROMPT'

      prompt      'Eight doubles'

      ppath       'CURRENT'

      default     1,1,1,1,1,1,1,1

   endparameter

 

endinterface



      PROGRAM HDS_TEST

*+

*  Name:

*     HDS_TEST

*-

      

*  Type Definitions:

      IMPLICIT NONE              ! No implicit typing



*  Global Constants:

      INCLUDE 'SAE_PAR'          ! Standard SAE constants

      INCLUDE 'DAT_PAR'          ! DAT_ public constants

      INCLUDE 'DAT_ERR'          ! DAT_ error codes

      INCLUDE 'CMP_ERR'          ! CMP_ error codes

      INCLUDE 'CNF_PAR'



*  Status:

      INTEGER STATUS             ! Global status



*  Local Variables:

      CHARACTER * ( DAT__SZLOC ) LOC1 ! Top-level locator

      CHARACTER * ( DAT__SZLOC ) LOC2 ! Locator for data array

      INTEGER DIM( 2 )           ! Data array dimensions

      INTEGER EL                 ! Number of mapped elements

      INTEGER PNTR               ! Pointer to mapped array



*  Local Data: These values are exact, 16377x16376 fails on my machine.

      DATA DIM / 16377, 16377 /



*.



*  Initialise the global status.

      STATUS = SAI__OK



*  Create a new container file with a data array inside it.

      CALL HDS_NEW( 'hds_test', 'HDS_TEST', 'NDF', 0, DIM, LOC1,

     :              STATUS )

      CALL DAT_NEW( LOC1, 'DATA_ARRAY', '_INTEGER', 2, DIM, STATUS )



*  Find and map the data array.

      CALL DAT_FIND( LOC1, 'DATA_ARRAY', LOC2, STATUS )

      CALL DAT_MAPV( LOC2, '_REAL', 'WRITE', PNTR, EL, STATUS )

      WRITE(*,*) 'Mapped', EL, ' elements for write access (', 

     :           STATUS, ')'

      WRITE(*,*) 'Mapped', EL*4, ' bytes for write access (', 

     :           STATUS, ')'



*  Clean up and close the file.

      CALL DAT_UNMAP( LOC2, STATUS )

      WRITE(*,*) 'Unmapped', EL, ' elements (', STATUS, ')'



      CALL DAT_ANNUL( LOC2, STATUS )

      CALL HDS_CLOSE( LOC1, STATUS )



      END