Bauklimatik-Dresden SchulungenDownloadsKlimadatenForumNewsletterWebinareImpressumDatenschutzerklärung english
Validierung nach DIN EN ISO 13971
StartseiteDokumentation & HilfeScreenshotsBestellung & LizenzenKontakt
    START»NANDRAD»VALIDIERUNG NACH DIN EN ISO 13971
Validierungsfall 1

Der Validierungsfall 1 testet die Validität der Abbildung opaker Bauelemente. Zugrundgelegt wird ein einzelner Raum mit den Innenmaßen 1mx1mx1m, der ringsum von Außenwänden mit gleichem Konstruktionsaufbau und gleichen Randbedingungen umgeben ist. Die Wandmaterialeigenschaften sind hierbei der Tabelle 1 zu entnehmen. Die Wärmeübertragung infolge langwelliger und kurzwelliger Strahlung, sowie die Wärmespeicherfähigkeit des Raumes werden zunächst ignoriert. Angenommen wird ein konstanter innerer Konvektionswärmeübergangskoeffizient jedes Wandelements, einschließlich Decke und Fußboden von 2,5W/m2K. Der äußere Konvektionswärmeübergangskoeffizient jedes Wandelements,einschließlich Decke und Fußboden beträgt 8W/m2K.

Prüfnummer  Dicke  Wärmeleitfähigkeit  Dichte   Wärmekapazität
             [m]         [W/mK]        [kg/m3]    [kJ/kgK]
    1       0.20          1.2           2000        1.0
    2       0.10          0.04           50         1.0
    3       0.20          1.2           2000        1.0
            0.10          0.04           50         1.0
            0.005         0.14           800        1.5
    4       0.005         0.14           800        1.5
            0.10          0.04           50         1.0
            0.20          1.2           2000        1.0
			
Tabelle 1: Aufbau der Wandelementelemente von innen (raumzugewandt) nach außen:
	

Zu Beginn der Simulation befinden sich Raum und Wandelemente im thermischen Gleichgewicht bei einer einheitlichen Temperatur von 20°C. Die Außentemperatur wird für ist zu Simulationsbeginn ebenmfalls bei 20°C, steigt innerhalb einer Stunde linear auf 30°C und bleibt dann konstant, vergleiche Abbildung 1.


Abbildung 1: Variation der Außenlufttemperatur für Testfall 1

(Auf das Diagram zum Vergrößern klicken)

Die Innenlufttemperaturen sind im Zeitverlaufbis 5 Tagen zu bestimmen, wobei eine Abweichung von maximal 0,5K als zulässig erachtet wird.

Modellierung in NANDRAD

Im Installationsordner sind die Validierungsfälle 1 und 2 unter resources/examples/DIN_EN_13791 als vorgefertigte Projektdateien Case1a.nandrad, Case1b.nandrad, ... Case2d.nandrad abgelegt.

Aufbau der NANDRAD-Datenstruktur

In NANDRAD wird zwischen verschiedenen Beschreibungsebenen unterschieden:

  • NANDRAD Projektdatei: Diese beschreibt das Gebäude.
  • Kontruktionsdatenbank: Diese enthält Beschreibungen für alle Wandschichtkonstruktionen im Gebäude.
  • Materialdatenbank: Diese enthält Beschreibungen thermischer Eigenschaften aller Wandmaterialien.
  • Klimadatenbank: Diese enthält Dateien für Außenklimabedingungen.

Im konkreten Fall sind die Projektdateien in Case1a.nandrad - Case2d.nandrad abgelegt. Die Konstruktionsdatenbank befindet sich im Unterordner constructions, die Materialdatenbank in materials und die Klimadaten in climate.

Wandkonstruktionen

Die Wände für die Validierungsfälle wurden als nutzerdefinierte in NANDRAD umgesetzt. Hierbei wird die Wandkonstruktion als eindimensionaler Schichtverbund über die Wanddicke gedeutet und durch drei Merkmale beschrieben: das Wandmaterial (referenziert über als eigene Textdatei in Materials), die Schichtdicke (Discretization) und die Zuweisung des Wandmaterials zu den entsprechenden Wandschichten (Assignments).

Der entsprechende Ausschnitt aus der Konstruktionsdatei für Fall 1 Case1a_1001.d6p ist im Folgenden aufgelistet.

    
<Materials>
  <MaterialReference name="Case 1 Mat 1 (lambda=1.2)">
	${Material Database}/Case1_Mat1_10001.m6
  </MaterialReference>
</Materials>
<Discretization geometryType="2D">
  <XSteps unit="m">0.2</XSteps>
</Discretization>
<Assignments>
  <Assignment type="Material" location="Element">
    <Reference>Case 1 Mat 1 (lambda=1.2)</Reference>
    <Range>0 0 0 0</Range>
  </Assignment>
</Assignments>
    
	

