EMS as Additional String

[AMIRTABADKANI]

Dear Community,

I am trying to overwrite the EP Transparency Schedule of a simple shading by EMS coding as an input to E+ engine.

I defined two sensors: one is the sunlit fraction on window, and the other one is the indoor operative temperature. I controlled these two sensors through available actuator in E+, and it seems Honeybee recognizes the EMS perfectly and changes the Trans.Sch according to the sensors, but the operative temperature does not change when you add/remove the EMS string.

This picture shows the results when I used EMS and it changes the Transparency schedule default to what I expected perfectly …

But here when I disconnect the EMS string, the schedule will return to what I connected manually as a fraction of ‘1’ which means completely transparent for the whole year, but the operative temperature still remains the same…

test03-EMS.gh (636.9 KB)

Regards
Amir

[mostapha]

I would start by checking the values that eventually effect the operative temperature and go backwards to find the source of the results. Did you try to check the amount of radiation that passes through the window and surface temperature of the windows in both cases? That should be a good starting point.

I didn’t open the file but you should also keep in mind that the calculation is done for the center of the zone so it will depend on the view factor from the center point to this window.

[AMIRTABADKANI]

Thanks @mostapha for your reply,

Both window outdoor temperature and the energy flow are the same which shouldn’t be…

This is excluding EMS string…

And this is including the EMS…

test03-EMS.gh (624.4 KB)

BUT, when I copy the overwritten schedule into a panel (the one that I obtained after implementing EMS) and import it to the EPTransschedule of the Hb context component like a normal case, the results will change proportionally…

[chris]

@AMIRTABADKANI ,
From your tests it seems that you may not be setting the right parameter to change the transparency of the context shade. Just knowing that E+ has a lot of outputs (some of which are not too helpful), the Weighted Shade Fraction Schedule might not have any real bearing on the simulation that you are trying to run here.

The UnmetHours forum might also be a better place to ask questions that are this deep down the rabbit hole of E+. You are definitely stretching my expertise here

[AMIRTABADKANI]

Thank you @chris for your reply…

Actually, the ‘Weighted Shade Fraction Schedule’ is not an output exactly, it is a random name for the output that can be anything, it is just for naming …

I also asked on unmethours forum several weeks ago here, but I still could not get a proper response yet for what I want to do, however I also talked with E+ developers, and it seems at the moment the available actuators are limited for now…

Getting back to my question here, my point is that the results remain constant whether an additional string is connected or not in my case, which shouldnt be … but when I overwrite the schedule manually, the results will change as I expected …

Cheers
Amir

[SamueldeVries]

Hi Amir,

A student in our group has tried the same (setting exterior shading surface transmittance through EMS) and had the same difficulties. I haven’t tried this myself but I believe (maybe you can test if I am correct) the following might have be associated with your problem:

• From the engineering reference within ShadowCalculations object (access through HB shadow par withing energysimPar): ‘TimestepFrequency is required to capture changes in shading transmittance.’

• I recall from the students project that she still had troubles even with this setting applied. I suspect (but am not sure) not that the ShadowCalculations take place before the runPeriod (or at lest before the predictor calling moment) . She also noticed that the only way to get any recognisable affect was through a predefined schedule. If this is true then changing transmittance of an exterior shading object through EMS might be impossible.

• Also check this part from the input output reference:

• “Two choices are available here: SimpleSkyDiffuseModeling and DetailedSkyDiffuseModeling. SimpleSkyDiffuseModeling (default) performs a one-time calculation for sky diffuse properties. This has implications if you have shadowing surfaces with changing transmittance (i.e. not all opaque or not all transparent) during the year. The program checks to see if this might be the case and automatically selects DetailedSkyDiffuseModeling if the shading transmittance varies.”
  I would say, make sure your initial schedule varies because else the program might still use the simple model which computes a one-time calculation (and therefore overwriting a schedule will have no effect).

