Pipe System to same Pipe System of a different name

[dennis]

Here is the scenario:  I have a Mens Restroom and a Womens Restroom side by side.  In the Womens room I create by selecting the fixtures a Cold Water System named: DCW Womens Restroom.  Then do the same for the Mens room named: DCW Mens Restroom.  Then when I connect the two systems to then run to the main water line, the entire system adopts one or the other named system, so both restrooms end up on DCW Womens Restroom (or the mens, not sure why it choses one over the other at any given time.)

So, it appears to me that eventually all your cold water systems will end up on the same Cold Water SystemName, hot water system on the same name, etc.  Is this what everyone else is finding? -Or- am I once again missing a simple step to keep the System Names set?

[dennis]

Here is the scenario:  I have a Mens Restroom and a Womens Restroom side by side.  In the Womens room I create by selecting the fixtures a Cold Water System named: DCW Womens Restroom.  Then do the same for the Mens room named: DCW Mens Restroom.  Then when I connect the two systems to then run to the main water line, the entire system adopts one or the other named system, so both restrooms end up on DCW Womens Restroom (or the mens, not sure why it choses one over the other at any given time.)

So, it appears to me that eventually all your cold water systems will end up on the same Cold Water SystemName, hot water system on the same name, etc.  Is this what everyone else is finding? -Or- am I once again missing a simple step to keep the System Names set?

[Anonymous]

Yep - but surely that's the point of a system. The DCW system you are describing is a building system not an individual system. Presumably the DCW starts from either an incoming mains water meter or from a storage tank and then is distributed around the building serving many different areas. Therefore I see systems as building based not zone based.

If you needed to note what zone things are in then schedules should solve that or add a specific parameter to the relevant categories to manually state what areas things are in.

One query I do have regarding systems though is - anyone finding in 2012 that although systems are supposed to be easy to create, when you actually try and amend the system, after piping/ducting up, to add mechanical equipment or remove elements then it either doesn't do it or it then crashes Revit? Instead you have to delete the system and recreate a new one in the old way?

[Anonymous]

Yep - but surely that's the point of a system. The DCW system you are describing is a building system not an individual system. Presumably the DCW starts from either an incoming mains water meter or from a storage tank and then is distributed around the building serving many different areas. Therefore I see systems as building based not zone based.

If you needed to note what zone things are in then schedules should solve that or add a specific parameter to the relevant categories to manually state what areas things are in.

One query I do have regarding systems though is - anyone finding in 2012 that although systems are supposed to be easy to create, when you actually try and amend the system, after piping/ducting up, to add mechanical equipment or remove elements then it either doesn't do it or it then crashes Revit? Instead you have to delete the system and recreate a new one in the old way?

[dennis]

Thanks Julian for your thoughts.  It would seem that you are right in that eventually in the modeling process your DCW lines will all be on the same system.  It wasn't this way in earlier releases (at least not that I noticed) so I wanted to make sure I wasn't doing something wrong.  I do use the systemization process for automatic pipe layouts (except for sanitary which never gives me a layout I can use), so that is one reason why I want to control systems a bit more than what I seem to be able to do.  But I could see where once I am finished with a layout, that it may not really matter that it stay put on the system used to do the auto-layout.

I too have found that tweeking the components in a system won't work often times.  I had a system worked up DCW01, If I decided to start another system DCW02 and pull one component from the existing DCW01 system, I could have a couple different things happen: 1) simply would not pull the one component out of the DCW01 system,  -or- 2) pulled everything in the DCW01 system over with the one component selected.  But based on what we were talking about origionally with this post, maybe now #2 is what is suppose to happen?

Additionally, I have found that some 'out there' are now creating the systems as duplicates of the mains: Cold Water Supply is duplicated to CWS01, CWS02, etc and then the fixtures/pipes are assigned to these duplicated systems rather than creating systems via the select objects method.  I am wondering if now with 2012 is that "the way" to do it now or just an option?  In some ways I do like how each system then gets listed separately in the SystemBrowser rather than all be a subset of the ColdWaterSystem.