Die Konstruktion im Prüffall 1 enthält nur eine Wandschicht der Dicke von 20 cm, erkennbar an den Schichtdicken in XSteps. Die Zuweisung des Materials Case 1 Mat 1 (lambda=1.2) auf die entsprechende Materialschicht erfolgt durch das Assignment vom Typ “Material”. Als Referenz dient der vorher festgelegte eindeutige Materialname und eine Bereichsangabe in Range. Dabei bezeichnet Range die Position der Materialschicht im Schichtverbund von links unten nach rechts oben mit dem Index 0 beginnend.

Referenzierung von Wandkonstruktionen und Außenklima in der Projektdatei

Die Konstruktion wird innerhalb der Projektdatei für den Fall 1, Case1a.nandrad eingebunden. Dafür vorgehen ist der Abschnitt Database, konkret der Unterabschnitt ConstructionTypeReferences. Eine Konstruktionsdatei wird referenziert über ihren Dateipfad. Dabei ist die Verwendung von Platzhalterpfaden zulässig, wie hier der Alias {Construction Database}. Voraussetzung ist, dass solche Platzhalter als absolute oder relative Pfade zur Projektdatei im Abschnitt DirectoryPlaceholders definiert sind.

	
<DirectoryPlaceholders>
  ...
  <Placeholder name="Construction Database">
    ${Project Directory}/constructions
  </Placeholder>
  ...
</DirectoryPlaceholders>
...
<Database>
  <ConstructionTypes>
    <ConstructionTypeReference displayName="Case 1a">
	  ${Construction Database}/Case1a_1001.d6p
    </ConstructionTypeReference>
  </ConstructionTypes>
</Database>
    
	

Des Weiteren wurde ein neuer Klimadatensatz erzeugt, der den gewünschten Außentemperaturverlauf ohne Berücksichtigung kurzwelliger Strahlungsanteile nachbildet. Dieser ist in der Klimadatenbank als Binärdatei DIN_EN_ISO_13791_Fall01.c6b abgelegt. Der Unterordner wird analog zur Konstruktionsdatenbank als Platzhalterpfad {Climate Database} im Abschnitt DirectoryPlaceholders adressiert. Der KLimadatensatz ist im Binärformat abgelegt und kann mit dem CCM Editor gelesen und bearbeitet werden.

Im Abschnitt Location der Projektdatei erfolgt die Parametrisierung des Außenklimas und damit auch die Referenzierung der Klimadatei im Tag ClimateReference.

	
<DirectoryPlaceholders>
  ...
  <Placeholder name="Climate Database">
	${Project Directory}/climate
  </Placeholder>
  ...
</DirectoryPlaceholders>
...
<Location>
  ...
  <ClimateReference displayName="DIN EN 13791 Case 1">
    ${Climate Database}/DIN_EN_ISO_13791_Fall01.c6b
  </ClimateReference>
</Location>
    
	

Beschreibung der Gebäudegeometrie

Als Mehrzonenmodell deutet NANDRAD die Gebäudegeometrie als Netzwerk benachbarter Räume, Raumgruppen und Wände. Die Räume/ Raumgruppen werden hierbei als Zonen unter dem Unterabschnitt Zones in der Projektdatei zusammengefasst, die Wände im Unterabschnitt ConstructionInstances. Zum Zweck der späteren Referenzierung werden sowohl Zonen als auch Wände mit einer id-Nummer versehen, die für alle Gebäudekomponenten eindeutig sein muss. Eine Zonen-Id-Nummer muss nicht nur innerhalb des Zonen-Blocks eindeutig sein, sondern sie darf auch nicht für Wände wiederverwendet werden. Im Validierungsfall wird nur ein Raum betrachtet, welcher der Zone mit der Id-Nummer 1 entspricht. Das Attribut Active informiert das NANDRAD-Modell darüber, dass für sie Zone eine thermische Bilanz gelöst werden soll, im Gegensatz beispielsweise zu Räumen mit konstanter Temperatur. Die Projektdatei registriert des Weiteren sechs Raumumschließungskonstruktionen mit den Id-Nummern 2-7.

	
<Zones>
  <Zone displayName="Pruefraum1" id="1" type="Active">
  ...
  </Zone>
  ...
</Zones>
...
<ConstructionInstances>
  <ConstructionInstance id="2">
  ...
  </ConstructionInstance>
  <ConstructionInstance id="3">
  ...
  </ConstructionInstance>
  <ConstructionInstance id="4">
  ...
  </ConstructionInstance>
  <ConstructionInstance id="5">
  ...
  </ConstructionInstance>
  <ConstructionInstance id="6">
  ...
  </ConstructionInstance>
  <ConstructionInstance id="7">
  ...
  </ConstructionInstance>
</ConstructionInstances>
    
	

