Structures in Dapper dds & Loaddap

[Arnaud FOREST <Arnaud.Forest@xxxxxxxxxx>]

Hi all,

I work on an opendap server for in-situ vertical profiles stored in a 
Oracle DBMS.
Our dds structure is copied from the 'argo' dapper interface 
(http://dapper.pmel.noaa.gov/dapper/argo/argo_all.cdp.dds) but I notice 
that matlab struct tools(Libdap :  3.6.2, loaddap : 3.5.2, Matlab : 7 ) 
doesn't completly manage the in-situ profile dapper interface.

The 'structures' are especially not very well managed by the matlab client :

   1) "Loaddap" doesn't support the structure of structure, a fatal		 
    error occures. (the matlab's crash dump is at the end of the
      message)

   2) The fields of the 'location.attributes' structure cannot be
      completly read. Only the last field is loaded in the matlab
      memory. It seems that the 'matlab dap  structure' can only manage
      a structure containing one field.

For example :

>>loaddap('http://dapper.pmel.noaa.gov/dapper/argo/argo_all.cdp?
location.attributes.PLATFORM_NUMBER,location.attributes.PI_NAME
&location.JULD>1143929418000&location.JULD<1144447818000
&location.LATITUDE>30&location.LATITUDE<50&location.LONGITUDE>-51&location.LONGITUDE<-5');


>>location.attributes

ans =

68x1 struct array with fields:
    PI_NAME



The 'PLATFORM_NUMBER' field has disappeared !
Even if the field seems to be created according to the 'verbose' output 
of loaddap :

...
Creating string vector `PLATFORM_NUMBER' with 1 elements.
Creating string vector `PI_NAME' with 1 elements.
Creating string vector `PLATFORM_NUMBER' with 1 elements.
Creating string vector `PI_NAME' with 1 elements.
Creating string vector `PLATFORM_NUMBER' with 1 elements.
...



Is there a known bug or updates foreseen about the structure management 
in the loaddap matalb toolbox ?

Why the dapper interface has been defined with so many structures in it?

Does anyone know what opendap clients are fully compliant with the 
dapper output (structures of structures, sequences of sequences, 
sequences of structures...) and what is planned for the improvement of 
the compliance between dapper interface and opendap clients (matlab, 
ferret, nco, Opendap Data connector, pyDAP, GrADS... I guess C++ and 
JAVA API are right).


Thanks a lot,

Arnaud and Thomas

--------------------- Matlab Crash Dump ---------------------


>>loaddap('http://dapper.pmel.noaa.gov/dapper/argo/argo_all.cdp?
&location.JULD>1143929418000&location.JULD<1144447818000&location.LATITUDE>30
&location.LATITUDE<50&location.LONGITUDE>-51&location.LONGITUDE<-5')

> ------------------------------------------------------------------------
>        Segmentation violation detected at Thu May  4 15:06:08 2006
> ------------------------------------------------------------------------
>
> Configuration:
>   MATLAB Version:   7.0.1.24704 (R14) Service Pack 1
>   MATLAB License:   122551
>   Operating System: Linux 2.6.9-11.EL #1 Wed Jun 8 16:59:52 CDT 2005 i686
>   Window System:    Hummingbird Communications Ltd. (7000), display br144-122:0.0
>   Current Visual:   0x23 (class 4, depth 24)
>   Processor ID:     x86 Family 15 Model 0 Stepping 10, GenuineIntel
>   Virtual Machine:  Java is not enabled
>   Default Charset:  UTF-8
>
> Register State:
>   eax = 00000000   ebx = 00cbc148
>   ecx = 02d09560   edx = 0896bd40
>   esi = 025250d0   edi = 00000003
>   ebp = bfff8bc8   esp = bfff8bc8
>   eip = 00cb737b   flg = 00210286
>
> Stack Trace:
>   [0] loaddap.mexglx:vfprintf~(0x0896bd40, 0x025250d0, 0xbfffafb0 "location", 0x00cb8d64) + 13179 bytes
>   [1] loaddap.mexglx:0x00cb8e6c(0x08642338, 0xbfffb20c, 0x00cba7c6, 1)
>   [2] loaddap.mexglx:0x00cb97ba(0x08642338, 0x00cba429, 1, 0xbfffbe30)
>   [3] loaddap.mexglx:mexFunction~(0, 0xbfffbdd0, 1, 0xbfffbe30) + 304 bytes
>   [4] libmex.so:mexRunMexFile(0, 0xbfffbdd0, 1, 0xbfffbe30) + 93 bytes
>   [5] libmex.so:Mfh_mex::dispatch_file(int, mxArray_tag**, int, mxArray_tag**)(0x02b40fb0, 0, 0xbfffbdd0, 1) + 537 bytes
>   [6] libmwm_dispatcher.so:Mfh_file::dispatch_fh(int, mxArray_tag**, int, mxArray_tag**)(0x02b40fb0, 0, 0xbfffbdd0, 1) + 262 bytes
>   [7] libmwm_interpreter.so:inDispatchFromStack(455, 0x0869ad20 "loaddap", 0, 1) + 1240 bytes
>   [8] libmwm_interpreter.so:inDispatchCall(char const*, int, int, int, int*, int*)(0x0869ad20 "loaddap", 455, 0, 1) + 112 bytes
>   [9] libmwm_interpreter.so:.L924(2, 0, 0, 0) + 165 bytes
>   [10] libmwm_interpreter.so:inInterPcodeSJ(inDebugCheck, int, int, opcodes, inPcodeNest_tag*)(2, 0, 0, 0) + 315 bytes
>   [11] libmwm_interpreter.so:inInterPcode(2, 0, 0xbfffc3f8, 0x0095e39b) + 93 bytes
>   [12] libmwm_interpreter.so:in_local_call_eval_function(int*, _pcodeheader*, int*, mxArray_tag**, inDebugCheck)(0, 0xbfffcdf0, 0xbfffce7c, 0xbfffcea8) + 163 bytes
>   [13] libmwm_interpreter.so:inEvalStringWithIsVarFcn(_memory_context*, char const*, EvalType, int, mxArray_tag**, inDebugCheck, _pcodeheader*, int*, bool (*)(void*, char const*), void*)(0x008dd468, 0x08744bd0 "loaddap('http://dapper.pmel.noaa..";, 0, 0) + 2358 bytes
>   [14] libmwm_interpreter.so:inEvalCmdNoEnd(0x08744bd0 "loaddap('http://dapper.pmel.noaa..";, 0x08744bd0 "loaddap('http://dapper.pmel.noaa..";, 0xbfffd048 ", 0x00de8c27) + 85 bytes
>   [15] libmwbridge.so:mnParser(0x00cd21e8 "@@@", 0x00cd22d8 "mnParser", 1, 0xbfffd0a4) + 471 bytes
>   [16] libmwmcr.so:mcrInstance::mnParser()(0x080a01c0, 0, 0xbffff398, 0x0804a902) + 96 bytes
>   [17] MATLAB:mcrMain(int, char**)(2, 0xbffff444, 0x0804ad1c, 0xbffff3b8) + 308 bytes
>   [18] MATLAB:main(2, 0xbffff444, 0xbffff450, 0x0047ebe6) + 23 bytes
>   [19] libc.so.6:__libc_start_main~(0x0804a7c4, 2, 0xbffff444, 0x0804a3d8) + 211 bytes
>
> This error was detected while a MEX-file was running.  If the MEX-file
> is not an official MathWorks function, please examine its source code
> for errors.  Please consult the External Interfaces Guide for information
> on debugging MEX-files.

FOREST Arnaud