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

Tue Jan 12 16:54:36 GMT 2010

Jon,

There needed to be a code bit to update the control file everytime day types 
are incremented. It is a "simple" matter of reading the control file with say 
3 day types and then writing it out with 4 day types when the user increments 
day types. 

I have made the bug fix in my branch now and it will get into development in 
the normal process of things.

-Aizaz

On Tuesday 12 January 2010 16:12, Jon Hand wrote:
> There would seem to be a conflict between defining a calendar with 4 day
> types and then trying to open an existing model which has a control file
> which assumes three day types.  This 'difference' when found needs an error
> trap.
>
> If you were to create a new model from scratch you would first set
> the calendar and then define controls (which would then notice that
> there were more than 3 day types) and that should work ok.
>
> If you sent me the model that crashed we could have a look at the
> location of the crash and see if there was a way to stop the crash.
>
> -Jon
> ________________________________________
> From: esp-r-bounces at lists.strath.ac.uk [esp-r-bounces at lists.strath.ac.uk]
> On Behalf Of Georgios KOKOGIANNAKIS
> [Georgios.KOKOGIANNAKIS at nottingham.edu.cn] Sent: 12 January 2010 15:20
> To: Aizaz Samuel; esp-r at lists.strath.ac.uk
> Cc: 'Milan Janak'; Achim Geissler
> Subject: [esp-r] Re: Zone control sensors - cannot change with control law?
>
> 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
>
> ***************************************************************************
>****************************************************
> _______________________________________________
> esp-r mailing list
> esp-r at lists.strath.ac.uk
> http://lists.strath.a