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

[Aizaz Samuel]

Georgios,

There is a bug in the control file read. If a control file already exists and 
the user increases the number of day types. The crash occurs because the 
control file reading subroutine expects to find information for the 
additional day type defined but of course does not find it there. Will get 
round to fixing it when I get some time:)
The alternative is to define day types before defining controls -- this may 
not always be an option and for these cases the user has to dereference the 
control file, increase day types and define controls again.

I agree further that Lukas' question is more complicated and so I did not 
forward the day types extension as a solution. Temporal data may also not be 
suitable because of the master - slave control he mentioned in the original 
mail because temperatures are only known at simulation time. The simplest 
solution could be to have a lookup table that allows different control loops 
to be assigned to different zones based on day types (or other such 
parameter)

Cheers,
Aizaz


On Tuesday 12 January 2010 15:20, Georgios KOKOGIANNAKIS wrote:
> 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
>
> ***************************************************************************
>****************************************************