Welcome to the TRNSYS Users Forum.
The forum is a place where people can interact and have discussions about different topics involving the use of the TRNSYS software package. Here you can post topics for discussion or questions on using TRNSYS and get advice from other users or TRNSYS experts. This forum is not intended for detailed technical support. Users should contact their distributor’s hotline for such assistance.
Some tips for success on using the forum:
- Follow the Forum Rules posted in Forum Administration.
- There are categories for different types of topics and questions. Post your topic or question into the proper category.
- Before posting a topic or question search the existing topics (and the TRNSYS Users listserv archive or Post archive) to see if a similar topic or question has already been answered.
- Use a descriptive topic name. Don’t use attention getting subjects, they don’t get attention and only annoy people.
- State the version of TRNSYS and which add-ons your are using.
- Include enough specific details for your topic of question to be answered. Just posting “Why am I getting an error?” without describing the specific error and what you are trying to do when you get the error will not receive a response that fixes your issue.
- Remember when people help you, they are doing you a favor. Be patient, help people out by posting good descriptions of what you need help with, and be polite even if a response does not solve your issue.
- Moderators may edit your post for clarity or move your topic to a more appropriate category.
I don't see any way to write an IF statement in the equation block. Is there any way to do this?
While there is not an "IF" function in the equation editor, some of its functions may be combined to get the same result.
The equation editor has the following logic functions: GT (greater than), LT (less than), GE (greater than or equal to), LE (less than or equal to), EQ (equals), NE (not equal), AE (approximately equal), AND, and OR. The first six functions listed take two arguments, and if the logic applied to the first argument relative to the second argument is TRUE, the function returns a value of 1, else it returns 0. So for example, GT(Arg1, Arg2) would = 1 if Arg1 > Arg2, but it would = 0 if Arg1 <= Arg2. You can read more about these and other functions in the TRNEdit documentation, under "Available mathematical functions".
Say you want a setpoint to be Setpoint1 when a building is occupied, but Setpoint2 when a building is unoccupied. If Occupied is a variable that = 1 when the building is occupied, but = 0 when the building is unoccupied, you could write
[1] SetpointToUse = GT(Occupied, 0.5)*Setpoint1 + LE(Occupied, 0.5)*Setpoint2
The equation above would set SetpointToUse = Setpoint1 when Occupied is 1, and it would set SetpointToUse = Setpoint2 when Occupied = 0. "Occupied" could come from a forcing function or data file created by the user, or it could be set in its own equation based on time of day, etc., using outputs from the time values component (Type 21) and similar logic.
You could also write
[2] SetpointToUse = EQ(Occupied, 1)*Setpoint1 + NE(Occupied, 1)*Setpoint2
or even, in this case,
[3] SetpointToUse = Occupied*Setpoint1 + (1-Occupied)*Setpoint2
... but if Occupied = 0.99999999 or Occupied = 1.00000001, you would get Setpoint2 with equation [2], and you would get something slightly off from the desired setpoints with equation [3] as well. Even if you're 99% certain Occupied can only equal 1.000000 when the building is occupied, it can help to leave a little room for error, just in case some floating point math translates that 1.000000 into a slightly greater or lesser value.
A final note: setting inputs based on logic in an equation block like this works best if the critical variable (Occupied) is derived from a schedule, an outside air temperature, or some other input that can be known given *only* the simulation time, and is independent of other equipment. If you were to, for example, set a control signal based on the outlet temperature of some equipment, you could run into a situation where the outlet temperature changes, which changes the control signal, which (indirectly, perhaps) causes the outlet temperature to change again, which causes the control signal to change again, which ultimately results in a convergence problem. It would be better to use a controller component to set that control signal; controller components have oscillation limits, which only allow the signal to change so many times before it is "stuck" for the rest of a timestep. A "stuck" controller can still be a problem, if it happens frequently, but it's an easier problem to troubleshoot than a convergence problem, and (if the oscillation limit is an odd number) it still allows the controller to cycle on and off in a crude way.