[dennis]

Thanks Julian for your thoughts.  It would seem that you are right in that eventually in the modeling process your DCW lines will all be on the same system.  It wasn't this way in earlier releases (at least not that I noticed) so I wanted to make sure I wasn't doing something wrong.  I do use the systemization process for automatic pipe layouts (except for sanitary which never gives me a layout I can use), so that is one reason why I want to control systems a bit more than what I seem to be able to do.  But I could see where once I am finished with a layout, that it may not really matter that it stay put on the system used to do the auto-layout.

I too have found that tweeking the components in a system won't work often times.  I had a system worked up DCW01, If I decided to start another system DCW02 and pull one component from the existing DCW01 system, I could have a couple different things happen: 1) simply would not pull the one component out of the DCW01 system,  -or- 2) pulled everything in the DCW01 system over with the one component selected.  But based on what we were talking about origionally with this post, maybe now #2 is what is suppose to happen?

Additionally, I have found that some 'out there' are now creating the systems as duplicates of the mains: Cold Water Supply is duplicated to CWS01, CWS02, etc and then the fixtures/pipes are assigned to these duplicated systems rather than creating systems via the select objects method.  I am wondering if now with 2012 is that "the way" to do it now or just an option?  In some ways I do like how each system then gets listed separately in the SystemBrowser rather than all be a subset of the ColdWaterSystem.

[Anonymous · Accepted solution]

hmmm - I hadn't really noticed that before but you're right. Up to 2011, you could create 2 systems on one set of pipes but the flows didn't always come through correctly. 2012 seems to do some weird stuff with systems aside from pulling stuff onto a single system.

I remember when first starting out a couple of examples which wrecked systems early on such as by-pass loops on Mech water systems, flow and return on DHW or smoke extract ducts connected to return air ducts where fittings/accessories had to be doctored to allow 2 systems to one item. Slightly different to your example I know but still one of the things that caues a headache. I suppose you could doctor a valve to allow you split the main building system into smaller zonal systems.

I guess that the theory behind Revit systems is similar to the way you design and size distribution systems with terminal fittings fed from a central source, although unfortunately not all real-life scenarios are as straight forward as Revit systems. Out of interest - why do you want to split your plumbing system up in the way you are describing?

I have heard of something similar to the "out-there'ers". One of our offices does something similar in creating loads of different system types and uses the graphical over-rides to colour the elements, etc instead of filters. I have recently looked at using this to help split duct system types up a bit more and some piping systems up a bit more and treat it in a similar fashion to worksets - less is better. Otherwise you can start getting into a mess with multiple duct/pipe system types-filters-duct/pipe types-phasing-design options-etc. all affect visibility, etc and sometimes clashing or over-riding in ways you don't want. I guess that like anything in Revit, there are good ways and better ways of doing things

Currently I have some return air duct work arriving at an AHU from 2 different directions through a tee and connecting via a tap/shoe. Rather than working as expected, the system inspector reckons that the flow direction is to the smallest grille with the AHU pushing the return air (huh???) to the grille so parts of the ductwork have positive flows and some have negative flows. Personally I think that the principle of the new system method is great for newcomers learning Revit that don't understand how simple it is to create system connectors but I find that Revit has become too temperamental with the various user controlled options for assigning elements to system types without having to create a system properly first.

[Anonymous · Accepted solution]

hmmm - I hadn't really noticed that before but you're right. Up to 2011, you could create 2 systems on one set of pipes but the flows didn't always come through correctly. 2012 seems to do some weird stuff with systems aside from pulling stuff onto a single system.

I remember when first starting out a couple of examples which wrecked systems early on such as by-pass loops on Mech water systems, flow and return on DHW or smoke extract ducts connected to return air ducts where fittings/accessories had to be doctored to allow 2 systems to one item. Slightly different to your example I know but still one of the things that caues a headache. I suppose you could doctor a valve to allow you split the main building system into smaller zonal systems.