Im Gegensatz zu den Vorgaben der Norm berücksichtigt NANDRAD die thermische Trägheit der Raumluft. Um dadurch verursachte thermische Verzögerungseffekte auszuschließen, werden Höhe und Raumgrundfläche auf annähernd 0 gesetzt und somit die Speicherkapazität des Zonenvolumens minimiert. Die entsprechenden Parameter sind Teil der Zonencharakterisierung im Unterabschnitt Zone und in die Parameter mit Namen Height und Area gekapselt. Der Typ IBK:Parameter erlaubt neben der Angabe konstanter Parameterwerte die Vorgabe einer konvertierbaren Parametereinheit (auch Nicht-SI-Einheiten) und eine Größenbenennung.

	
<Zone displayName="Pruefraum1" id="1" type="Active">
  <IBK:Parameter name="Height" unit="m">0.001</IBK:Parameter>
  <IBK:Parameter name="Area" unit="m2">0.001</IBK:Parameter>
  ...
</Zone>
    
	

Die Wände sammeln in der Datenstruktur ConstructionInstance Eigenschaften der Wandgeometrie, den Konstruktionsaufbau und Informationen über die Anordnung im Zonen-Wand-Netzwerk. Zu den Geometrieeigenschaften zählen zunächst der Wandorientierungswinkel auf der horizontalen Ebene (Orientation, 0° = Norden, 90° = Süden), der vertikale Wandneigungswinkel (Inclination, 0° = horizontale Wand, 90° = vertikale Wand, 180° = nach unten gerichtete Wand ) und die Wandfläche (Area).

Im Tag ConstructionTypeID wird der Wandaufbau über eine eindeutige Id-Nummer referenziert. Diese Id-Nummer muss dabei einer Wandkonstruktion gehören, die im Abschnitt Database unter ConstructionTypeReference aufgelistet wird. Die Wandkonstruktionen selbst sind allerdings in externe Datenbanken ausgelagert, nur die Dateinamen sind auf der Ebene der Projektdatei bekannt. Daher wurde die Regel eingeführt, dass die Id-Nummer einer Wandkonstruktion als Suffix an den zugehörigen Dateinamen angehangen wird. Die Id 1001 referenziert beispielsweise die Konstruktionsdatei Case1a_1001.d6p.

	
<ConstructionInstance id="2">
  <IBK:Parameter name="Orientation" unit="Deg">0</IBK:Parameter>
  <IBK:Parameter name="Inclination" unit="Deg">0</IBK:Parameter>
  <IBK:Parameter name="Area" unit="m2">1</IBK:Parameter>
  <ConstructionTypeID>1001</ConstructionTypeID>
  <Interfaces>
    <Interface id="8" location="A">
      <ZoneID>0</ZoneID>
    </Interface>
    <Interface id="9" location="B">
      <ZoneID>1</ZoneID>
    </Interface>
  </Interfaces>
</ConstructionInstance>
    
	

Die Wandoberflächen (Interfaces) bilden die Verbindungen zwischen Zonen und Wänden. Als eigenständige geometrische Komponenten sind sie mit einer Id-Nummer versehen. Das Attribut location bestimmt, auf welcher Seite der Wandkonstruktion sich die entsprechende Oberfläche befindet. Dabei postiert der Wert "A" die Oberfläche auf der linken, der Wer "B" auf der rechten Seite des Wandschichtaufbaus, wie er in der Konstruktionsdatei aufgelistet ist. Die Oberfläche (Interface) mit der Id-Nummer 8 befindet sich entsprechend linksseitig der 20 cm dicken Konstruktionsschicht der Konstruktion Case1a_1001.d6p, die Oberfläche mit der Id-Nummer 9 passend rechtsseitig. Die der Oberfläche angeschlossene Zone wird durch ihre eindeutige Id-Nummer im Tag ZoneID angegeben. Dabei ist die Id-Nummer 0 zur Kennzeichnung des Außenklimas reserviert. Die linke Konstruktionsseite ist im konkreten Beispielfall folglich eine Außenoberfläche, die rechte Seite eine Innenoberfläche zum einzigen Raum, die Wand selbst eine Außenwand.

In dem Beispielfall sind sechs Außenwände vorgesehen, welche allesamt gleichartig parametrisiert sind.

Beschreibung physikalischer Parameter

