[esp-r] Re: Zone control sensors - cannot change with control law?

Tue Jan 12 15:20:16 GMT 2010

Aizaz et al.,

I was curious on this issue because there have been many postings in the past about it and it is an essential functionality for ESP-r.
I compiled the latest trunk version (i.e. the new version) in MSYS. I opened the basic examplar ("own" mode) and then I went to the calendar. There I defined a 4th day type. That looked promising and good. The definitions at the interface did not seem "fast" but there must be a fast way as you mention at your email and there is always the fast alternative of hacking the cfg file.
Anyway, I just added an extra (4th) day type just to try this facility. I then went to try and use it at the controls. I click on controls (the basic model has an existing control file) and the whole thing crashed. 
At this point Jon would ask if there were any messages/warnings/errors. There was nothing and the window just disappeared. The reading of the existing control file when there is an extra day type may be problematic. The model reads the file fine without this day type.
This was on a Windows Vista.

An alternative to Milan's and Teresa's querries is to use the "import measured data" option from the model context menu. You can import from csv files your own schedules that vary at timestep scale. This works fine for operations and the basic control law (Examples for heating and cooling setpoints that vary over the year can be found in: C:\Esru\esp-r\validation\CEN\15265 or the relevalt Linux location).
However, Lukas's question can only be partially solved this way. It is more complex and requires a bit of development work since he is not using the basic control law. 
Lukas - if the control laws that you want to use do already exist in ESP-r then it is just a matter of extending the existing "import measured data" (tdf) facility. Not difficult for your skills. Otherwise, it may require a bit more effort (still not difficult for your skills).

Best regards,
Georgios

________________________________________
From: esp-r-bounces at lists.strath.ac.uk [esp-r-bounces at lists.strath.ac.uk] On Behalf Of Aizaz Samuel [aizaz.a.samuel at strath.ac.uk]
Sent: Friday, January 08, 2010 8:32 PM
To: esp-r at lists.strath.ac.uk
Cc: 'Milan Janak'; Achim Geissler
Subject: [esp-r] Re: Zone control sensors - cannot change with control law?

Milan and Achim,

The way to do winter and summer weekdays/saturdays and sundays is as Achim has
described. Define these six day types from context > calendar. Next associate
these with Julian days of year and define operations and control information
as usual. The associations are assisted in that you can choose every Nth day
to be a particular day type (e.g. every seventh day starting from a specified
day could be winter sunday) and do not have to manually choose each day.

The limit is ten day types so the user can define seven more in addition to
the default week/sat/sunday. This limit can be increased in a manner
analogous to increasing maximum number of zones. Day types once defined
cannot be deleted but the equivalent is to not associate these with Julian
DOY. Unassociated day types do not affect simulations in any way.

The period of validity mechanism in my opinion should be removed and I raised
the issue on the core developers list but retained it in the end because some
legacy models in the tester use it.

The following excerpt from a previous email may be of interest.

> > - Control day types are now synchronised with calendar day types from the
> >   context menu. Now users can define day types in the context menu and
> >   associate different controls for different day types. The day type
> >   description is consistent with operations description of day types.
> >   Controls can be associated with one of three schemes to describe day
> > types as follows:
> >   1) One control for all days
> >   2) Different controls for day types as described in the context menu
> > i.e. a list of Julian days for every day type (or if not defined then
>> default to week/sat/sunday)
> >   3) Dates of validity. One control is active all days within each period
> >       defined by dates of validity.

Regards,
Aizaz

