[NeXus-tech] Nexus C++ API by DESY

[Pete Jemian]

walking through that with hdfview

/scan_1/sample/GLS/soft_limit_max
    attribute is "units", not "unit" (other places as well)
    Is a value assigned to this dataset?
      array length is 1, value is empty
      should it be a number, not a string?

/scan_1/sample/GLS/soft_limit_min
    change "unit" attribute to "units"
    array of length 1, value of 0.0 found

there's more so I switched to using h5toText.py, output attached.

Summary, you are probably correct that you've selected a string 
representation that conflicts with the NAPI representation of a string.

Here's a snippet from an HDF5 file written by GDA at Diamond Light Source:

   @file_time = 2011-06-02T19:32:44+00:00
   entry1:NXentry
     @NX_class = NXentry
     entry_identifier:char[5] = 31672
     program_name:char[10] = GDA 8.12.0
     scan_command:char[14] = static readout
     scan_dimensions:int32 = 1
     scan_identifier:char[36] = 67b05b7f-454f-4ed4-8914-f442c710fdeb

Compliant strings seem to be fixed length "array of char".
This does not address the error you reported below.

Look at /scan_1/instrument/Slit3/center_ver/@unit and 
/scan_1/instrument/Slit3/center_ver/@description, something got tangled up:

         center_ver:float32 = 0.0
           @unit = 5.18226e-38
           @description = 5.19678e-38

This is the same for all four slits (Slit1, Slit2, Slit3, Slit4)
Might be the problem.  The other attributes look like they have 
reasonable values.

How come nxconvert or nxdir do not give a more detailed error message?
Which attribute is the one that triggered the exception and what was the 
defect?

Pete


On 2/22/2012 3:30 AM, Eugen Wintersberger wrote:
> Hi folks
>    as you know I am developing a C++ API for Nexus within the HDRI
> project. Attached to this file you find a first Nexus file written by
> the API. As far as I see all attributes are set correctly. However,
> nxconvert or nxdir give the following error
>
> ERROR: HDF could not read attribute data
>
> I assume that this is due to the fact that I use variable length UTF8
> strings to store string data. This gives me the possibility to write
> fields of strings where the strings have variable length.
> Can someone please have a look on the file to confirm my assumption or
> maybe finds another reason why nxconvert or nxdir do not work as
> expected?
>
> best regards
>     Eugen Wintersberger
>
>
>
> _______________________________________________
> NeXus-tech mailing list
> NeXus-tech at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-tech
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: d4_test.h5.txt
URL: <http://lists.nexusformat.org/mailman/private/nexus-tech/attachments/20120222/917ab236/attachment.txt>