Archmage's profile - activity

Yes, this is correct. PV panels are assumed to just run whereas other generators that consume fuel to make electricity can attempt to respond to dispatch controls.

That warning can happen when the Sandia model gets wacky. It seems this usually hits when the sun is near the horizon, and wouldn't be producing any significant power yet anyway. But often it appears that the model input coefficients are the culprit. The Sandia model has a vast number of input coefficients and getting a set that is internally consistent is a challenge.

The increase in cooling setpoint results in lower volume of air flow into the zone. That is where the cooling savings come from. But at the same time the lower volume of 55F supply air requires less reheating (to the heating setpoint).

Here are a couple workarounds, but I haven't tried them:

• If there is just one baseboard on the plant loop you could actuate the pump's flow rate schedule to limit the flow available.

• It might work to put a LoadProfile:Plant object on the same hot water branch in front of the baseboard's connection and actuate it's mass flow rate (with no load).

It appears this slow down has to do with the use of dynamic shading surfaces. An issue has been filed for the development team to look into it (https://github.com/NREL/EnergyPlus/is...). But it may turn out that this slow down is expected after a bug fix that corrected diffuse sky modeling with varying transmittance shading surfaces (and now that the onerous calculations are being done right they take longer).

Yes, there is a good chance the surfaces are facing the wrong direction, that is the inside face of a surface might not be facing toward its assigned thermal zone. The surfaces have an inside face and and outside face and the order of vertices and geometry rules are used to determine that orientation. If it is wrong then there are severe problems with solar distribution among other things. EnergyPlus will report some warnings about floors being upside down when this problem is occuring.

I think you want Surface Outside Face Incident Solar Radiation Rate per Area.

Could you explain what you mean by "vertical" here?

The Component Sizing Summary table report includes all types of HVAC devices and should be complete.

You might find some cases where some details are missing that would be needed to create equivalent hard-sized versions of autosized IDF input objects (if that is your goal). The Engineering Reference documentation for the sizing calculations might need to be checked for some constants. The EIO output file is another important source for sizing information and not all of it is in the SQLite file (though it is being added for 8.7).

These are not necessarily problems that need to be fixed, but...

For # 1, some zones just have no heating load. You can add some infiltration or a fake cooling load during the winter design day to get a non-zero design heating load.

For #2, you could increase the resulting design air flow rate by raising the value for Zone Cooling Design Supply Air Temperature from 12.5C to something higher, say 14.0 C. Then you won't trip the minimum limit on the Flow/Capacity ratio. The idea is that DX coil models have a range of flow/capacity that is valid and when autosizing the range is enforced, so there needs to be an appropriate balance between air flow rate and cooling capacity.

This is fairly common issue. The zone's design heating load is used to size the reheat coil and if that load is tiny or zero the reheat coils do not come out with enough capacity.

One way of getting some design heating load is to use OtherEquipment (now with the fuel type set to None) with a negative value for the power. A negative internal gain will provide cooling to the zone and thus a design heating load. I use something lik e -20.0 W/m2 or so. Use the OtherEquipment schedule so that the loads occur only during heating design days by using the day type called WinterDesignDay.

The 0.01 m value is hard coded for collinear points (https://github.com/NREL/EnergyPlus/bl...). There is a difference between the minimum precision (1 mm) with which geometry is modeled and the minimum distance between two vertices. The idea is that the resolution of geometry modeling calculations should be a bit finer than the resolution you can enter for geometry on input. The Engineering reference could be clearer but it is talking about resolution and doesn't actually say what the collinear check is, that is in the warning message.

I cannot help with the OS measure, but looking at this it seems you may be missing the IDF objects called RoomAirModelType and RoomAir:TemperaturePattern:UserDefined that are also needed here to setup a zone to use the constant gradient pattern.

Hi, I would like to run simulations of the thermal (heating and cooling) in order to determine the energy required in both cases. I would like to replace the glass thermal transmittance value (U-factor WindowMaterial: SimpleGlazingSystem) of random values that have determined an excell files and reported in the cvs of energy plus the scheduleFile. you can make such a procedure chart using the energy management system ???? how could I ??

Yes it should be possible to do this with EMS, but it would be cumbersome. You may end up wanting to script the creation of the input objects rather than schedule values. There is an example called EMSThermochromicWindow.idf that should be helpful starting point, it is also discussed in the EMS application guide as Example 13. There are other posts on UnMet hours related to using EMS to manipulate constructions for dynamic performance, eg. https://unmethours.com/question/16819...

For your case you would need to set up 8760 sets of the IDF input objects called Construction, EnergyManagementSystem:ConstructionIndexVariable, and WindowMaterial: SimpleGlazingSystem, that define the window for each hour (that is if they are all really unique). EMS can only swap out entire constructions over time at a surface, not modify the properties of a construction.

The EMS variable you define in each of the EnergyManagementSystem:ConstructionIndexVariable objects will need to be used in long EMS program(s). I believe the maximum length of an if-elseif logic block is 200, so you may need like 44 seperate if-elseif statements to be able to map each hour to actuate the surface's construction by setting the EMS variable. Unfortunately, the schedules can only provide you number values in EMS, but the EMS variables for a construction are variable names that cannot be a number. You could get the hour of the year (or any useful flag value) from a schedule to use in the program logic. Or there are built in EMS variables called DayOfYear and Hour to determine when during year the EMS program is running. This is how the if-elseif could start out.

EnergyManagementSystem:Program,
ZN_1_wall_south_Window_1_Control,  !- Name
IF ( ( Hour == 0 )  && ( DayOfYear == 1 ) ),    !- Program Line 1
Set Win1_Construct = Window_hour1,  !- Program Line 2
ELSEIF ( ( Hour == 1 )  && ( DayOfYear == 1 ) ),!- <none>
Set Win1_Construct = Window_hour2,  !- <none>
ELSEIF ( ( Hour == 2 )  && ( DayOfYear == 1 ) ),!- <none>
Set Win1_Construct = Window_hour3,  !- <none>
...

Do you mean you want to change the window over time during one simulation? or do several simulations with different windows for each?

I am not sure about OpenStudio, but the ZoneVentilation:WindandStackOpenArea input object has a field called Maximum Wind Speed. There is no modeling of vortexes, but we know it is correlated with strong wind. The idea is that the papers will fly when the outside wind gets above some speed so people will shut the window. So if you pick a wind speed limit, the model can shut off open area ventilation during those times, to avoid over-prediction of natural ventilation.

What control method are you using for the CHP engine?

There can be plenty of heat exchange in and out of all kinds of surfaces with "Adiabatic" boundary condition regardless of symmetry in the construction. The same boundary conditions get applied to both faces of the surface, but the surface still can have heat capacity and it is likely to be hotter or colder than the surroundings at times. An asymmetrical construction might not end up with symmetrical surface temperature results at the faces at any given time, but over time it will average out. It is just a temporal artifact of how thermal storage charging and discharging happens.

I suggest you give it a try. There is an example file called EMSCurveOverride_PackagedTerminalHeatPump and discussion of Example 11 in the EMS Application Guide. Use calling point called InsideHVACSystemIterationLoop.

If it is variable flow, I'd guess SetpointManager:ReturnTemperature:ChilledWater could come fairly close to replicating the desired behavior after some trial and error to find a return setpoint that met the logic, depends how many different chilled water loads you have. Otherwise EMS, no examples.

You can get the Electricity:Facility as a timeseries data, using Output:Meter, and then process that into those variables. Also report out the Schedule Value for the schedules that define when it is peak time, they can help you sort between Peak* and OffPeak*. Demand power is just the Joules from the meter divided by the reporting interval duration in seconds, but this is more accurate for the finest resolution data you can get. TotalDemand also includes a definition for a sliding average window that is often less than an hour. So if you want to be able to replicate the values reported by the tariffs, you will need to use at least timestep fequency data rather than hourly.

I would speculate that you didn't adjust wind speed for height above ground. The weather file wind data is usually for a 10 m height above ground. When apply this model, EnergyPlus will adjust this speed for each zone in the model based on the height of the zone's centroid, 1.5 m in your case. The setting of Terrain in the Building object has an impact on this adjustment -- see the section in Engineering Reference called Local Wind Speed Calculations

You also don't mention how you dealt with the stack part of this model, so that could be a factor in your comparison.

The water that the roof gets will be the sum of rain (from Site:Precipitation) and irrigation (from RoofIrrigation).

The Average Total Annual Precipitation should equal the sum of the schedule. You can report an output variable called Schedule Value to check the values of your schedule pattern.

Do you have any on-site electricity generation?

It sounds like you are using the Site:Precipitation object. Have you set both the Design Level for Total Annual Precipitation and Average Total Annual Precipitation to the same value? The way it works is a little tricky but intended to be able to scale the rainfall pattern up or down to model wetter or drier years by just changing one number in the Design Level.

I agree that Sandia is considered the most representative of real world performance. I seem to recall there may be some ways of generating input from more detailed models rather than always requiring physical testing. The one-diode has shown numerical problems in the solver and tricky sensitivity to input sets. The robust and easy PhotovoltaicPerformance:Simple is a useful fallback, just lop off 2% efficiency or so to be conservative and catch balance of systems losses.

Which WAHP model are you using? Have you tried using heat transfer pipes, e.g. Pipe:Indoor?

ResultsViewer might be choking on the "HVAC Sizing Simulations," try setting Do HVAC Sizing Simulation for Sizing Periods to No in SimulationControl and see if the problem goes away. If you want to use coincident plant sizing then may need to switch to a different plotting tool. Try with Run Simulation for Sizing Periods set to No as well. Also old translated example files don't usually have a name in the RunPeriod object and ResultsViewer seems to work better if you enter a name.

The annual tabular summary reports show the number of hours that were used in the annual summations at the top of the table report file. If that says 8760 hours, you can be sure the tabluar reports are for the one year. If you are using raw meter reports at the RunPeriod frequency, then you can verify their timeframe by checking that the values agree with the annual summary tables.

I don't know about OS, but in EnergyPlus there is an input object called LoadProfile:Plant. This can be used to put a load on a chiller plant and run models with no building.

They are not manual, but this set of output variables provides results that are useful for understanding what is driving heat transfer in the zone air balance.

• Zone Air Heat Balance Internal Convective Heat Gain Rate [W]
• Zone Air Heat Balance Surface Convection Rate [W]
• Zone Air Heat Balance Interzone Air Transfer Rate [W]
• Zone Air Heat Balance Outdoor Air Transfer Rate [W]
• Zone Air Heat Balance System Air Transfer Rate [W]
• Zone Air Heat Balance System Convective Heat Gain Rate [W]
• Zone Air Heat Balance Air Energy Storage Rate [W]
• Zone Air Heat Balance Deviation Rate [W]

This output variable is probably the simplest way to compare different opaque surfaces (of relatively lightweight contruction).

• Surface Average Face Conduction Heat Transfer Rate per Area [W/m2]

I think you want to go with the alternate option you describe at the end.

maybe your IDF editior is not picking up the new IDD?

This is a new check in EMS added as of version 8.6. It now checks that variables used on the right hand side of an expression have been initialized before being used.

The error message is saying that you need to be sure SOLAR_BEAM_INCIDENT_COS has been assigned a value before using it in that expression.

oh interesting, I never did that step 10 and use build\src\EnergyPlus\ for that.

SHGC is a specific metric for window performance, but it is not something that EnergyPlus ever uses directly during a simulation. EnergyPlus will report out a value for center-of-glass SHGC based on the window description, but that is for a special case used for standard reporting with direct normal incidence and fixed thermal boundary conditions. As you say, a real time SHGC, were such a report available, would vary over time with incidence angle as well as the thermal conditions surrounding the window. EnergyPlus already does take this into account.

There is a section in the Engineering Reference called Calculation of Angular Properties that describes how angle of incidence is handled for window performance.

The WindowMaterial:SimpleGlazingSystem has an SHGC input, but it is used by a model that then constructs a more detailed representation of the window, with a different angular model (see table Normalized Transmittance Correlations for Angular Performance), and it would also have a time-varying "SHGC."

Are you thinking of HVACTemplate processing which makes an expanded IDF file?

Should be the WAHP units running during heating. They have a high COP but do use electricity at the zone unit.

No, sorry, the WindowMaterial:SimpleGlazingSystem does not use the Equivalent Layer model.

The window model is selected by the type of construction object used to describe the window. A single window is only going to have one model at a time, but the building could have different window models assigned to different windows. The input object "Construction" will trigger the original model in EnergyPlus which is similiar to older versions of the Window program. The input object "Construction:WindowEquivalentLayer" will trigger the ASHWAT model. There is also a third option using the input object "Construction:ComplexFenestrationState."

As to which is better, it depends on how complex the window system is and what kinds of layers you need to model. The original model is fine for plain insulated specular windows. If you have special fabric or screen materials, the ASHWAT equivalent layer model might have some advantages on the ease of input. The complex fenestration can handle bidirectional light redirections.

The DX coil cannot just sit on the airloop, which kind of wrapper are you using with the DX coil, unitary or coil system?