Zur vollständigen Parametrisierung des Simulationsfalles ist die Vorgabe von Startwerten sowie die Charakterisierung von Wärmeübertragungseigenschaften an den Wandoberflächen notwendig. Da im Normfall für alle Wände und Wandoberflächen identische Eigenschaften gefordert sind, wird die Parametrisierung zentral innerhalb der Projektdatei vorgenommen. Hierfür vorgesehen ist der Unterabschnitt ParametrizationDefaults, welcher individuell überschreibbare Standardeigenschaften zur Verfügung stellt. Der Modus (mode) muss hierfür auf Lazy gesetzt sein.

	
<ParametrizationDefaults mode="Lazy">
  <IBK:Parameter name="InitialTemperature" unit="C">20</IBK:Parameter>
  <IBK:Parameter name="HeatTransferCoefficient" unit="W/m2K">2.5</IBK:Parameter>
  <IBK:Parameter name="Ambient.HeatTransferCoefficient" unit="W/m2K">8</IBK:Parameter>
  <IBK:Parameter name="AbsorptionCoefficient" unit="---">0.0</IBK:Parameter>
  <IBK:Parameter name="Ambient.AbsorptionCoefficient" unit="---">0.0</IBK:Parameter>
</ParametrizationDefaults>
    
	

Als vorgegebene Standardparameter liefert die Projektdatei Starttemperaturen für die Raumluft und die Wandkonstruktionen (InitialTemperature), einen konstanten Wärmeübergangskoeffizienten für alle Innenoberflächen (HeatTransferCoefficient) und Außenoberflächen (Ambient.HeatTransferCoefficient), den Absorptionskoeffizienten für kurzwellige Strahlung der Innenoberflächen (AbsorptionCoefficient) und für Solarstrahlung der Außenoberflächen (Ambient.AbsorptionCoefficient). Für den Normfall wird die Solarstrahlungsberechnung deaktiviert, alle entsprechenden Koeffizienten sind auf Null gesetzt.

Neben der zentralen Parametrisierung ist auch die indivuelle Angabe von Wandoberflächeneigenschaften zulässig. Hierzu sei auf die NANDRAD-Wiki-Seite verwiesen. Analog ist eine individuelle Vorgabe von Zonenstarttemperaturen (siehe NANDRAD-Wiki-Seite ) und Wandtemperaturen (siehe NANDRAD-Wiki-Seite ) möglich.

Anforderung von Simulationsausgaben

Simulationsausgaben erfolgen stets für eine Liste von geometrischen Komponenten gleichen Types (Zonen, Wandkonstruktionen, Oberflächen) oder Modellen, die allesamt diesselbe Ausgabegröße anbieten. Diese Kompontenlisten werden in Form von Objektlisten (ObjectLists) erzeugt. Eine Objektliste besitzt einen eindeutigen Namen (name), einen Typenkennzeichner (FilterType) und einen Id-Kennzeichner für alle Listenelemente (FilterID). Im Normfall werden Raumtemperaturen verglichen. Daher ist die ANlage einer Objektliste für die Ausgabezone verpflichtend. Diese wird durch den Filtertyp Zone umschrieben und durch den npassenden Id-Filter ausgewählt.

	
<ObjectLists>
  <ObjectList name="Pruefraum1">
    <FilterType>Zone</FilterType>
    <FilterID>1</FilterID>
  </ObjectList>
  ...
</ObjectLists>
    
	

Weitere mögliche Objekttypen sind auf der NANDRAD-Wiki-Seite gelistet, ebenso wie alternative Id-Filterformate.

Zu jeder Objektliste können Ausgaben angefordert werden. Diese werden in der Projektdatei im Unterabschnitt Outputs spezifiziert. Jede Ausgabe ist durch ein Zeitraster (OutputGrid) charakterisiert. Dieses kann eines oder mehrere Intervalle (Interval) besitzen, in denen unterschiedliche Ausgabezeitschritte (StepSize) festgelegt sind. Für den vorliegenden Fall sind stündliche Simulationsausgaben zielführend, die StepSize wird auf den Wrt von 1 h gesetzt. Der Name "Hourly" dient als Referenzname für das entsprechende Zeitraster.

	
<Outputs>
  ...
  <OutputGrids>
    <OutputGrid name="Hourly">
      <Interval>
        <IBK:Parameter name="StepSize" unit="h">1</IBK:Parameter>
      </Interval>
    </OutputGrid>
  </OutputGrids>

  <OutputDefinitions>
    <OutputDefinition>
      <OutputGridName>Hourly</OutputGridName>
      <ObjectListName>Pruefraum1</ObjectListName>
      <Quantity>AirTemperature</Quantity>
      </OutputDefinition>
      ...
    </OutputDefinitions>
</Outputs>
    
	

Die Ausgaben selbst werden durch Ausgabedefinitionen (OutputDefinitions) angefordert. Das Ausgabezeitraster wird über den Referenznamen (OutputGridName) angegeben. Zusätzlich wird die Objektliste namentlich spezifiziert (ObjectListName), die alle auszugebenden Komponenten enthält, im konkreten Fall die einzige Zone "Pruefraum1". Angefordert wird die Raumlufttemperatur "AirTemperature" als Ausgabegröße (Quantity).