• From the students project she concluded some more behaviour leading from varying transmittance exteriod shading that seemed unusual. When scheduling this, she also saw some unexpected behaviour of daylighting controls within EnergyPlus (I have not looked into this in detail, so this is just a heads-up).

• From your other post I conclude that you are trying to model electrochromic glazing. Using energyPlus’s built in models for electrochromic glazing seems more straight forward. Attached you will find a GH definition with an EMS script added through additional strings. This one acuates an exterior shade but you change the number set by ShadeIsOn to switch an electrochromic window to a darker or lighter state (see EMS application manual). You will have to find a way to implement an electrochromic window in HB or overwrite the idf afterwards (maybe add the whole fenestration surface into the additional string).
  20190322_Tsk56prtCref_HB_EP_Example.gh (990.3 KB)

Kind regards,

Samuel

[AMIRTABADKANI]

Dear @SamueldeVries

I really appreciate your detailed response,

However, my case is a bit different, but I ll get back to you soon when I reached a conclusion, I am still investigating different possibilities including yours and I hope I ll find a way.

Cheers
Amir

[SamueldeVries]

Hi @AMIRTABADKANI,

Sorry. I think I had multiple windows open and started mixing up different posts. Is it correct you’re trying to model a three dimensional shading surface (sticking out of the facade plane)?

I don’t know how important it is to have a detailed picture of the internal distribution of transmitted solar radiation, but in case it is:

You can take a look at the four phase method in Radiance (don’t think HB supports this though).
This could give you an idea of the amount of transmitted solar to inform scheduling or EMS control of more traditional shading objects in EP.

(From the Subramaniam manual on Matrix based methods)

EP also allows you to overwrite absorbed(or incident?) solar on interior surfaces and it should also be possible to use the facade matrix as a ComplexFenestrationState in EP. There’s a few unsolved UnmetHours problems connected to these approaches so I would be careful.

Would be interested to learn what you’ll find.

Kind regards,

Samuel

[AMIRTABADKANI]

Dear @SamueldeVries

Thanks for sharing the materials, and Yes, I am aware of phase modelling but my case is not concerning about the simulation method or CFS systems, it is more related to control a shading system at this stage mostly for external shadings not even EC windows.

For the first step of my proposal, I am trying to model a simple Venetian Blinds here, but instead of using HB default components I tried to use only additional strings, because when you use the HB components, they write the idf file with many ‘blank’ fields that does not answer my case.

Consider I want to control slat angles of VB based on indoor illuminance and DGI, without using Radiance and DaySim, only within E+ in HB.

I wrote an EMS code to test the control strategy, but surprisingly, results of some hours remain the same after I disconnect the EMS code (which slat angles are constant throughout the year based on a predefined schedule as a reference case).

Here is the EMS code i used:

EnergyManagementSystem:Sensor,
S1, !- Name
D1, !- Output:Variable or Output:Meter Index Key Name
Daylighting Reference Point 1 Illuminance ; !- Output:Variable or Output:Meter Name

EnergyManagementSystem:Sensor,
S2, !- Name
D1, !- Output:Variable or Output:Meter Index Key Name
Daylighting Reference Point 1 Glare Index ; !- Output:Variable or Output:Meter Name

EnergyManagementSystem:Actuator,
myA1, !- Name
ASF, !- Actuated Component Unique Name
Schedule:Year, !- Actuated Component Type
Schedule Value; !- Actuated Component Control Type

EnergyManagementSystem:ProgramCallingManager,
MyComputedTransProg, !- Name
BeginTimestepBeforePredictor, !- EnergyPlus Model Calling Point
myProgram1; !- Program Name 1

EnergyManagementSystem:Program,
myProgram1, ! Name
Set Daylit = S1 ,
Set DGI = S2 ,
IF (Daylit <= 3000)&& (DGI < 22),
Set myA1 = 90 ,
ELSEIF (Daylit > 3000) && (DGI < 22),
Set myA1 = 25 ,
ElSEIF (Daylit > 3000) && (DGI > 22),
Set myA1 = 0,
ENDIF ;