> >       On Friday 08 January 2010 11:50, Achim Geissler wrote:
> Hi Milan
>
> got me. I have actually never used this, yet. I just remembered reading it
> because I would have liked this feature some time ago.
>
> I assume it is not possible. I think the limit is 5 day types (but am not
> sure - you would need to look into the source). So you could have
> SatWin/SatSum/Sun/WeekSum/WeekWin ... which is already quite a step
> forward.
>
> It would of course be a lot better if the "Valid for period" entry in the
> control file would do what the name suggests. No idea if this is much work
> to code.
>
> Regards
> Achim
>
>
> -----Original Message-----
> From: Milan Janak [mailto:milan.janak at stuba.sk]
> Sent: Freitag, 8. Januar 2010 12:00
> To: Achim Geissler
> Subject: Re: [esp-r] Re: Zone control sensors - cannot change with control
> law?
>
> Hi Achim,
>
> Related to this "problem" with day types a question comes to mind
> that what is realy needed is to be able to define a day type e.g.
> "winterday" but at the same time to maintain division to week/sat/sunday.
> Is this possible?
>
> Best regards,
>
> Milan.
>
>
> On Fri, 8 Jan 2010 11:34:55 +0100
>
>  "Achim Geissler" <achim.geissler at intergga.ch> wrote:
> >Hi Lukas
> >
> >
> >
> >Recently (1.12.2009) there was a similar question on the forum, I think.
> >Aizaz gave this answer:
> >
> >
> >
> >==
> >
> >There has been an extension to day type facility recently and is available
> >in the current version. One can define day types in addition to legacy
> >week/sat/sunday from context>calendar>day types. This should ideally be
> > done before defining controls and operations information. Once daytype
> > "summerday"
> >
> >and "winterday" are defined in the calendar (and associated with Julian
> > days of the year), different control laws and schedules can be associated
> > in the same control loop as with week/sat/sunday.
> >
> >==
> >
> >
> >
> >Regards
> >
> >Achim
> >
> >
> >
> >
> >
> >From: esp-r-bounces at lists.strath.ac.uk
> >[mailto:esp-r-bounces at lists.strath.ac.uk] On Behalf Of Lukas Swan (Dal)
> >Sent: Donnerstag, 7. Januar 2010 22:00
> >To: esp-r at lists.strath.ac.uk
> >Subject: [esp-r] Zone control sensors - cannot change with control law?
> >
> >
> >
> >Hello-
> >
> >
> >
> >I am modeling a house that has multiple zones and both heating and
> > cooling.
> >
> >Each zone has an independent electric baseboard convective heaters and
> >independent thermostats (i.e. individual zone sensor and actuation).
> >
> >There is also a central cooling system that distributes to each zone
> >proportionally (volume based) and is controlled by a single thermostat on
> >the first floor level (i.e. central sensor and distributed actuation).
> >
> >
> >
> >I was planning on modeling this using zone control loops.
> >
> >Heating during heating months would be completed using a basic controller
> >for each zone with the sensor and actuator at that specific zone's air
> >point.
> >
> >Cooling during other months would be completed using a master/slave scheme
> >(Laws #1 and #21), where slave zones would then reference the master zone
> >air point as the sensor.
> >
> >
> >
> >However, it appears that the specification of the sensor and actuator are
> >outside the scope of a particular period, and are fixed for a given
> > control loop.
> >
> >Also - it appears that each zone can only reference one control loop.
> >
> >
> >
> >Does anyone have a solution to this problem?
> >
> >
> >
> >Thanks,
> >
> >Lukas Swan
> >
> >Dalhousie Univ.
> >
> >Canada
>
> _______________________________________________
> esp-r mailing list
> esp-r at lists.strath.ac.uk
> http://lists.strath.ac.uk/mailman/listinfo/esp-r

_______________________________________________
esp-r mailing list
esp-r at lists.strath.ac.uk
http://lists.strath.ac.uk/mailman/listinfo/esp-r

*******************************************************************************************************************************
This email has been scanned by the Altman Email Security System.
For more information please visit www.altman.co.uk/emailsystems

*******************************************************************************************************************************
*******************************************************************************************************************************
This email has been scanned by the Altman Email Security System.
For more information please visit www.altman.co.uk/emailsystems

*******************************************************************************************************************************