Thanks @MingboPeng,
I’m aware of how Grasshopper handles data management; what confused me is that it usually uses a “Longest List” approach:
@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.
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.
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!
