Hiérarchie des données du modèle et héritage de données

Sommaire  Précédent  Suivant

Les modèles de DesignBuilder sont hiérarchisés :

 

Hierarchy_4

 

Une donnée par défaut est héritée du niveau supérieur de la hiérarchie. Ainsi, les données de bloc sont héritées du niveau bâtiment, les données de zone sont héritées du niveau bloc et les données de surface héritées des données de zone.

Ce système vous permet de définir des paramètres au niveau bâtiment qui peuvent devenir actives pour l'ensemble du bâtiment ou bien faire des saisies au niveau bloc pour affecter toutes ses zones et surfaces.

Par exemple si le mur extérieur est choisi comme "Mur 1" pour le bâtiment entier, il devient le mur extérieur par défaut de tous les blocs du bâtiment.

Il est possible de changer les données par défaut héritées dans n'importe lequel des blocs du bâtiment en faisant une sélection explicite (Mur 2 par exemple).

Toutes les zones du bloc dont les murs extérieurs ont été définis comme "Mur 2" auront "Mur 2" comme caractéristique par défaut pour la construction de leur murs extérieurs.

Les valeurs par défaut des constructions et ouvertures sont propagées vers le bas jusqu'au niveau surface d'ou les données seront effectivement utilisées pour les simulations.

Par exemple, c'est la construction du mur extérieur lisible au niveau de la surface qui définit la véritable construction de ce mur extérieur. La donnée de construction de mur extérieur saisie au niveau zone, bloc ou bâtiment n'a aucun rôle excepté de diffuser la donner jusqu'à la surface.

Les données du modèle héritées du niveau supérieur sont inscrites en bleu et les données spécifiques (personnalisées par saisie explicite) sont inscrites en rouge (voir ci-dessous).

 

user data_4

 

Le mécanisme de hiérarchisation des données de DesignBuilder est un moyen rapide de définir globalement les données d'un modèle de bâtiment, mais il faut prendre garde à n'entrer qu'un minimum de données pour profiter au mieux du système d'héritage.

Par exemple, si toutes les zones d'un bloc particulier abritent la même activité (bureaux par exemple), cette dernière devra être établie au niveau du bloc et non plusieurs fois au niveau des différentes zones qui composent ce bloc.

Pareillement, si tous les blocs d'un bâtiment ont la même activité, il faut établir cette activité au niveau du bâtiment et permettre ainsi à tous les blocs du bâtiment d'hériter du bâtiment.

En maintenant au minimum l'usage des "données spécifiques", il sera plus rapide de faire des modifications particulières à un stade plus avancé du projet.

A l'évidence, il est bien plus rapide de changer un petit nombre de données du modèle au niveau bâtiment ou bloc que de faire de multiples modifications aux niveaux zones ou surfaces.

Lorsque vous entrez des données de construction, vous pourriez saisir les modes de construction au niveau de chaque surface mais en pratique cette méthode est peu efficace.

Il est plus rapide et cela provoque moins d'erreur de saisir aussi haut que possible dans la hiérarchie les données, au niveau bâtiment (si les murs extérieurs du bâtiment ont tous la même construction) ou au niveau bloc si tous les murs du bloc ont la même construction (et les autres non).

La grande majorité des données au niveau "bâtiment" sont des données spécifiques, car, les bâtiments ne peuvent hériter de données du niveau "site".

Repères

En résumé les règles sont :

 

Construction et Ouvertures sont reprises du niveau surface, en conséquence toutes les données de construction et d'ouverture au niveau bâtiment, bloc et zone sont des valeurs par défaut mais seulement les données au niveau surface sont utilisées pour la définition du modèle de simulation.
Activité, Eclairage, CVC, Équipement sont repris du niveau zone, ainsi toutes les données d'Activité, d'éclairage, CVC, d'équipement du niveau bâtiment et bloc sont des valeurs par défaut. La seule exception étant les donnée de centrale de traitement d'air (CTA) pour les systèmes CVC Compact dont les paramètres sont déterminés au niveau bâtiment.

 

Une question usuelle est "Pourquoi vois-je des Constructions de toiture inclinées au niveau bâtiment dans l'onglet Construction alors que mon bâtiment n'a pas de toit incliné" ?

 

La réponse est que le choix d'une construction de toiture inclinée aux niveaux bâtiment, bloc et zone est une option à saisir par défaut dans le cas ou il pourrait y avoir des toits inclinés plus tard dans le modèle.

S'il n'y a pas de toiture inclinée dans le modèle ces données ne seront tout simplement pas utilisées.

Ouvertures personnalisées

Lorsque des ouvertures personnalisées ont été créées sur une surface, celles-ci se substituent au système de Disposition de façade du modèle pour la surface.

Ouvertures

Bien que les ouvertures (fenêtres, aérations, portes, etc) apparaissent dans la hiérarchie de DesignBuilder, il n'existe pas en version 1 de moyen de modifier les données au niveau Ouverture.

Toutes les ouvertures héritent des données de leur surface. Il est donc impossible d'avoir différent type de vitrage sur une surface unique.

Si vous cliquez sur une ouverture dans le Navigateur vous verrez en fait la surface contenant les ouvertures.

Blocs Composants

Les blocs composants héritent leurs données du niveau bâtiment.

 

Partition data inheritance

Il existe 2 types de surface nommée Cloison :

Cloisons séparant des zones à l'intérieur d'un bloc. Les données de ces cloisons héritent du niveau Bloc. En effet, elles ne peuvent héritées du niveau zone car il y a 2 zones adjacentes à la cloison et il n'est pas possible d'hériter d'une zone plutôt que d'une autre.
Cloisons interblocs qui séparent des zones dans 2 blocs différents. Elles ont 2 blocs parents et il n'est donc pas possible que les données héritent du niveau Bloc puisqu'il y a deux parents potentiels à la cloison.