Innerhalb der Initialisierung eines NANDRAD-Simulationslaufes werden alle verfügbaren Ausgabegrößen, also Werte für für Quantity, zusammen mit den passenden Objekttypen in der Datei var/output_reference_list.txt abgelegt. Genaueres zur Ausgabe-Ordnerstruktur siehe nächster Abschnitt.

Ergebnisse der NANDRAD-Berechnung

Die Simulation wird durch die Batch-Datei run.bat im Projektordner gestartet. Diese enthält die Aufrufsyntax für den Kommandozeilensolver (hier für den ersten Validierungsfall):

    
<solver path>/NandradSolver.exe <project file path>/Case1a.nandrad
    
	

Im NANDRAD Simulationslauf wird unter dem Projektnamen (project name) eine Ordnerstruktur Simulationsausgaben angelegt. Diese enthält die Unterordner

  • <project name>/log
  • <project name>/results
  • <project name>/var

Innerhalb des log-Ordners befinden sich Ausgaben zum Simulationsverlauf und Rückmeldungen der numerischen Verfahren. Der Ordner results enthält Simulationsausgaben, der Ordner var für weitere Berechnungen oder Verarbeitung bestimmte Zwischenergebnisse.

Die Simulation des Normfalles 1 erzeugt die Ergebnisdateien Case1a/results/Location_Temperature.d6o und Case1a/results/Zones_AirTemperature_objectList(Pruefraum1).d6o. Ergebnisdateien enthalten im Namen stets den Komponententyp, für den die AUsgabe erzeugt wurde, also Location für das Außenklima und Zones für Zonenausgaben. Dieser wird gefolgt vom Namen der Ausgabegröße (Außentemperatur Temperature und Raumlufttemperatur AirTemperature), sowie dem Namen der Komponentenobjektliste (Pruefraum1 für den Innenraum). Die gewünschten Raumlufttemperaturen finden sich in der Datei Zones_AirTemperature_objectList(Pruefraum1).d6o:

	
D6OARLZ! 007.000
TYPE          = REFERENCE
PROJECT_FILE  = Case1a.nandrad
CREATED       = Fri Jun 15 12:00:28 2018
GEO_FILE      =
GEO_FILE_HASH = 0
QUANTITY      = 1 'Pruefraum1'
QUANTITY_KW   = AirTemperature
SPACE_TYPE    = SINGLE
TIME_TYPE     = NONE
VALUE_UNIT    = C
TIME_UNIT     = h
START_YEAR    = 2011
INDICES       = 1

0            	20
...
6            	21.30795
...
12           	23.48059
...
24           	26.372
...
120          	29.96667
    
	

Dies Ausgabedatei enthält einen Kopfteil mit Informationen über das Erstelldatum, die Ausgabegröße, Zeit- und Werteeinheit, sowie alle angeforderten Id-Nummern. Der darauffolgende Hauptteil enthält als erste Spalte die Realzeit in der vorgegebenen Zeiteinheit (TIME_UNIT), in den darauffolgenden Spalten die Ergebniswerte (QUANTITY_KW) in der vorgegebenen Ausgabeeinheit (VALUE_UNIT). Diese Ausgabeformat kann durch das am IBK verfügbare wissenschaftliche Postprocessing visualisiert werden.

Für die Validierung des Normfalles sind die Raumlufttemperaturen für die Zeiträume von 0 Stunden, 6 Stunden, 12 Stunden, 24 Stunden und 120 Stunden nach Simulationsbeginn mit den Normwerten zu vergleichen. Für diesen Anwendungsfall ist eine Auswertung der Textdatei zureichend. Die Berechnung aller vier Falltypen erzeugt die folgenden Ergebnisse:

                            nach 2h  nach 6h  nach 12 h  nach 24 h  nach 120 h
							
Sollwerte Norm Prüfraum 1    20.04    21.26     23.48      26.37        30
NANDRAD                      20.05    21.31     23.48      26.37      29.97
Abweichung                   -0.01    -0.05        0          0        0.03
                                                          
Sollwerte Norm Prüfraum 2    25.09    29.63       30         30         30
NANDRAD                      25.09    29.63     29.99        30         30
Abweichung                      0       0        0.01         0          0
                                    
Sollwerte Norm Prüfraum 3      20     20.26     21.67       24.9      29.95
NANDRAD                        20     20.26     21.67       24.9      29.94
Abweichung                      0       0         0           0        0.01
                                   
Sollwerte Norm Prüfraum 4      20     20.06     20.25      20.63      23.17
NANDRAD                        20     20.06     20.25      20.62      23.17
Abweichung                      0       0         0         0.01         0

Tabelle 2: Vergleich der Simulationsergebnisse für Testfall 1
    

Validierungsfall 2

Testfall 2 berücksichtigt den langwelligen Strahlungsaustausch zwischen den Rauminnenwänden bei unterschiedlicher Raumgemetrie, vergleiche Abbildung 2. Dabei wird die braune Fläche als Außenwand gedeutet bei konstanter Außentemperatur von 30°C, alle anderen Wände als Innenwände zu einem Nachbarraum mit konstanter Temperatur von 20°C.