I guess that the theory behind Revit systems is similar to the way you design and size distribution systems with terminal fittings fed from a central source, although unfortunately not all real-life scenarios are as straight forward as Revit systems. Out of interest - why do you want to split your plumbing system up in the way you are describing?

I have heard of something similar to the "out-there'ers". One of our offices does something similar in creating loads of different system types and uses the graphical over-rides to colour the elements, etc instead of filters. I have recently looked at using this to help split duct system types up a bit more and some piping systems up a bit more and treat it in a similar fashion to worksets - less is better. Otherwise you can start getting into a mess with multiple duct/pipe system types-filters-duct/pipe types-phasing-design options-etc. all affect visibility, etc and sometimes clashing or over-riding in ways you don't want. I guess that like anything in Revit, there are good ways and better ways of doing things

Currently I have some return air duct work arriving at an AHU from 2 different directions through a tee and connecting via a tap/shoe. Rather than working as expected, the system inspector reckons that the flow direction is to the smallest grille with the AHU pushing the return air (huh???) to the grille so parts of the ductwork have positive flows and some have negative flows. Personally I think that the principle of the new system method is great for newcomers learning Revit that don't understand how simple it is to create system connectors but I find that Revit has become too temperamental with the various user controlled options for assigning elements to system types without having to create a system properly first.

[dennis]

Main reason "why" I break the systems up the way I do is for the auto-layout function.  I get more useful layout options with fewer fixtures and grouping fixtures that I want to "act together" for the layout.  Example:  I systemize the cold lines for sinks in a restroom separate from the toilets to get better control over what layouts generated -and- would never systemized the 2nd floor restroom fixtures with the 1st floor for the same reason, the layouts generated would never be used.

[dennis]

Main reason "why" I break the systems up the way I do is for the auto-layout function.  I get more useful layout options with fewer fixtures and grouping fixtures that I want to "act together" for the layout.  Example:  I systemize the cold lines for sinks in a restroom separate from the toilets to get better control over what layouts generated -and- would never systemized the 2nd floor restroom fixtures with the 1st floor for the same reason, the layouts generated would never be used.

[dennis]

Another discovery thru experimentation:  If I duplicate the ColdWaterSystem in the Family list, first DCW1 then DCW2, when I assign fixtures to those systems, then plumb them together, they retain their respective systems -but- if I create system names via the selection method, keeping them all under DomesticColdWater, then when I plumb the two together, they adopt just one of the system names.  Good to know and now 'which way' is the prefered way?  I suppose this may end up being user preference for what they want to show later on.

[dennis]

Another discovery thru experimentation:  If I duplicate the ColdWaterSystem in the Family list, first DCW1 then DCW2, when I assign fixtures to those systems, then plumb them together, they retain their respective systems -but- if I create system names via the selection method, keeping them all under DomesticColdWater, then when I plumb the two together, they adopt just one of the system names.  Good to know and now 'which way' is the prefered way?  I suppose this may end up being user preference for what they want to show later on.

[Anonymous]

A couple of thoughts (probably rheotorical) on that, assuming I understood your comments correctly:-

• Is it working because of creating a different system type for each system name you require even though they are the same system type (i.e DCW) and as a caution feature, Revit continues to treat them separately due to potential differences in the type parameters of each system?
• If this method is the "preferred way" by Autodesk or users generally, then to achieve what you were talking about for the auto-routing, the project would require a different system type for each area you wanted to auto-route which would lead to hundreds for system types. That seems a strange way to deal with systems.

A little further explanation from Autodesk would be rather helpful as this change to the system creation tool appears to have created more issues than it solved

[Anonymous]

A couple of thoughts (probably rheotorical) on that, assuming I understood your comments correctly:-

• Is it working because of creating a different system type for each system name you require even though they are the same system type (i.e DCW) and as a caution feature, Revit continues to treat them separately due to potential differences in the type parameters of each system?
• If this method is the "preferred way" by Autodesk or users generally, then to achieve what you were talking about for the auto-routing, the project would require a different system type for each area you wanted to auto-route which would lead to hundreds for system types. That seems a strange way to deal with systems.

