Sanitary drainage must slope; supply piping does not.
This was one of the main things that affected how I modeled the plumbing system. I started with the sanitary stack and branch pipes, then added the hot and cold water lines around them. Since the sanitary pipes need a slope of 1/4 inch per foot, the distance between the bathroom and the shaft became important. In my model, the bathroom in unit 501 is right next to Mech Shaft-1, so the branch only needs to run about 8 feet. The supply lines were easier to work with because they are pressurized and do not need to follow the same slope. If I could redesign the layout, I would probably place all the bathrooms along the corridor walls and provide separate shafts for the north and south units. This would keep the sanitary branches shorter and avoid having the south units depend on one stack
Building science: efficient lighting and controls.
You modelled a representative slice rather than the whole building.
I think working on a representative floor helped me understand the plumbing system better without having to model every pipe in the building. By focusing on one bathroom, one stack, and one branch, I could see how the required slope affects the distance between the bathroom and the shaft. I also realized that using a typical floor does not always mean the same layout will work everywhere. For example, Level 8 has a different unit arrangement, so I had to check whether the bathrooms were still aligned with the stack. At the same time, modeling only one part of the building can hide some problems. When I first added lighting to only the north half of Level 5, the electrical panel load looked fine because the other half of the circuits was missing. A complete model would also help identify the total load on the sanitary stack and any additional conflicts between plumbing branches and structural beams.
Panels, risers and mechanical rooms all compete for the same square footage.
You now have five models from five notional disciplines.
I think having separate models makes it easier to understand who is responsible for each part of the design. When there is a conflict between two systems, the people responsible for those models need to review it and decide how to fix it. The coordinator can track the conflict through Model Coordination and assign it to the appropriate person instead of leaving it in the clash report. I also learned that managing the model files is just as important as modeling the systems themselves. For example, my MEP models included the linked architectural model in their published 3D views, which resulted in about 2,100 false clashes. I also had a problem with the structural model not appearing in the coordination set because its publish settings did not include a 3D view. These issues showed me why the publishing settings and model responsibilities need to be clear. Even in a small project like this, one incorrect setting can affect the coordination process for everyone.