Die Außenfläche ist durch einen Durchlasskoeffizient von 5W/m2K charakterisiert, für alle anderen Flächen ist dieser 1W/m2K.

Der langwellige Strahlungsaustausch an der Wandaußenflächenfläche wird durch einen Übergangskoeffizienten von 5,5W/m2K erfasst, zusätzlich zum Wärmeübergang durch Konvektion 8W/m2K.

In Folge kurzwelliger Strahlung adsorbiert die Innenoberfläche der Außenwand eine Wärmestrahlung in von 100W/m2. Der Konvektionswärmeübergangskoeffizient zum Innenraum beträgt 5W/m2K, alle anderen Innenlächen besitzen einen Konvektionswärmeübergangskoeffizient von 2,5W/m2K. Der langwellige Emissionsgrad aller Oberflächen auf der Innenseite beträgt 0.9.


Abbildung 2: Raumgeometrien für Testfall 2

(Auf das Diagram zum Vergrößern klicken)

Modellierung in NANDRAD

Die Herausforderung in dem konkreten Beispiel besteht in zwei Schwerpunktthemen: Zunächst muss die Erwärmung der Innenoberfläche durch eine konstante Last gesichert werden. Um dies zu erreichen, muss ein geeignetes Lastmodell genutzt werden, welches ausschließlich eine Erwärmung der isolierten Oberfläche bewirkt. Zum Anderen konstanten ist geometrischen Verteilung der eingetragenen Last im Innenraum in Folge langwelliger Strahlung von Interesse. Hierfür sind die bisher vorgestellten Geometrieinformationen unzureichend.

Modellierung der Wandkonstruktionen und der Nachbarräume

Die Wandaufbauten wurden ebenso wie in Testfall 1 durch nutzerdefinierte Materialeigenschaften mit einer Wärmeleitfähigkeit von 0.1W/mK eingepflegt. Für Wärmekapazität und Massedichte des Materials wurden willkürliche Werte von 10kg/m3, 840J/kgK gesetzt, die das stationäre Ergebnis nicht beeinflussen. Die Wanddicke für die Außenwand wurde mit d=2cm, für die Innenwände mit d=10cm angesetzt.

Als Beispielprojekt dient im Folgenden die Projektdatei Case2a.nandrad. Der Simulationsfall berücksichtigt im Gegensatz zum ersten Fall konstante Nachbarräume. Somit liegt ein Mehrzonenmodell vor, auch wenn die thermische Bilanz nur für einen der beiden Räume gelöst wird. Um diese Bedingungen in NANDRAD abzubilden, wurde ein konstanter Nachbarraum hinzugefügt und mit dem Attribut Constant versehen, welches die entsprechende Zone der Bilanzberechnung entnimmt. Verpflichtend ist die Angabe der Raumposition (location), in diesem Fall ein Innenraum (Inside), um eine differenzierte Bilanzierung von eventuellen Wärmeverlusten zu ermöglichen. Da keine Berechnung vorgesehen ist, muss ein konstanter Raum zusätzlich die entsprechende Raumlufttemperatur Temperature als Parameter liefern.

	
<Zone displayName="Constant Zone" id="1" type="Constant" location="Inside">
  <IBK:Parameter name="Temperature" unit="C">20</IBK:Parameter>
</Zone>
    
	

Berücksichtigung geometrischer Detailinformation des Innenraumes für den langwelligen Strahlungsaustausch

Als nichtgeometrisches Modell verfügt NANDRAD über keine Befähigung zur Berechnung geometrischer Verteilungen. Anstelle von Geometrieinformation müssen entsprechende Kenngrößen übermittelt werden. Im Fall der langwelligen Strahlungsbilanz sind dies die Sichtbarkeitsfaktoren aller Innenoberflächen des zu berechnenden Raumes. Diese wurden durch das Hilfstool Radiance vorberechnet und ins Modell eingepflegt.

Die Sichtbarkeitsfaktoren (ViewFactors) sind als Eigenschaft in der Projektdatei einer Zone zugeordnet. Sie werden tabellarisch angegeben, wobei die erste Zeile und zweite Spalte jeweils die Id-Nummern der empfangenden und aussendenden Oberfläche (Interface) angeben. Die dritte Spalte enthält den zugehörigen Sichtbarkeitsfaktor.

	
<Zone displayName="Pruefraum1" id="2" type="Active">
  ...
  <ViewFactors>
    100026 100026 0.00000
    100026 100028 0.20001
    ...
    100030 100030 0.00000
    100030 100026 0.19982
    ...
    100036 100032 0.20004
    100036 100034 0.19982
 </ViewFactors>
</Zone>
    
	