EnergyManagementSystem:GlobalVariable,
myglobeA1; !- Erl Variable 1 Name

EnergyManagementSystem:OutputVariable,
WeightedShadeFractionSchedule, !- Name
myglobeA1, !- EMS Variable Name
Averaged, !- Type of Data in Variable
SystemTimestep; !- Update Frequency

Output:EnergyManagementSystem ,
Verbose ,
Verbose ,
Verbose;

As you see I am trying to overwrite the ASF schedule that are assigned for slat angle schedule by EMS based on two indoor sensors.

Here is the result when EMS applied, Check hour 10.

and when EMS is not used, and slat angles are constantly in horizontal position (reference case).

As you see for example, hour 10 is receiving the same daylight intensity even when the blind position is 0 degrees which means fully closed.

Do you have any experience on this? What am I missing here?

Regards
Amir

[SamueldeVries]

Hi Amir,

I think this has to do with the availability of information at a particular moment in the simulation. When using a sensed variable from within EP you can only sense retroactively and not predicatively. Meaning glare has to first be exceeded before your system can respond to it.

You’re using DGI as an input for your program and your sampling this value at BeginTimeStepBefore predictor so your getting the value that DGI was set to at that moment. I suspect (not sure) that the daylighting models are only called after that moment in time. If this is correct than the DGI you’re requesting is that of the last timestep.

It isn’t clear whether this is what you want or not. If you’re trying to model user behaviour it might be. If you’re trying to model an automated control system then this might give an unrealistic control delay.

As you’re using DGI as control input it looks like you have some kind of ideal control in mind, so in case you do not want this delay; shortening the timestep can help minimize it’s duration but will never take it away completely (some delay is also realistic for a control response). If you want to loose it completely you’ll have to work in a predictive way (for instance: by saving predefined daylight/glare responses for each of the shading states into schedules and referencing these from within EMS).

Another thing to keep in mind when looking at outputs when using EMS is where and when this output is created. It looks like now your outputting only your sensed EMS variables but I recommend also looking at what EP actually used for slat angles, indoor illuminance and glare. For the slat angle this would be:

Output:Variable,
*, !- Key Value
Surface Window Blind Slat Angle, !- Variable Name
Timestep; !- Reporting Frequency

This is a matter of personal preference, but, you can also actuate the slat angle directly without all these schedules:

EnergyManagementSystem:Actuator,
FSD_Window103_Blind_Slat_Angle, !- Name
FSD_Window103, !- Actuated Component Unique Name
Window Shading Control, !- Actuated Component Type
Slat Angle; !- Actuated Component Control Type

Maybe we should follow Chris’s suggestion and move this discussion to unmet-hours though.

Gr,

Samuel

[AMIRTABADKANI]

@AMIRTABADKANI

As you see for example, hour 10 is receiving the same daylight intensity even when the blind position is 0 degrees which means fully closed.

Whoever is interested in this topic, this issue has been solved after some playing.

First, as the actuator is calling the sensor before predictor (which is the only way to control blinds), all the time steps will be shifted for one hour.

If you change the time step for example to 6 and run the simulation for each time step (not hourly), you see the blinds angle are actually a function of previous hour results, and the previous hour’s results are a function of previous hour’s blinds angle and so forth.

It is a bit tricky how EMS works here but at least it works properly, however, you have to take into account this delay may cause visual discomfort in certain time intervals, but this is the only way to do if you are trying to control shading system based on DGI or indoor illuminance.

Cheers
Amir

[rakhmat.aditra]

@AMIRTABADKANI

If you change the time step for example to 6 and run the simulation for each time step (not hourl

Hi Amir,

I have been reading this issue, and I have similar problem. I see that you already got your solution.
I still do not get what does it means with “run the simulation for each time step”. Is it setting the shadow calculation into TimestepFrequency, or setting the simulation output per timestep? Because neither of them works in when I tried in the file that you share.

Looking forward for your reply,
Rakhmat