[esp-r] Re: [Core_developers] opinions requested about backward compatibilityin ESP-r results libraries

[Lopez, Phylroy]

Hey Jon, 
 
Coincidentally, I have been looking at res the past week. 
 
I think moving forward is a great idea and cleaning up the routines in res would be a boon to the output of ESP-r. 
 
I am curious if anyone has considered using a common sql database structure such as sqlite to store the data. Currently the XML interface provides users with a lot of flexibility in the development of output, for web simulations as well as rendering output on client systems. However the tradeoff is a slow parsing of the xml data, which can be very very large.
 
Providing an sql library would still allow users to use res to obtain the data, but the common sql database would let developers access the data directly through sql calls. A hierarchal database scheme such as "edge numerical" or "adjacent-list" stratagies could store the data in a logical structure such as:
 
Building
           ->Plant
           ->Zone
                ->Surface
                ->Surface
 
etc.
 
This would allow a few things, 
    Auto-discovery of data by walking the tree, and have res become a data driven application.
    Simplfied xml generation if required.  
    Allowing developers to add data to the database with much more ease.
    Allowing developers to access the databases without having to use or understand res binary formats. 
 
If sqlite is used..
 
    Sqlite format is platform independant. So it could results could be viewed/compared on win/mac/linux.
    Sqlite licence is compatible with ESP-r.
 
 
 
I have noticed that there are sql calls already in the ESP-r source code, but the way it was implemented could slow down the simulation as currently written by writing data every timestep. However by grouping the sql calls and only invoking them when a suitable number of transaction could be performed at once, decreasing the file i/o slowdown. 
 
If we are revamping the res/output, this is something to consider if it already hasn't been.
 
 
Phylroy
 

________________________________

From: core_developers-bounces at developer2.cvsdude.com on behalf of Jon Hand
Sent: Fri 1/18/2008 9:10 AM
To: esp-r at lists.strath.ac.uk
Cc: Core_developers at developer2.cvsdude.com
Subject: [Core_developers] opinions requested about backward compatibilityin ESP-r results libraries




To the ESP-r community of users and developers....

At ESRU we are working on some changes to the zone results library
file which adds in additional data types. The new information
records, for each type of casual gain, the sensible convective, sensible
radiant and latent values (in addition to the usual total radiant and
convective for each zone).

This change has a number of impacts:

a) it allows users to be more specific when graphing and listing and
    doing stats on casual gain related information. You can ask
    for only the occupant sensible convective or only the latent small
    power etc.
b) it includes latent casual gains for the first time
c) it corrects a long-standing glitch for 'controlled' casual
    gains which made it difficult to undertake some lighting
    control assessments.
d) it makes the recovery of information from the results database
    much simpler because almost no post processing is required
    and it will probably be faster because the zone operation file
    should not need to be scanned to support post-processing.

Essentially the new approach takes about 15% of the lines of
code that the previous version and this simplification of the
code is A VERY GOOD THING.

What we are debating at the moment is whether to MAINTAIN
backwards compatibility with older results files in the 'res' module. 
Literally thousands of lines of code clutter could be removed if there
is no requirement for backwards compatibility.

The old format only privided limited choices, it did a rotten
 job for models with lighting control, and for complex models
it slows down results recovery tasks.  We would imagine that
all users would prefer to use the new facility when it becomes
available.

We always attempt to maintain backwards compatibility with
simulation models.  It seems less important for results files
since they can be re-generated easily.  And the truly paranoid
who have 3 year old models will probably also have a 3 year
old version of ESP-r saved as well.

So, if you have a strong opinion one way or another please
send a brief email with your comments.

Regards, Jon Hand
_______________________________________________
CVSDude mailing list: Core_developers
Managed by GNU Mailman.
Core_developers at developer2.cvsdude.com
Archives: https://mirror2.cvsdude.com/mlarch/core_developers