Die angegebenen Id-Nummern entsprechen hierbei allen Oberflächen (Interfaces), welche an die entprechende Zone mit der Id-Nummer 2 grenzen. Dies ist beispielsweise das Interface mit der Id-Nummer 100030. DIe Vollständigkeit aller Sichtbarkeitsfaktiren wird vorausgesetzt. Die passende Oberfläche liefert zusätzlich den langwelligen Emissionsgrad (Emissivity) als Parameter. Parameter für Wandoberflächen sind stets in Modelle gekapselt, die gegebenenfalls eine komplexere Berechnungsvorschrift erlauben. Im konkreten Fall ist die Angabe eines konstanten Emissionsgrades zureichend, und das Berechnungsmodell LongWaveEmission vom Typ "Constant" wird bedient.

	
<ConstructionInstance id="100003" displayName="Flaeche2Pruefraum1">
  ...
  <Interfaces>
    <Interface id="100030" displayName="Flaeche2Pruefraum1 A" location="A">
      <ZoneID>2</ZoneID>
      ...
      <LongWaveEmission model="Constant">
        <IBK:Parameter name="Emissivity" unit="---">0.9</IBK:Parameter>
      </LongWaveEmission>
    </Interface>
    ...
  </Interfaces>
  ...
</ConstructionInstance>
    
	

Aktivierung des Heizmodells

Im Validierungsfall muss eine Innenoberfläche modelliert werden, die einen konstanten Wärmestrahlungseintrag adsorbiert. Um diesen Effekt nachzubilden, wird in NANDRAD wird die entsprechende Innenoberfläche durch eine Flächenheizung mit identischer Leistung erwärmt. Die Flächenheizung befindet sich dabei innerhalb einer dünnen oberflächennahen Konstruktionsschicht.

Nahezu alle Lastberechnungen, die zu- und abschaltbare Mechanismen wie Heizung oder Lüftung beschreiben, werden in Modelle (Model) gekapselt. Für den Flächenheizkörper mit vordefinierter Heizlast ist das Modell ConstructionInternalSourceModel reserviert. Dieses wird mit einer Id-Nummer versehen, die innerhalb des Modellblocks eindeutig sein muss.

Das Modell überträgt die Heizlast in eine nutzergewählte Wandkonstruktionsschicht und reichert damit die zugehörigen Bilanzgleichungen an. Die Meldung einer Heizlast erfolgt durch eine Modellrückwirkung (ImplicitModelFeedback). Diese wählt das zu beheizende Objekt mittels einer Objektliste (ObjectList) aus und referenziert den zugehörigen Objektlistennamen (ObjectListName), in diesem Fall die beheizte Wand (ConstructionInstance) mit der Id-Nummer 100003. Der Index der Zielgröße FieldFlux[0] spezifiziert die Konstruktionsschicht in der Konstruktionsdatei, in welche die Heizlast eingetragen werden soll. Um nach Möglichkeit nur die Wandoberfläche aufzuheizen, wurde die linksseitige Konstruktionsrandschicht mit Index 0 ausgewählt.


<Models>
  <Model model="ConstructionInternalSourceModel" id="1">
    ...
    <ImplicitModelFeedback>
      <ObjectListName>Flaeche2Pruefraum1</ObjectListName>
      <Quantity>ConvectiveHeatingFlux</Quantity>
      <TargetName>FieldFlux[0]</TargetName>
      ...
    </ImplicitModelFeedback>
    ...
  </Model>
</Models>
...
<ObjectLists>
  ...
  <ObjectList name="Flaeche2Pruefraum1">
    <FilterType>ConstructionInstance</FilterType>
    <FilterID>100003</FilterID>
  </ObjectList>
</ObjectLists>
    
	

Modellierung von Nutzungsszenarien und Raumanforderungen

Auslegung und Regelung von Anlagen- und Heizkomponenten sind auf Informationen zum Raumnutzungsverhalten angewiesen. Zu diesem Zweck werden Gruppen von ähnlichgearteten Räumen (SpaceTypes) bestimmt und mit identischem Verhalten versehen. Raumnutzungsgruppen werden durch ihren Namen (SpaceTypeName) referenziert, wobei jeder bilanzierte Raum (Zone) einer Nutzungsgruppe zugeordnet werden und diese referenzieren muss.

	
<SpaceTypes>
  <SpaceType name="Pruefraum1"/>
</SpaceTypes>
...
<Zones>
  ...
  <Zone displayName="Pruefraum1" id="2" type="Active">
    <SpaceTypeName>Pruefraum1</SpaceTypeName>
    ...
  </Zone>
</Zones>
    
	

