water and air system creation

[alan.jackson]

What ability is available for the end user to create custom systems for hydronic and air systems. For example, rather than have supply water from a chiller be labeled as "Hydronic Supply", it would be labeled "Chilled Water Supply".

Thanks

Alan Jackson, LEED® A.P.
Mechanical Engineer
Buro Happold Consulting Engineers, PC

[kyle.bernhardt]

Those are system types and impact a number of ways that things interact well beyond just the name, like how things flow inside. You have additional control by just defining a system name. Your "Chiller Water Supply" system is a situation where the liquid is moving in a supply direction, so it's of the Hydronic Supply type, so go ahead and choose whatever you want for the system name.

Most people find it useful to do this and create view filters to tell the difference between systems.

HTH,
Kyle B

[mjdanowski]

for our piping I made a shared project parameter called "Pipe Type" where I specify what kind of pipe it is;
CWR
CWS
SAN
SW etc etc
This parameter is put on all pipes and pipe fittings. I then have filters that essentially check to see which pipe type it is and changes the lineweight respectively (and there is a tag associated with it, so it works rather nice)

[kyle.bernhardt]

for our piping I made a shared project parameter called "Pipe Type" where I specify what kind of pipe it is;
CWR
CWS
SAN
SW etc etc
This parameter is put on all pipes and pipe fittings. I then have filters that essentially check to see which pipe type it is and changes the lineweight respectively (and there is a tag associated with it, so it works rather nice)I'm interested to understand why you chose that solution to the problem. I can see how it solves the problem for you. Is it because you are not connecting your systems consistently? Are you just looking to model things for CDs?

Normally the System Type and Name is inherited on Pipe and Pipe Fittings when their "connected run" is connected to a Family, like an AHU or a Pump. You can then use View Filters according to those system parameters.

I'm not trying to point out that you're doing something wrong, I can see how this works for you, I am just interested in your reasons. It can be really useful for us on the Product Team to hear real-world usage of features to solve tasks.

Cheers,
Kyle B

[mjdanowski]

I'm interested to understand why you chose that solution to the problem. I can see how it solves the problem for you. Is it because you are not connecting your systems consistently? Are you just looking to model things for CDs?

Normally the System Type and Name is inherited on Pipe and Pipe Fittings when their "connected run" is connected to a Family, like an AHU or a Pump. You can then use View Filters according to those system parameters.

I'm not trying to point out that you're doing something wrong, I can see how this works for you, I am just interested in your reasons. It can be really useful for us on the Product Team to hear real-world usage of features to solve tasks.

Cheers,
Kyle B

Well it is kind of in regards to what Alan said in the original post.
My plumbing guys essentially came to me with a list of about 20-30 different types of pipe, ranging from natural gas, to compressed air, to "chemical resistance vent pipe." Each of these pipe types has a different notation tag and/or line pattern associated with it. To change the single line pattern I just used 10-15 filters or so for the most common pipes. These filters will then see a "ERR" in the pipe type parameter for example (energy recovery return) and then translate that line into a short dashed line. Then the engineer can then tag the pipe where he sees fit in accordance to our standard.

However, for things like Domestic Hot Water, Domestic Cold Water, Sanitary where there are system types for what I am trying to represent, I do use a filter based upon the system type. (its just easier) This is unfortunately though, only for the line pattern, for tags on the pipe we also have to use the parameter method. (though its still easier)

However, after reading your post a few times over I think that what you are suggesting might possibly be easier. Right now we use the System Name parameter for what the system is ("DHWH-1 CW Supply" for example) as it makes things a lot less confusing. However, it might be worth making the system name the tag instead to make out filters and tags off of that. However, another system parameter with the name of "System Tag" that is inherited on pipes and what not would be very helpful here if you are looking for ideas.

Correct me if I am not on the same page here as well, I am still a little befuddled in what you are suggesting. :)

[kyle.bernhardt]

You're understanding what I was pointing out. It just seemed to me that you may be creating an extra Shared Param to accomplish something that can already be done with the System Name. If inheritance of System Type and name is an issue, due to lack of connectivity from modeling, then the method wouldn't work consistently. I was trying to figure out if that was the case for you.

[mjdanowski]

You're understanding what I was pointing out. It just seemed to me that you may be creating an extra Shared Param to accomplish something that can already be done with the System Name. If inheritance of System Type and name is an issue, due to lack of connectivity from modeling, then the method wouldn't work consistently. I was trying to figure out if that was the case for you.

Well the system name is something I never though of before, and that might just be easier to deal with. Right now we like to use that as a designation for other information, but perhaps combining the two would also work;

Make the system name "CH-1 CWR" or something like that and then make the filter for all system names which contains "CWR." The only problem would be for equipment designations which overlap pipe designations, but I think we could deal with that, hehe.

Another inherited parameter though for "sub-type" or something like that would be really nice though, I shall add it to the wishlist. :)

[alan.jackson]

Those are system types and impact a number of ways that things interact well beyond just the name, like how things flow inside. You have additional control by just defining a system name. Your "Chiller Water Supply" system is a situation where the liquid is moving in a supply direction, so it's of the Hydronic Supply type, so go ahead and choose whatever you want for the system name.

Most people find it useful to do this and create view filters to tell the difference between systems.

HTH,
Kyle B


Kyle,

Thanks for the response. This method does exactly what I was looking for, I was not aware of the ability to do that.

To take it one step further though. Can the System Name be part of a connector in a family so when a hydronic supply system is created with a chiller it will apply that name to the system? I realize this is just one extra step when creating a system so it may not be worth it, but my reasoning behind it would be to have the automatic ability to assign those properties to systems on the fly as you create them based on the relevant equipment.

Often equipment has multiple types of connections such as a complex air handler, you may have a chilled water cooling, a DX heat pipe, and glycol or steam pre-heat. It would be nice to have the ability to create a glycol system on the fly like you create an exhaust system.

Thanks

Alan Jackson, LEED® A.P.
Mechanical Engineer
Buro Happold Consulting Engineers, PC

[kyle.bernhardt]

At the connector level, currently you define only the System Type and can assign a name to that connector using the the Connector Name parameter. That's useful in situations where you have multiple connectors of the same System Type on a piece of equipment, you will be presented with a dialog to choose connectors and the Connector Name will show up. You cannot define the actual System Name that's generated using that equipment.

This is for a few reasons, but most importantly; A system does not have to be created from a piece of equipment, but rather could be created from a downstream element. If the System Name is defined at that point, what happens when the Equipment is added? Does the equipment override the existing name? Is it disregarded? Does the user want to see a message every time this happens?


I think the current method is pretty painless, with the System Name able to be defined in the Options Bar when the System Editor is active, and provides users the flexibility to create any System Name that they want quickly ans easily. But, that's just my feeling. If you have a use case where it's not sufficient then let us know, we're always open to suggestions.

Cheers,
Kyle B

[alan.jackson]

Kyle

I agree the current method is fairly painless, I was only curios to hear the methodology which I am satisfied with.

Thank you.

Alan Jackson, LEED® A.P.
Mechanical Engineer
Buro Happold Consulting Engineers, PC

[matthew.ferguson]

This seems to work out really well, but how do you get venting to work with this methodology?

Kindest regards,

Matthew S. Ferguson

Buro Happold Consulting Engineers PC

[JoelLondenberg]

This seems to work out really well, but how do you get venting to work with this methodology?
Kindest regards,
Matthew S. Ferguson
Buro Happold Consulting Engineers PC

This was a big annoyance for me as well. In real life the vent pipe is directly connected to the sewer, but we want to display them differently. It seems that means that we cannot physically connect the two and still treat them as separate.