This file can be recognized:
When you open the grasshopper, in rhino commands it will display the openstudio version that is loading, can you confirm this?
Can you also check if this works:
@MaxMarschall could you do me a favor to test this file?
ScheduleFile.gh (4.8 KB)
Note: it might ask you to locate the “C:\openstudio-2.9.1\CSharp\openstudio\OpenStudio.dll”, for your case please relocate it to “C:\openstudio-2.9.0\CSharp\openstudio\OpenStudio.dll” if you have 2.9.0.
Ok @MaxMarschall I checked with OpenStudio team about this issue, there were some updates on dealing with ScheduleFile and ExternalFile object. I just updated the ironbug for this, and did some tests:
Ironbug.20200429.zip (288.9 KB)
20200429_ScheduleFile_Example.gh (562.0 KB)
Here is the daily schedule in csv to control system’s availability, and below is the hourly cooling results that matches the csv schedule.
Let me know if this works.
@MingboPeng
Hallelujah, it works now!! Thanks for chasing up on this.
I also tested it with my custom subhourly csv schedule and it’s behaving as expected now:
Thanks @MingboPeng, seems to be working now.
I have a different question that I’m reluctant to put in another thread since I’m still using the ScheduleFile component that others won’t have access to, so I’ll just ask here:
My definition now has A LOT of duplication since each zone has a different schedule and I’m defining the HVAC systems individually.
I have tried making this more efficient but I’m getting the error message
- One zoneEquipmentGroup or zone equipment per zone is needed. Currently you have 2 zones, and 1 equipment
The issue seems to be that while the
HVAC Params component is outputting a list, the PT HeatPump component is not.
ironbug test.gh (676.1 KB)
Is there a way around this?
It is good to see you are actually thinking to remove duplicates.
This is more about data management in Grasshopper.
If you use Param Viewer to check your output data of each component, it might help you to understand why it failed.
PTHP won’t take more than one parameter list, as you see below it only outputs one PTHP. ThermalZone requires the equal amount of zone equipment as input HBZones. This is why it is complaining.
You can use Graft and Flatten ( Here is a tutorial that explains data tree) to achieve what you want.
Thanks @MingboPeng,
I’m aware of how Grasshopper handles data management; what confused me is that it usually uses a “Longest List” approach:
Following that logic, I would have expected the “PTHP” output to be a list that is as long as the “params_” input (in this case 2).
Do you understand what I mean? I think it might be confusing for Grasshopper users if they have to manually graft and flatten lists in these cases.
@MaxMarschall
I made this on purpose.
For a bigger project or a commercial building, the HVAC system is more complex than this single zone system PTHP. There are many HVAC components that much be co-exist within two locations: such as water-source coil, ONE coil has to be connected to both air system and water loop, which means this coil can not be passed to the next component as a duplicated value that basically is all other grasshopper component is doing.
I use your example to explain this problem:
Screenshot below: water coil is duplicated within air system when an uneven list passed to “B”, this creates two air systems with two water coils. But not all water coils are connected to the water loop at the same time. This creates the problem that water coils within air system won’t work correctly in simulation.
Here is how it should be: make two water coils to match input list B, to ensure all coils are connected to water loop’s supply side. So the same water coil is located at two places (water loop, air system) at the same time. In other words, air system and water loop is connected by water coil.
This is the background, but the reason I use Graft and Flatten here in PTHP is:
The fan you added to PHTP actually can be duplicated, and it cannot co-exist in multiple places. The moment you pass grafted parameter list (two trees), PTHP duplicates fan for each tree, which is ok for this type of system.
This is the explicit way to build this system that works exactly the same as above.
You may have noticed some Ironbug components have three dots at its bottom left corner. It means this component has a hidden input for duplication.
You can also use IB Duplicate component to do this.
So the conclusion is:
In the very early version of Ironbug, I made some of works done automatically. But it confuse users even more, as it completely changed the some grasshopper components behaviors that totally against the way it works in grasshopper.
Therefore, I switched to currently workflow on purpose to ensure users to match the data structures by themselves instead of assuming grasshopper would figure this out for you. From my experience on HVAC, this is also better for user to understand the relationship how each HVAC element is connected.
1 Like
I have noticed that I am getting heating energy even during times when my custom heating schedule file is “Off”. I think that the reason for this may be the issue that was mentioned in this thread before, namely that there are 2 different heating components in the system. Here is where I set the availability:
…but this is the output. You can see that the cooling is doing what it is supposed to do (I gave it the same schedule as the occupancy), as is the first heating output “Heating electric energy”. The second output “Heating electric energy for COIL” is NOT considering the availability schedule:
Is there any way to get rid of that second heating element altogether, or otherwise to access it and give it an availability schedule?
Heating availability.gh (615.5 KB)
I have uploaded the schedules here.
Cheers,
Max
I can’t believe I missed that input… I ended up altering the actual IDF in post but this is of course much better, thanks!