Task ID 1085 "Variant" types DDML type descriptions to not correctly specify the associated data

add task

Task ID: 1085

"Variant" types DDML type descriptions to not correctly specify the associated data

Created by guest on 2009-12-11 1:08 PM, 269 days ago


Project:	Module Code

Category:	Bug
Priority:	[no priority]
Assigned to:	[not assigned]
Status:	closed
Apsim Version:
Your Name:
Contact Details:	Eric.Zurcher@csiro.au

Comment: Entering "bugid#999" in comment creates link to id 999

show inline images show change history

comment 32001 posted by zur003 on 2010-08-13 12:46 PM, 24 days ago

forward

I've made changes to pass values as arrays of strings, which fixes the described problem, but there is still certainly scope for improving the way "variants" are handled.

comment 31230 posted by guest on 2009-12-18 4:17 PM, 262 days ago

forward

I think I see a way around this. If the paramn_value field are declared as arrays of strings, rather than merely as strings, it is fairly easy to pass values in a CMP standard-compliant way. The chief "cost" is that numeric values must first be converted to string representations, but it is easy to pass scalars as arrays of length 1. Both the APSIM and AusFarm engines seem to be content with such an arrangement.

comment 31226 posted by guest on 2009-12-11 1:08 PM, 269 days ago

forward

Most (all?) components using "variant" types to describe the data associated with events describe that data with the following DDML:

This doesn't work well with the PI (AusFarm) protocol implementation, as it expects the DDML to accurately indicate the data layout (indeed, that is precisely what the DDML is for). That's not currently happening. All the declared fields are not necessarily present in the passed data. More problematically, the paramn_value fields are always declared as being of kind="string", but their actual content may differ from this. Hence an attempt to parse the passed data based on its DDML declaration fails.

This "non-specific" declaration of "variant" types also makes these components largely unusable with the AusFarm manager which, when sending an event, needs to know the correct structure for the data to be sent with that event. The currenly provided declaration makes that impossible.

This is a very serious problem from the AusFarm perspective, with no obvious "work-around" available.