A little further explanation from Autodesk would be rather helpful as this change to the system creation tool appears to have created more issues than it solved

[Martin__Schmid]

In brief- the goal of System Types was to provide a mechanism by which to pre-define systems and their associated characteristics, and to allow display control to be assigned to logical 'groups' of things.  for example, you can now define Types for the following

1. Chilled Water Return

2. Chilled Water Supply

3. Heating Hot Water Supply

4. Heating Hot Water Return

5. Sanitary Black Water

6. Sanitary Grey Water

7. Circulating Hot Water

For each system type, you can now specify properties such as:

1. Calculations (on/off/flow)

2.  Fluid Type

3. Fluid Temperature

4. Graphic Overrides

5. System Abbreviation

In general, prior to System Types there were a few different ways users were solving the end goal of 'grouping' elements to control their visibilty.  I.e., in 'View A' I want to see this group of components this color, but I want to hide these other things, and in 'View B' I want to see this other group of things, and hide the rest.  Futher, I want to be able to easily tag an abbreviation on the pipes/duct.  Worksets were one option, Pipe Types (and duplicated fitting types) were another, a project param helped solve the problem of tagging, but was difficult to maintain on all the pipes.  Additionally, there was a frequent desire to route a pipe for a particular system without it being connected to other elements... for example, to coordinate a chase or a ceiling cavity with the pipie mains indicating their services.

When you interconnect pipes from different systems, but are the same system type, as you have found, the systems will merge... there is a logic here, for example, if you trim two pipes of different systems, I beleive the first selected pipe controls which system 'rules'.  If you connect one pipe into another, the pipe you are editing will 'rule'.

Hopefully that provides a little more insight into the whys.  If you have scenarios where you are getting unexpected results, please provide the scenarios/details.

[Martin__Schmid]

In brief- the goal of System Types was to provide a mechanism by which to pre-define systems and their associated characteristics, and to allow display control to be assigned to logical 'groups' of things.  for example, you can now define Types for the following

1. Chilled Water Return

2. Chilled Water Supply

3. Heating Hot Water Supply

4. Heating Hot Water Return

5. Sanitary Black Water

6. Sanitary Grey Water

7. Circulating Hot Water

For each system type, you can now specify properties such as:

1. Calculations (on/off/flow)

2.  Fluid Type

3. Fluid Temperature

4. Graphic Overrides

5. System Abbreviation

In general, prior to System Types there were a few different ways users were solving the end goal of 'grouping' elements to control their visibilty.  I.e., in 'View A' I want to see this group of components this color, but I want to hide these other things, and in 'View B' I want to see this other group of things, and hide the rest.  Futher, I want to be able to easily tag an abbreviation on the pipes/duct.  Worksets were one option, Pipe Types (and duplicated fitting types) were another, a project param helped solve the problem of tagging, but was difficult to maintain on all the pipes.  Additionally, there was a frequent desire to route a pipe for a particular system without it being connected to other elements... for example, to coordinate a chase or a ceiling cavity with the pipie mains indicating their services.

When you interconnect pipes from different systems, but are the same system type, as you have found, the systems will merge... there is a logic here, for example, if you trim two pipes of different systems, I beleive the first selected pipe controls which system 'rules'.  If you connect one pipe into another, the pipe you are editing will 'rule'.

Hopefully that provides a little more insight into the whys.  If you have scenarios where you are getting unexpected results, please provide the scenarios/details.

[Anonymous]

Thanks for the explanation Martin.

As I mentioned - the new systems are great for several reasons but also seem to bog work down when they over-ride each other. It seems you have to be more regimented in your procedures for creating systems before joining elements and equipment. However if you have an AHU with a cooling coil and also a heat recovery coil connected to a Run around coil, despite being two separate systems, Revit tries to pull the run around coil into the chilled water system so you have to delete systems and start again It seems that Revit is trying to be helpful by running rules in th backgorund but isn't quite knowledgeable enough to understand the designer's requirement. (If that makes sense). Not meaning it should read my mind or be a one button solution but at the same time it should be compiling the design I am asking it to.The elements in the system browser can appear in a different order for flow and return systems for the same equipment. Is there anywhere that explains the hierarchy and symbols of the system browser for each type of system? Ducted systems with AHU are fairly straight forward but when you have Hydronic supply and return systems with the same pieces of equipment that display in a different hierarchy in the system browser - that doesn't make sense.