Während konstante Parameter zur Raumnutzung im Tag SpaceType erfasst werden, sind Zeitpläne (Schedules) zur Beschreibung zeitlich variabler Nutzungseigenschaften vorgesehen. Für den Flächenheizkörper stellt die vordefinierte Heizlast eine solche Raumnutzungeigenschaft dar. Über einen Tagesrhytmus (DailyCycle) verteilt werden Intervalle (Interval) definiert, die unterschiedliche Parameterwerte ein und derselben Größe zu verschiedenen Tageszeiten enthalten. Für den Validierungsfall ist lediglich die ganztägig vorgegebene konstante Heizlast (HeatingLoad) von 100 W bedeutsam.

Jeder Tagesablauf wird einem Zeitplan (Schedule) zugeordnet, der für verschiedene Wochentage, das Wochenende, Ferientage gültig ist. Der Typ (AllDays) beschreibt ein täglich gültiges Nutzerverhalten. Nähere Informationen und Regeln sind auf der NANDRAD-Wiki-Seite zusammengefasst.

Ein Zeitplan ist Teil einer Raumnutzungsgruppe (SpaceTypeGroup), die über ihren Namen (spaceTypeName) referenziert wird, im konkreten Fall die Gruppe "Prüfraum1". Alle Raumnutzungsgruppen sind Unterkategorien einer Schedulegruppe (ScheduleGroup). Im Validierungsfall ist nur eine Basisgruppe ohne zeitliche Begrenzung vorhanden. Es können neben dieser Basisgruppe weitere Gruppen (ScheduleGroup) definiert werden, die für bestimmte Jahresabschnitte wie beispielsweise Sommer oder Winter ein abweichendes Nutzerverhalten vorsehen. Mehr Informationen sind auf der auf der NANDRAD-Wiki-Seite verfügbar.

	
<Schedules>
  <ScheduleGroup>
    <SpaceTypeGroup spaceTypeName="Pruefraum1">
      <Schedule type="AllDays">
        <DailyCycle>
          <Interval>
            <IBK:Parameter name="HeatingLoad"    unit="W">100</IBK:Parameter>
          </Interval>
        </DailyCycle>
      </Schedule>
    </SpaceTypeGroup>
  </ScheduleGroup>
</Schedules>
    
	

Alle in Zeitplänung oder Raumnutzungsgruppen definierten Eigenschaften werden den gruppierten Räumen zugeschlagen und sind als Zoneneigenschaft abrufbar. Für die Flächenheizung bedeutet dies, dass die Heizlast durch als berechnete Größe in der Zone mit Id-Nummer 2 verfügbar ist. Solche Modellabhängigkeiten bilden komplexe Referenzen, die als ModelInputReference zusammengefasst werden. Die ModelInputReference muss eine Objektliste namentlich referenzieren (ObjectListName), welche die gewünschte Größe (Quantity) anbietet, in diesem Fall die Heizlast "HeatingLoad".

	
<Models>
  <Model model="ConstructionInternalSourceModel" id="1">
    ...
    <ModelInputReference>
      <ObjectListName>Pruefraum1</ObjectListName>
      <Quantity>HeatingLoad</Quantity>
      </ModelInputReference>
    </Model>
</Models>
...
<ObjectLists>
  ...
  <ObjectList name="Pruefraum1">
    <FilterType>Zone</FilterType>
    <FilterID>2</FilterID>
  </ObjectList>
  ...
</ObjectLists>
    
	

Ergebnisse der NANDRAD-Berechnung

Der Validierungsfall prüft die Ergebnisse im stationären Zustand. Dieser wird nach zwei Tagen für alle Testfälle erreicht. Die Raumlufttemperaturen sind im Ausgabeordner des entsprechenden Simulationsfalles verfügbar, für den Fall 2a beispielsweise unter Case2a/results/Zones_AirTemperature_objectList(Pruefraum1).d6o.

	
D6OARLZ! 007.000
TYPE          = REFERENCE
PROJECT_FILE  = Case2a.nandrad
CREATED       = Fri Jun 15 16:38:15 2018
GEO_FILE      =
GEO_FILE_HASH = 0
QUANTITY      = 2 'Pruefraum1'
QUANTITY_KW   = AirTemperature
SPACE_TYPE    = SINGLE
TIME_TYPE     = NONE
VALUE_UNIT    = C
TIME_UNIT     = h
START_YEAR    = 2011
INDICES       = 2

0                20
24               34.14825
    
	

Tabelle 2 vergleicht die Raumtemperaturen für die Normfall und die NANDRAD Berechnung. Laut Norm wird eine Abweichung von maximal 0,5 K als zulässig erachtet.

               Prüfraum 1  Prüfraum 2  Prüfraum 3  Prüfraum 4

Sollwerte Norm    34.4        30.4        38.5         25.5
NANDRAD          34.14       30.27       38.37        25.61
Abweichung       -0.26       -0.13       -0.13         0.11

Tabelle 2: Vergleich der Simulationsergebnisse für Testfall 2
	

 

(Auf Hintergrund klicken, um zu schließen)