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

Lopez, Phylroy PLopez at NRCan.gc.ca
Fri Jan 18 16:58:15 GMT 2008


Jon said....

-::Yes this has been considered. One of the issues that made it difficult was the
amount of post-processing that was happening in res.  The revised code
requires almost no post-processing. 


I am interested in what post-processing you are talking about. Does res 'massage' data? Or is it just the fact that the data reading from sql -> fortran 77 is problematic? Maybe we can discuss off-line? 


-::Indeed, there is one subroutine that recovers almost every item of data related to casual
gains for a given zone and timestep (very XML ish) and all that the calling
routines are doing is the display work with the subset of that data that is
of interest.

What I would like to see is that developers could ADD data easily to this zonal information contained in the RES database, without have to worry about corrupting other data ,the size of the record, etc.  Something like the "add_to_xml" function that CETC put together.  Also consider that some may be temporal data, but some may not (daylight luminace factors for example which would follow a more geometrical result using shocc and daysim) .  

-::We have a different project that is beginning to use sqllight and this should provide
some indications as to the overhead at run time and the overhead in compile
directives and required libraries.  More on this as we find out more...

This would be interesting. Possibly an optional compile option, and potentially create the res database as well as a sqlite database.  If done with care could replace the backend used to store the data for the  XMLreports.  


Thanks Jon,

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








More information about the esp-r mailing list