The new system type certainly adds more flexibility. One issue I notices though is that any graphical override you apply through tthe system type will override insulation graphics when you apply insulation to pipes - especially materials.

It may be me but I noticed that when you have a piece of equipment with two connectors of the same type being applied to a system, the option of right clicking on the second connector and adding to the first connector's system is no longer available. The second connector belongs to another numbered system matching the connectors type. This happens especially if the equipment is piped up before you have created a system (rightly or wrongly) but I don't recall that happening in previous versions.

With regards to systems - are Autodesk planning to provide further real-life examples of system creation aside from the ones you have demonstarted previously. For example:- A smoke extract system with a grille, inline fan or inline twin fans and an exhaust louvre. Which part is mechanical equipment and how the fans would fit in the system (aside from designating the System flow configuration), the expected extents of each part of the system as you can't always add all the fan conenctors, etc.

Also what about more complicated systems where you have bypass connections which mix flow and return systems (or more complex still but I can't think of any off the top of my head!) but may have an impact on the flow/velocity/pipe size. It could be resolved by creating a specific family or it could be resolved by modifying an exsisting valve (for example) or some other way. Whichever way it is resolved would be great to document so as to help newcomers and the take up of the software.

I appreciate there are a myriad of system configurations but perhaps Autodesk could add to their Wiki some of the more common ones and how Revit's principles are intended to cope with them. I'm sure Autodesk have had loads of questions/complaints that could be compiled to give more ideas to users - especially now there seems to be a rapid increase in RME use.

[Anonymous]

Thanks for the explanation Martin.

As I mentioned - the new systems are great for several reasons but also seem to bog work down when they over-ride each other. It seems you have to be more regimented in your procedures for creating systems before joining elements and equipment. However if you have an AHU with a cooling coil and also a heat recovery coil connected to a Run around coil, despite being two separate systems, Revit tries to pull the run around coil into the chilled water system so you have to delete systems and start again It seems that Revit is trying to be helpful by running rules in th backgorund but isn't quite knowledgeable enough to understand the designer's requirement. (If that makes sense). Not meaning it should read my mind or be a one button solution but at the same time it should be compiling the design I am asking it to.The elements in the system browser can appear in a different order for flow and return systems for the same equipment. Is there anywhere that explains the hierarchy and symbols of the system browser for each type of system? Ducted systems with AHU are fairly straight forward but when you have Hydronic supply and return systems with the same pieces of equipment that display in a different hierarchy in the system browser - that doesn't make sense.

The new system type certainly adds more flexibility. One issue I notices though is that any graphical override you apply through tthe system type will override insulation graphics when you apply insulation to pipes - especially materials.

It may be me but I noticed that when you have a piece of equipment with two connectors of the same type being applied to a system, the option of right clicking on the second connector and adding to the first connector's system is no longer available. The second connector belongs to another numbered system matching the connectors type. This happens especially if the equipment is piped up before you have created a system (rightly or wrongly) but I don't recall that happening in previous versions.

With regards to systems - are Autodesk planning to provide further real-life examples of system creation aside from the ones you have demonstarted previously. For example:- A smoke extract system with a grille, inline fan or inline twin fans and an exhaust louvre. Which part is mechanical equipment and how the fans would fit in the system (aside from designating the System flow configuration), the expected extents of each part of the system as you can't always add all the fan conenctors, etc.

Also what about more complicated systems where you have bypass connections which mix flow and return systems (or more complex still but I can't think of any off the top of my head!) but may have an impact on the flow/velocity/pipe size. It could be resolved by creating a specific family or it could be resolved by modifying an exsisting valve (for example) or some other way. Whichever way it is resolved would be great to document so as to help newcomers and the take up of the software.

I appreciate there are a myriad of system configurations but perhaps Autodesk could add to their Wiki some of the more common ones and how Revit's principles are intended to cope with them. I'm sure Autodesk have had loads of questions/complaints that could be compiled to give more ideas to users - especially now there seems to be a rapid increase in RME use.

[Martin__Schmid]

Great questions... 

:However if you have an AHU with a cooling coil and also a heat recovery coil connected to a Run around coil, despite being two separate systems, Revit tries to pull the run around coil into the chilled water system so you have to delete systems and start again It seems that Revit is trying to be helpful by running rules in th backgorund but isn't quite knowledgeable enough to understand the designer's requirement. "

Can you provide a basic schematic of this scenario?  I could make several guesses as to how you might pipe this up... if you could provide an image showing the coils (cooling, heat recover, run around) and the piping configuration, I may be able to further explain what revit is doing.

[Martin__Schmid]

Great questions... 

:However if you have an AHU with a cooling coil and also a heat recovery coil connected to a Run around coil, despite being two separate systems, Revit tries to pull the run around coil into the chilled water system so you have to delete systems and start again It seems that Revit is trying to be helpful by running rules in th backgorund but isn't quite knowledgeable enough to understand the designer's requirement. "

Can you provide a basic schematic of this scenario?  I could make several guesses as to how you might pipe this up... if you could provide an image showing the coils (cooling, heat recover, run around) and the piping configuration, I may be able to further explain what revit is doing.

[Anonymous]

Hi Martin

Please find attached a screenshot of a typical AHU incorporating 2 CHW systems. I have also shown the system browser which shows the difference in system hierarchy Revit has applied to the two CHW RAC piping systems. As the connector configurations for data flow are identical (same preset and calculated options) I would expect the same hierarchy. Please note how the RAC systems for AHUs 7 & 10 differ even though the system principles are the same

Unfortunately I am not able to show you issue of Revit combining the two systems as I have resolved that in this project. However what happened was when I added the AHU on the left to the CHWF & CHWR systems, Revit automatically added the Run Around Coil pipework to the CHW system. When editing the CHW RAC Flow & Return systems, Revit refused to allow me to add the AHU to the RAC systems. So I had to disconnect the pipework and delete the RAC systems then re-build the system. To me this defeats part of the benefit of systems as due to this new way of allowing pipes/ducts to be any system without connectors,you have to either build systems in by the book or go about deleting and re-building which takes extra time we don't usually have.

Pre-2012, I could pipe or duct layouts up without having to worry about creating systems first and then add systems later without the above problems. It may not have been the intended way but at least it was flexible. Now the additional flexibility can actually be quite restrictive.

Also can you explain the symbols in the system browser and the expected/intended heirarchy in a system. At present Revit seems to give me different version (as mentioned previously). Some of the symbols do give a good idea of what they mean but as I couldn't find any documentation on the wiki/help site it would be good to hear from one of the main people about this

[Anonymous]

Hi Martin

Please find attached a screenshot of a typical AHU incorporating 2 CHW systems. I have also shown the system browser which shows the difference in system hierarchy Revit has applied to the two CHW RAC piping systems. As the connector configurations for data flow are identical (same preset and calculated options) I would expect the same hierarchy. Please note how the RAC systems for AHUs 7 & 10 differ even though the system principles are the same

Unfortunately I am not able to show you issue of Revit combining the two systems as I have resolved that in this project. However what happened was when I added the AHU on the left to the CHWF & CHWR systems, Revit automatically added the Run Around Coil pipework to the CHW system. When editing the CHW RAC Flow & Return systems, Revit refused to allow me to add the AHU to the RAC systems. So I had to disconnect the pipework and delete the RAC systems then re-build the system. To me this defeats part of the benefit of systems as due to this new way of allowing pipes/ducts to be any system without connectors,you have to either build systems in by the book or go about deleting and re-building which takes extra time we don't usually have.

Pre-2012, I could pipe or duct layouts up without having to worry about creating systems first and then add systems later without the above problems. It may not have been the intended way but at least it was flexible. Now the additional flexibility can actually be quite restrictive.

Also can you explain the symbols in the system browser and the expected/intended heirarchy in a system. At present Revit seems to give me different version (as mentioned previously). Some of the symbols do give a good idea of what they mean but as I couldn't find any documentation on the wiki/help site it would be good to hear from one of the main people about this

[Martin__Schmid]

Based on the expanded nodes in the image, what I see are the you have two Pipe System Types.

1. CHW RAC Flow

2. CHW RAC Return

For these system types, you have some systems...some that have 'parent' equipment for the system, and some that don't:

1. CHW RAC Flow

  a. With Parent (Folder Icon)

    i. 5.06-AHU-7

  b. Without Parent

    i. RAC 10 CHW FLO...

    ii. RAC 8 CHW FLOW

2. CHW RAC Return

  a. With Parent (Folder Icon)
    i. 5.06-AHU-10
    ii. 5.06-AHU-7
    iii. 5.06-AHU-8

  b. Without Parent

    i. (none)

Perhaps this 'parent' vs. 'no parent' is what you are referring to by 'difference in system heirarchy'?  

I suspect that 'RAC 10 CHW FLO...' and 'RAC 8 CHW FLOW' have no equipment assigned to the systems (you could perhaps create a Pipe System Schedule to see if, in fact, the 'System Equipment' field is empty.  If you were to assign an equipment for these systems, your heirarchy should then become consistent with having the 'Folder' icon node.

It would be helpful if you could provide a model in a particular state where it isn't allowing you to do something that you expect you should be able to do.  We could then further investigate and evaluate what is going on.

[Martin__Schmid]

Based on the expanded nodes in the image, what I see are the you have two Pipe System Types.

1. CHW RAC Flow

2. CHW RAC Return

For these system types, you have some systems...some that have 'parent' equipment for the system, and some that don't:

1. CHW RAC Flow

  a. With Parent (Folder Icon)

    i. 5.06-AHU-7

  b. Without Parent

    i. RAC 10 CHW FLO...

    ii. RAC 8 CHW FLOW

2. CHW RAC Return

  a. With Parent (Folder Icon)
    i. 5.06-AHU-10
    ii. 5.06-AHU-7
    iii. 5.06-AHU-8

  b. Without Parent

    i. (none)

Perhaps this 'parent' vs. 'no parent' is what you are referring to by 'difference in system heirarchy'?  

I suspect that 'RAC 10 CHW FLO...' and 'RAC 8 CHW FLOW' have no equipment assigned to the systems (you could perhaps create a Pipe System Schedule to see if, in fact, the 'System Equipment' field is empty.  If you were to assign an equipment for these systems, your heirarchy should then become consistent with having the 'Folder' icon node.

It would be helpful if you could provide a model in a particular state where it isn't allowing you to do something that you expect you should be able to do.  We could then further investigate and evaluate what is going on.

[Anonymous]

Thanks for the reply Martin.

The explanation makes sense and is kind of what I expected you would say but as I couldn't find it documented I wasn't sure. I did go and check the systems and revised them based on your comments and that sorted it out - thought I had already done this but obviously not.

One issue I did have though whilst trying to finalise the systems is I made a global connector as Mech Equipment for supply and return with calculated values. However, try as I might, it Revit would not allow this global connector to be added to the system to be the head of the heirarchy and remained in the piping unassigned area of the system browser. When I change it to a specific service (Hydronic Supply/Return) the system works fine. Why is that?

I have seen people create global end caps so as to minimise the number of families in a project but again it didn't seem to work.

[Anonymous]

Thanks for the reply Martin.

The explanation makes sense and is kind of what I expected you would say but as I couldn't find it documented I wasn't sure. I did go and check the systems and revised them based on your comments and that sorted it out - thought I had already done this but obviously not.

One issue I did have though whilst trying to finalise the systems is I made a global connector as Mech Equipment for supply and return with calculated values. However, try as I might, it Revit would not allow this global connector to be added to the system to be the head of the heirarchy and remained in the piping unassigned area of the system browser. When I change it to a specific service (Hydronic Supply/Return) the system works fine. Why is that?

I have seen people create global end caps so as to minimise the number of families in a project but again it didn't seem to work.

[Martin__Schmid]

To be the 'equipment for the system', a connector has to be configured in a certain way.

For a 'Hydronic Return' classification system, the equipment must be a Hydronic Return connector with the ability for the flow to be In (i.e., Bidirectional is OK, but Out is not).
For a 'Hydronic Supply' classification system, the equipment must be a Hydronic Supply connector with flow not Out.

[Martin__Schmid]

To be the 'equipment for the system', a connector has to be configured in a certain way.

For a 'Hydronic Return' classification system, the equipment must be a Hydronic Return connector with the ability for the flow to be In (i.e., Bidirectional is OK, but Out is not).
For a 'Hydronic Supply' classification system, the equipment must be a Hydronic Supply connector with flow not Out.

[Anonymous]

Thanks Martin - I'm good with the general principles of connectors in systems (thanks to your AU documents) but interested in some of the finer points of systems/connectors.

So what is the purpose of Global - just for pumps/valves/etc. that sit within the system and not at the head of the system? Why can't global connectors sit at the head of the system - even if the other parameters are set in the correct fashion?

[Anonymous]

Thanks Martin - I'm good with the general principles of connectors in systems (thanks to your AU documents) but interested in some of the finer points of systems/connectors.

So what is the purpose of Global - just for pumps/valves/etc. that sit within the system and not at the head of the system? Why can't global connectors sit at the head of the system - even if the other parameters are set in the correct fashion?

[Martin__Schmid]

Gloabl connectors 'inherit' the system from other components whereas in Revit (and in real life) a piece of equipment generally defines what type of system it is.  I.e., you can have a valve or pump that is used in a variety of system types... however, the supply out connector of a chiller will always be a supply out connector... it couldn't be 'global' and inherit some other setting.  Could Revit try to guess what such a connector should be?  Perhaps, but generally, where it is possible and conveient to be explicit, it probably takes less logic and computation to do so!

[Martin__Schmid]

Gloabl connectors 'inherit' the system from other components whereas in Revit (and in real life) a piece of equipment generally defines what type of system it is.  I.e., you can have a valve or pump that is used in a variety of system types... however, the supply out connector of a chiller will always be a supply out connector... it couldn't be 'global' and inherit some other setting.  Could Revit try to guess what such a connector should be?  Perhaps, but generally, where it is possible and conveient to be explicit, it probably takes less logic and computation to do so!

[Anonymous]

Yes - that makes sense and is logical. I'm not talking so much about adding global connectors to things like chillers (as an example) which will clearly have specific connector uses but more like a piping distribution systems on floors which is in different model to the Primary distribution system. Here the end terminals (preset configuration) dictate the system type so I would have thought that when you added a global connector as the calculated head of system equipment, the global connector would pick up that it is part of a Hydronic supply system, for example.

Also with the introduction of the new pipe/duct systems in 2012, I would have thought that these would have had some influence on the global connectors so Revit doesn't have to guess. Just thinking that we could create a single family to do the job of 10 or so families but if it's not possible, that's fine.

Rather than create a massive post would it be easier to discuss this and previous questions further by phone?

[Anonymous]

Yes - that makes sense and is logical. I'm not talking so much about adding global connectors to things like chillers (as an example) which will clearly have specific connector uses but more like a piping distribution systems on floors which is in different model to the Primary distribution system. Here the end terminals (preset configuration) dictate the system type so I would have thought that when you added a global connector as the calculated head of system equipment, the global connector would pick up that it is part of a Hydronic supply system, for example.

Also with the introduction of the new pipe/duct systems in 2012, I would have thought that these would have had some influence on the global connectors so Revit doesn't have to guess. Just thinking that we could create a single family to do the job of 10 or so families but if it's not possible, that's fine.

Rather than create a massive post would it be easier to discuss this and previous questions further by phone?