



\chapter{GH script Workflow}
\label{ch:Workflow}


\section{Introduction for generating process}
In this section, we provide an overview of the simulation process. Prior to commencing the simulation, all necessary software and programs are prepared. The simulation process unfolds in the following sequential steps. To realize it, a \glsxtrshort{GH} programme is built up. A general canvas (see \cref{fig:MasterCite}) is presented here, which is sub-divided into 6 parts. All the 6 parts are presented below. The roman numbers refer to which following step is conducted within this red block. For deeper information, please turn to the relative sub-part of the canvas.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/Master-CITE.png}
	\caption{General \glsxtrshort{GH} Canvas\footnote{A larger version can be found in \cref{ch:appendix_Algorithm}}}
	\label{fig:MasterCite}
    \hfill
\end{figure}

In addition to \cref{fig:MasterCite}, a general workflow is displayed in \cref{fig:General workflow}, which indicates the tools that have been use on the exam. That is a logical process.
\newline \textit{Design the box}\ $\longrightarrow$ \textit{Simulation}\ $\longrightarrow$ \textit{Optimization}
\newline and \cref{subsec:I,subsec:II,subsec:III,Step IV: Operational Setting} are designing the box; while \cref{subsec:Step_V} is the simulation; and \cref{subsec:Step_VI} is the optimization.

\subsection{Step I: Preset}
\label{subsec:I}
In this initial step, the climate data, formatted as .epw files, are defined, and contextual surroundings are imported as geometries in \glsxtrshort{RH}.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/sec-A.png}
	\caption{GH section A}
	\label{fig:GH section A}
    \hfill
\end{figure}


\subsection{Step II: Database}
\label{subsec:II}
This step involves designing new constructions added to the existing ones. Using the \textit{HB\_Opaque Material} and \textit{HB\_Opaque Construction} components, new layers are incorporated. Material properties are derived from the Design Builder database and the Matweb\cite{MatLibrary}. Cost and price data, as explained in \cref{sec:design-object,sec:static-design,sec:Operative-design}, are associated with each material and imported into \glsxtrshort{GH}. Presented in \cref{fig:GH section B}, 3 insulation and window construction set are completed, which are:

\begin{itemize}
\setlength{\itemsep}{1pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\item Insulation of Wall
\item Insulation of Roof
\item Insulation of Floor (control group)
\item Glazing of Window
\item Framework of Window
\end{itemize}

The unchanged parts stay as the vintages are. Also the prices are here input into the program.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/sec-B.png}
	\caption{GH section B}
	\label{fig:GH section B}
    \hfill
\end{figure}


\subsection{Step III: \glsxtrshort{BIM} Setting}
\label{subsec:III}
This stage encompasses \glsxtrshort{BIM}, wherein the model contains both geometric and non-geometric data, defining horizontal faces into office or corridor, also doing the vertical ones into external or internal walls (see \cref{fig:GH section C}). This is achieved through the use of the \textit{HB Face component}. Subsequently, the \textit{HB Room} is created, with attention to using the \textit{HB Solve Adjacency} component for interior face matching, resulting in an information-rich model. 


\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/sec-C.png}
	\caption{GH section C}
	\label{fig:GH section C}
    \hfill
\end{figure}


\subsection{Step IV: Operational Setting}
\label{Step IV: Operational Setting}
Beyond the typical \glsxtrshort{BIM}, schedules for \glsxtrshort{CNV} and \glsxtrshort{HVAC} systems, as discussed in the operative design, are established. This includes:
\begin{itemize}
\item \textbf{Occupancy schedule:} This schedule indicates the occupancy ratio inside the room relative to its capacity, influencing other schedules. For unoccupied hours, the schedule is set to 0, with variations during working hours. (see \cref{fig:GH section A} Base schedule)
\item \textbf{Set-points:} Set-points for heating and cooling are adjusted based on occupancy. For unoccupied hours, they are set to maximum tolerance levels. (see \cref{fig:GH section A} Heating and Cooling schedule)
\item \textbf{Lighting schedule:} Based on occupancy schedule, lighting is set to 0 lux during unoccupied hours and operates in a smart mode when occupancy is greater than 0. (see \cref{fig:GH section A} sb. inside)
\item \textbf{Ventilation control:} Based on occupancy schedule, it's applied on top of delta set-point. That's temperature differential in Celsius between indoor and outdoor below which ventilation is shut off. This should usually be a positive number so that ventilation only occurs when the outdoors is cooler than the indoors. Negative numbers indicate how much hotter the outdoors can be than the indoors before ventilation is stopped. This number is one of the \textbf{Genomes}. (see \cref{fig:GH section D})
\item \textbf{\glsxtrshort{HVAC} system type:} PVAV\_Boiler is selected, since I want a \glsxtrshort{HVAC} system that fit to majority for the buildings, so a \glsxtrshort{PVAV} \glsxtrshort{HVAC} system benefits that. (see \cref{fig:GH section E} \glsxtrshort{HVAC} part)

\end{itemize}

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/sec-D.png}
	\caption{GH section D}
	\label{fig:GH section D}
    \hfill
\end{figure}



\subsection{Step V: Run the Simulation}
\label{subsec:Step_V}
Once the model from Step II is combined with the schedule from Step III, the \textit{HB\_Model} is developed, allowing for the execution of simulations. 4 simulation programs are conducted (see \cref{fig:GH section E}), including: 

\begin{itemize}
\item \textbf{\glsxtrshort{EUI} simulation:} Using \textit{HB Model to OSM} to start, operating on \glsxtrshort{EP}. And read the result by \textit{HB Read Room Energy Result}. This process needs a \textit{toggle} to activate.
\item \textbf{Comfort assessment:} Run after the \glsxtrshort{EUI} simulation. Using \textit{HB Read Room Comfort Result} to get the data, with an analysis period prepared, insert these inputs into \textit{LB PMV Comfort}, then output the \glsxtrshort{PPD}. This process needs a \textit{toggle} to activate.
\item \textbf{daylighting analysis:} Firstly, extract all the faces to be evaluated. Secondly, use \textit{LB Generate Point Grid, LB Generate Point Grid, LB Generate Point Grid} applied to the \glsxtrshort{HB} Model. Parallelly, use \textit{HB Wea From EPW } to set the weather. Thirdly, run the \textit{HB Annual Daylight } and use \textit{HB Annual Results to Data} to get the data of natural light. Lastly, use the mathematical method presented in \cref{sec: Approach for lighting simulation}, \cref{eq:RoomIndex,eq:MaintenanceF,eq:IlluminaceLevel,eq:Efficay} to calculate the consumption. This process needs a \textit{toggle} to activate to transfer to Radiance.
\item \textbf{economic accumulation:} Practice it with the mathematical method presented in \cref{sec: Approach for economical analysis}, \cref{eq:LCC,eq:GloblalCost,eq:GloblalCost2,eq:NPV}. Unit price times quantity. To get total prices for all the sections, here're the initial cost:
\begin{itemize}
\setlength{\itemsep}{1pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\item Price of Wall
\item Price of Roof
\item Price of Floor
\item Price of Window
\item Price of Louver
\item Price of Labor
\end{itemize}
Here're the annual cost:
\begin{itemize}
\setlength{\itemsep}{1pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
\item Total \glsxtrshort{HVAC} consumption
\item Lighting consumption
\end{itemize}
Add them together, then input into the NPV calculator that I've invented, so that we can evaluate how much is the net present cost. This process is activated \textbf{automatically}, it doesn't need to transfer to \glsxtrshort{EP} or Radiance.
\end{itemize}

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/sec-E.png}
	\caption{GH section E}
	\label{fig:GH section E}
    \hfill
\end{figure}




\subsection{Step VI: Repeat by the GA}
\label{subsec:Step_VI}
To iterate through the simulation process, the Wallacei\_X component is employed to automate parameter adjustments. It facilitates the generation of parameters for subsequent simulations, ensuring the process repeats automatically until reaching a specified generation count. This is presented in the VI block in \cref{fig:GH section E}.

\subsection{After experiment: Visualisation}
\label{subsec:Visualisation}
This step processes after all the \glsxtrshort{GA} generations are done. Presented in \cref{fig:GH section F}, it can be sub-divided into 4 steps:
\begin{itemize}
\item \textbf{Decoding and extracting the data: } The data is stored in the \textit{Wallacei X} component. Before all, we can use a \textit{tree branch} or \textit{split tree} to extract to analysed generation. For the \textit{WGenomes} and the \textit{WPhenotypes}, we shall apply a decoding component to translate them. 
\item \textbf{From numbers to colors:} Firstly, use \textit{bounds} to get the boundary of the numbers. Then, use a \textit{Gradient} with limits connecting to the bounds, translate the numbers in to \glsxtrshort{RGB} colors.
\item \textbf{Generating the chromosome matrix:} Use \textit{series} and \textit{mesh plane} to create the display matrix. And also print all the title bars.
\item \textbf{Coloring the matrix:} Use a human plug-in\cite{Human}, \textit{Custom Preview with Materials} with 2 matching diffuse color and geometry data tree. It can render the colored mesh on screen.
\end{itemize}

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/GH/sec-F.png}
	\caption{GH section F}
	\label{fig:GH section F}
    \hfill
\end{figure}




\section{Boundary Conditions}
\label{sec:Boundary Conditions}

This section outlines the key assumptions considered for the experiment, including boundary conditions i.e. context and orientation.

\subsection{Local climate}
\label{subsec:Local climate}

Weather data is imported into the \glsxtrshort{GH} environment using \glsxtrshort{LB} with \textit{LB Import \glsxtrfull{EPW}} files. \glsxtrshort{EPW} files are text files containing hourly information on temperature, relative humidity, wind speed and direction, solar radiation, illuminance, and pressure for a specific location. In the first eight lines of each \glsxtrshort{EPW} file, additional information is provided, including ``location coordinates, design conditions, typical/extreme periods, ground temperatures, holidays/daylight savings, data periods, and comments''\cite{EPW_Dic}.



The proposed method is implemented by considering 6 representative locations across Europe and 5 in east Asia (see \cref{fig:citySelnClass}), each characterized by distinct climatic conditions. These locations include Palermo, Rome, and Turin in Italy, as well as Geneva in Switzerland, Oslo in Norway, and Kiev in Ukraine among European countries\cref{fig:Cities_Euro}. Additionally, there are Canton, Hong Kong, Tientsin in China, Busan in Korea, and Kyoto in Japan, representing Asian regions\cref{fig:Cities_Asian}. The weather data is obtained from meteorological ground stations near these cities.

To obtain the weather data, EPWMap website is visited\cite{EPWMap}.






\begin{table}[h]
\centering
\begin{tblr}{|Q[c,m,2cm]|Q[l,m,5cm]|Q[l,m,4cm]|}
\hline
\textbf{1st} & \textbf{2nd} & \textbf{3rd} \\
\hline
\hline
(A) &  (f) Rainforest & \\
Tropical & (m) Monsoon & \\
& (w) Savanna, dry winter & \\
& (s) Savanna, dry summer & \\
\hline
(B) & (w) Arid Desert &(h) Hot \\
Dry & (s) Semi-Arid or steppe& (k) Cold\\
\hline
 (C) & (w) Dry winter & (a) Hot summer \\
Temperate& (f) No dry season & (b) Warm summer \\
& (s) Dry summer & (c) Cold summer \\
\hline
 (D) & (w) Dry winter & (a) Hot summer \\
Continental & (f) No dry season & (b) Warm summer \\
& (s) Dry summer & (c) Cold summer \\
& & (d) Very cold winter \\
\hline
 (E) & & (T) Tundra \\
Polar& & (F) Ice cap \\
\hline
\end{tblr}
\caption{Köppen classification scheme symbols}\cite{Beck2018,kottek2006,hess-11-1633-2007} 
\label{tb:Koppen3Letters}
\end{table}


``The Köppen climate classification scheme categorizes the types with 3 letters (see \cref{tb:Koppen3Letters}).
The first letter divides climates into five main climate groups: \textit{A} (tropical), \textit{B} (arid), \textit{C} (temperate), \textit{D} (continental), and \textit{E} (polar)\cite{11}. The second letter indicates the seasonal precipitation type, while the third letter indicates the level of heat\cite{hess-11-1633-2007}. Summers are defined as the 6-month period that is warmer either from April–September and/or October–March, while winter is the 6-month period that is cool''\cite{Beck2018}.

\begin{table}[h]
    \centering
	\includegraphics[width=\linewidth]{images/tables/tabular/ClimateClass.png}
	\caption{Cities selected and classification}
	\label{fig:citySelnClass}
    \hfill
\end{table}

\begin{figure}
    \centering
    \includegraphics[width=\linewidth]{images/Climate & Map/Cities_Asian.jpg}
    \caption{Asian selected cities}
    \label{fig:Cities_Asian}
\end{figure}
\begin{figure}
    \centering
    \includegraphics[width=\linewidth]{images/Climate & Map/Cities_Euro.jpg}
    \caption{European selected cities}
    \label{fig:Cities_Euro}
\end{figure}


\subsection{Context}
\label{Context}

Context geometries are initially modeled in \glsxtrshort{RH} and subsequently imported into \glsxtrshort{GH} as Breps or Meshes (see \cref{fig:Example of context}). These geometries are then integrated into the \glsxtrshort{GH} environment using the \textit{HB Shade} plugin.

\begin{figure}
    \centering
    \includegraphics[width=\linewidth]{images/tables/Context.png}
    \caption{Example of context}
    \label{fig:Example of context}
\end{figure}


The study assumes that the analyzed office space is situated within an urban setting. To simulate the surrounding urban context, a series of adjacent buildings are generated as solid blocks. \cref{Context} illustrates this random generation of neighboring buildings. It's important to note that the context remains consistent across all selected locations.

Furthermore, a ground surface is created directly within \glsxtrshort{GH} as a \glsxtrshort{HB} surface. This addition enhances the accuracy of daylight calculations within the simulation.





The overall performance of the building is assessed by evaluating two key aspects that significantly influence indoor comfort and efficiency: energy usage and daylight availability. Two concurrent and detailed dynamic simulations are executed using the \glsxtrshort{HB} plug-in (v1.6.0) and the \glsxtrshort{LBT} (v1.6.26), serving as interfaces with \glsxtrshort{EP}, Radiance, and Daysim simulation engines. These components are integrated within a single pollination\cite{Pollination} package for seamless coordination.
It's worth noting that, for this phase of the research, the thermal zone operates in a free-running mode. This paragraph provides information about the software programs employed, the configuration of simulation parameters, and the formats of the output files generated. The definitions presented in this paragraph are primarily sourced from the descriptions of inputs and outputs of the \glsxtrshort{HB} components.


\section{Model building}
\label{sec:Model building}
The overall performance of the building is assessed by evaluating two key aspects that significantly influence indoor comfort and efficiency: energy usage and daylight availability. Two concurrent and detailed dynamic simulations are executed using the Honeybee plug-in (v1.6.0) and the \glsxtrshort{LBT} (v1.6.26), serving as interfaces with \glsxtrshort{EP}, Radiance, and Daysim simulation engines. These components are integrated within a single pollination\cite{Pollination} package for seamless coordination.
It's worth noting that, for this phase of the research, the thermal zone operates in a free-running mode. This paragraph provides information about the software programs employed, the configuration of simulation parameters, and the formats of the output files generated. The definitions presented in this paragraph are primarily sourced from the descriptions of inputs and outputs of the \glsxtrshort{HB} components.


~\\
Model are conducted using \glsxtrshort{EP} (v22.2.0) in conjunction with OpenStudio (v3.5.1). \glsxtrshort{OS} serves as the bridge connecting the three-dimensional parametric model created in \glsxtrshort{RH} and \glsxtrshort{GH} (\glsxtrshort{RH}-\glsxtrshort{GH}) with the simulation engine.

The workflow involves utilizing the \glsxtrshort{HB} component \textit{HB Export To OSM} to export the developed \glsxtrshort{HB} zone into an \glsxtrshort{OSM} file. This \glsxtrshort{OSM} file is then translated into an \glsxtrshort{IDF} format and subsequently run through \glsxtrshort{EP}. The \textit{HB Export To OSM} component requires a set of inputs, which include simulation parameters, and generates various output files in different formats as part of the analysis process. The key component in modeling part are as followed.

Note that many the 4 simulations are entwined, they're processing parallelly. And some inputs are the source for plural simulations. If it is related to Energy simulation, it'll be introduced into this section.


\subsection{\glsxtrshort{HB} Opaque Material}
\label{subsec:HB Opaque Material}
Create a standard opaque material, which can be insert the information of material into the program. The data transfer flow is: 
\newline the source\ $\longrightarrow$ \textit{HB Opaque Material}\ $\longrightarrow$ \textit{HB Opaque Construction}\ $\longrightarrow$ \textit{HB Exterior Construction Subset}\ $\longrightarrow$\textit{HB Construction Set}\ $\longrightarrow$\textit{HB Room}
And also this:
\newline the source\ $\longrightarrow$ \textit{HB Opaque Modifier}\ $\longrightarrow$ \textit{HB Exterior Modifier Subset}\ $\longrightarrow$\textit{HB Modifier Set}\ $\longrightarrow$\textit{HB Room}

~\\
Then form the \textit{HB Room}, the model is applied with this modified material. Note that the construction data is basically from thermology which is for the \glsxtrshort{EP}simulation; and the modifier data is from optics which is for the Radiance simulation. But both data is combined within the \textit{HB Room}, so in the following process the program can directly read the construction (see \cref{subsec:HB Export to OSM}) and modifier (see \cref{subsec:HB Annual Daylight})data from \textit{HB object}.

For the source, we can use a \textit{TT toolbox} to read a excel document. However, here in the figure for the integrity we use display the number on the \glsxtrshort{GH} canvas(see \cref{fig:OpaqueMat}). And the detailed instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.



\begin{figure}[h]
    \centering
 	\centering
	\includegraphics[width=\linewidth]{images/Component/OpaqueMat.png}
	\caption{HB Opaque Material in application}
	\label{fig:OpaqueMat}
    \hfill
\end{figure}




\paragraph{Inputs Parameters:}
\begin{itemize}
\setlength{\itemsep}{1pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
    \item \texttt{\_name\_ (Generic Data):} Text to set the name for the material and to be incorporated into a unique material identifier.
    \item \texttt{\_thickness (Generic Data):} Number for the thickness of the material layer [m].
    \item \texttt{\_conductivity (Generic Data):} Number for the thermal conductivity of the material [W/m-K].
    \item \texttt{\_density (Generic Data):} Number for the density of the material [kg/m3].
    \item \texttt{\_spec\_heat (Generic Data):} Number for the specific heat of the material [J/kg-K].
    \item \texttt{\_roughness\_ (Generic Data):} Text describing the relative roughness of the material. Must be one of the following: 'VeryRough', 'Rough', 'MediumRough', 'MediumSmooth', 'Smooth', 'VerySmooth' (Default: 'MediumRough').
    \item \texttt{\_therm\_absp\_ (Generic Data):} A number between 0 and 1 for the fraction of incident long wavelength radiation that is absorbed by the material (Default: 0.9).
    \item \texttt{\_sol\_absp\_ (Generic Data):} A number between 0 and 1 for the fraction of incident solar radiation absorbed by the material (Default: 0.7).
    \item \texttt{\_vis\_absp\_ (Generic Data):} A number between 0 and 1 for the fraction of incident visible wavelength radiation absorbed by the material. Default value is the same as the \_sol\_absp\_.
  \end{itemize}

\paragraph{Output Parameters:}
\begin{itemize}
    \item mat (Generic Data): A standard opaque material that can be assigned to a \glsxtrshort{HB} Opaque construction.
  \end{itemize}


\subsection{HB Weekly Schedule}
\label{subsec:HB Weekly Schedule}

This is the most commonly used component to create a schedule (see \cref{fig:HB Weekly Schedule}). This is the most representative one, also the \textit{HB Constant Schedule, \glsxtrshort{HB} Seasonal Schedule} are being used in the program. The schedules support 2 simulations in the end, the energy performance and the lighting one.
The first data flow transfer:
\newline \textit{HB Weekly Schedule}\ $\longrightarrow$ \textit{HB Ventilation, \glsxtrshort{HB} Setpoint} and \textit{HB People}\ $\longrightarrow$ \textit{HB Program Type}\ $\longrightarrow$\textit{HB Room}\ from here the setting is applied to the\glsxtrshort{HB} model.
The second data flow transfer:
\newline \textit{HB Weekly Schedule}\ $\longrightarrow$ \textit{HB Annual Daylight} Which directly inserted into the daylight simulation.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/HB_Sch.png}
	\caption{HB Weekly Schedule}
	\label{fig:HB Weekly Schedule}
    \hfill
\end{figure}

The inputs of this component are straightforward. Only the limit type should be paid attention to, which is a text string from the identifier of the ScheduleTypeLimit to be looked up in the schedule type limit library. This can also be a custom ScheduleTypeLimit object from the "HB Type Limit" component. The input here will be used to validate schedule values against upper/lower limits and assign units to the schedule values. Default: "Fractional" for values that range continuously between 0 and 1. Choose from the following built-in options: 
\begin{itemize}
\setlength{\itemsep}{1pt}
\setlength{\parskip}{0pt}
\setlength{\parsep}{0pt}
    \item Fractional
    \item On-Off
    \item Temperature
    \item Activity Level
    \item Power
    \item Humidity
    \item Angle
    \item Delta Temperature
    \item Control Level
\end{itemize}
And the detailed instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.

\paragraph{Output Parameters:}
\begin{itemize}
    \item \texttt{schedule (Generic Data):} A ScheduleRuleset object that can be assigned to a Room, a Load object, or a ProgramType object.
    \item \texttt{idf\_year (Generic Data):} Text string for the EnergyPlus ScheduleYear that will ultimately be written into the \glsxtrshort{IDF} for simulation. This can also be used to add the schedule to the schedule library that is loaded up upon the start of \glsxtrshort{HB} by copying this text into the honeybee/library/schedules/user\_library.idf file along with the other idf text outputs.
    \item \texttt{idf\_week (Generic Data):} Similar to the idf\_year.
    \item \texttt{idf\_days (Generic Data):} Similar to the idf\_year
\end{itemize}

\subsection{HB Face}
\label{subsec:HB Face}
This is for us to define the interface where the thermal transmittance happen, with which the\glsxtrshort{HB} Room can be enclosed.
From architectural aspect, it define the floor, roof and wall. See \ref{fig:HB Room}. And the detailed instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.

\paragraph{Input Parameters:}
\begin{itemize}
\item \texttt{\_geo (Generic Data):} \glsxtrshort{RH} Brep or Mesh geometry.
\item \texttt{\_name\_ (Generic Data):} Text to set the name for the Face and to be incorporated into a unique Face identifier. If the name is not provided, a random name will be assigned.
\item \texttt{\_type\_ (Generic Data):} Text for the face type. The face type will be used to set the material and construction for the surface if they are not assigned through the inputs below. The default is automatically set based on the normal direction of the Face (up being RoofCeiling, down being Floor, and vertically-oriented being Wall). Choose from the following:
\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
\item Wall
\item RoofCeiling
\item Floor
\item AirBoundary
  \end{itemize}
\item \texttt{\_bc\_ (Generic Data):} Text for the boundary condition of the face. The boundary condition is also used to assign default materials and constructions, as well as the nature of heat exchange across the face in energy simulation. Default is Outdoors unless all vertices of the geometry lie below the XY plane, in which case it will be set to Ground. Choose from the following:
\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
\item Outdoors
\item Ground
\item Adiabatic
    \end{itemize}
\item \texttt{ep\_constr\_ (Generic Data):} Optional text for the Face's energy construction to be looked up in the construction library. This can also be a custom OpaqueConstruction object. If no energy construction is input here, the face type and boundary condition will be used to assign a default.
\item \texttt{rad\_mod\_ (Generic Data):} Optional text for the Face's radiance modifier to be looked up in the modifier library. This can also be a custom modifier object. If no radiance modifier is input here, the face type and boundary condition will be used to assign a default.
\end{itemize}

\paragraph{Output Parameters:}
\begin{itemize}
\item \texttt{faces (Generic Data):} \glsxtrshort{HB} surface. Use this surface directly for daylight simulation or to create a \glsxtrshort{HB} zone for Energy analysis.
\end{itemize}




\subsection{HB Room}
\label{subsec:HB Room}
Create \glsxtrshort{HB} Room from \glsxtrshort{HB} Faces. Note that each Room is mapped to a single zone in \glsxtrshort{EP}/\glsxtrshort{OS} and should always be a closed volume to ensure correct volumetric calculations and avoid light leaks in Radiance simulations. To define a room (see \cref{fig:HB Room}), we need information applied to the model, which come from 3 aspects:

\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
\item \texttt{Geometrical data:} comes from the \textit{HB face}, see \cref{subsec:HB Face}
\item \texttt{Physical data:} comes from the \textit{HB Construction Set} and similarly the \textit{HB Modifier Set}, see \cref{subsec:HB Opaque Material}
\item \texttt{Operative data:} comes from the \textit{HB Program Type}, see \cref{subsec:HB Weekly Schedule}.
    \end{itemize}
So that the\glsxtrshort{HB} Room is built up, which is the unitary object to put in to the energy performance study (see \cref{sec:Energy simulation}). We can read the result for each room, distinguishing them by the name. So it's the core in the modeling part and worth diving into its i/o. Instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/HB_Room.png}
	\caption{HB Room}
	\label{fig:HB Room}
    \hfill
\end{figure}

\paragraph{Input Parameters:}
\begin{itemize}
    \item \texttt{\_faces (Generic Data):} A list of \glsxtrshort{HB} Faces to be joined together into a Room.
    \item \texttt{\_name\_ (Generic Data):} Text of Room identifier. 
    \item \texttt{\_mod\_set\_ (Generic Data):} Just as the below.
    \item \texttt{\_constr\_set\_ (Generic Data):} Text for the construction set of the Room, which is used to assign all default energy constructions needed to create an energy model. Text should refer to a ConstructionSet within the library, such as that output from the "HB List Construction Sets" component. This can also be a custom ConstructionSet object. If nothing is input here, the Room will have a generic construction set that is not sensitive to the Room's climate or building energy code.
    \item \texttt{\_program\_ (Generic Data):} Text for the program of the Room (to be looked up in the ProgramType library) such as that output from the "HB List Programs" component. This can also be a custom ProgramType object. If no program is input here, the Room will have a generic office program. Note that ProgramTypes effectively map to \glsxtrshort{OS} space types upon export to \glsxtrshort{OS}.
    \item \texttt{\_conditioned\_ (Generic Data):} Boolean to note whether the Room has a heating and cooling system.
\end{itemize}

\paragraph{Output Parameters:}
\begin{itemize}
    \item \texttt{room (Generic Data):} \glsxtrshort{HB} room. These can be used directly in energy and radiance simulations.
\end{itemize}

\section{Energy simulation}
\label{sec:Energy simulation}

\glsxtrshort{HB} creates, runs, and visualizes daylight simulations using Radiance and energy models using \glsxtrshort{OS} and \glsxtrshort{EP}\cite{PollinationHB}. So here in this section, we mainly introduce the core of \glsxtrshort{HB} Energy. As we can see in \cref{fig:HB class}, the \glsxtrshort{HB} energy components are put into 9 categories. We can see \textit{0::Basic Properties} in \cref{fig:GH section A}, also the Opaque Material (in \cref{subsec:HB Opaque Material}) can represent \textit{1::Construction}, while the weekly schedule (in \cref{subsec:HB Weekly Schedule}) making example for \textit{2::Schedules}, and \textit{HB People} in \cref{fig:HB Weekly Schedule} symbolizing the \textit{3::Loads}. In this section, we focus on \textit{4::\glsxtrshort{HVAC}} and \textit{5::Simulation}, taking \textit{HB All-Air \glsxtrshort{HVAC}, \glsxtrshort{HB} Model to \glsxtrshort{OSM} } as examples.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/HB_Class.png}
	\caption{HB component classification}
	\label{fig:HB class}
    \hfill
\end{figure}



\subsection{Weather file}
\label{Weather file}
an \glsxtrshort{EPW} file imported to \glsxtrshort{GH} via \textit{LB Import \glsxtrshort{EPW}}.

\subsection{Analysis period}
\label{Analysis period}
an optional analysis period can be set using the corresponding \glsxtrshort{LB} component. ``In this case, no analysis period is specified, so that simulation is run for the entire year. But the for the setpoint, the cooling and heating are restricted to the half year.''\cite[41]{rhino-gh}

\subsection{HB All-Air \glsxtrshort{HVAC}}
\label{subsec:HB All-Air HVAC}

Apply an All-Air template \glsxtrshort{HVAC} to a list of \glsxtrshort{HB} Rooms. All-air systems provide both ventilation and satisfaction of heating + cooling demand with the same stream of warm/cool air. They often grant tight control over zone humidity. However, because such systems often involve the cooling of air only to reheat it again, they are often more energy-intensive than systems that separate ventilation from meeting thermal loads. The context and detail is presented in \cref{fig:HB HVAC}. And the detailed instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/HVAC.png}
	\caption{HB \glsxtrshort{HVAC}}
	\label{fig:HB HVAC}
    \hfill
\end{figure}

\subsubsection{Input Parameters:}
\begin{itemize}
    \item \texttt{\_rooms (Generic Data):} \glsxtrshort{HB} Rooms to which the input template \glsxtrshort{HVAC} will be assigned. This can also be a \glsxtrshort{HB} Model for which all conditioned Rooms will be assigned the \glsxtrshort{HVAC} system.
    \item \texttt{\_system\_type (Generic Data):} Text for the specific type of all-air system and equipment. The "HB All-Air \glsxtrshort{HVAC} Templates" component has a full list of the supported all-air system templates.
    \item \texttt{\_vintage\_ (Generic Data):} Text for the vintage of the template system. This will be used to set efficiencies for various pieces of equipment within the system. The "HB Building Vintages" component has a full list of supported \glsxtrshort{HVAC} vintages. (Default: \glsxtrshort{ASHRAE}\_2019).
    \item \texttt{\_name\_ (Generic Data):} Text of \glsxtrshort{HVAC} identifier. 
    \item \texttt{\_economizer\_ (Generic Data):} Text to indicate the type of air-side economizer used on the \glsxtrshort{HVAC} system. Economizers will mix in a greater amount of outdoor air to cool the zone (rather than running the cooling system) when the zone needs cooling and the outdoor air is cooler than the zone. Choose from the options below. (Default: NoEconomizer).
        \begin{itemize}
         \setlength{\itemsep}{1pt}
         \setlength{\parskip}{0pt}
         \setlength{\parsep}{0pt}
            \item NoEconomizer
            \item DifferentialDryBulb
            \item DifferentialEnthalpy
            \item DifferentialDryBulbAndEnthalpy
            \item FixedDryBulb
            \item FixedEnthalpy
            \item ElectronicEnthalpy
        \end{itemize}
    \item \texttt{sensible\_hr\_ (Generic Data):} A number between 0 and 1 for the effectiveness of sensible heat recovery within the system. Typical values range from 0.5 for simple glycol loops to 0.81 for enthalpy wheels (the latter tends to be fairly expensive for air-based systems). (Default: 0).
    \item \texttt{latent\_hr\_ (Generic Data):} A number between 0 and 1 for the effectiveness of latent heat recovery within the system. Typical values are 0 for all types of heat recovery except enthalpy wheels, which can have values as high as 0.76. (Default: 0).
    \item \texttt{dcv\_ (Generic Data):} Boolean to note whether demand-controlled ventilation should be used on the system, which will vary the amount of ventilation air according to the occupancy schedule of the zone. (Default: False).
\end{itemize}

\subsubsection{Output Parameters:}
\begin{itemize}
    \item \texttt{report} (Generic Data): Reports, errors, warnings, etc.
    \item \texttt{rooms} (Generic Data): The input Rooms with an all-air \glsxtrshort{HVAC} system applied.
\end{itemize}






\subsection{HB Ventilation Control}
\label{subsec:HB Ventilation Control}

Create a Ventilation Control object to dictate the temperature setpoints and schedule for ventilative cooling (e.g., opening windows). Note that all the default setpoints of this object are set to always perform ventilative cooling, allowing individual decisions on which setpoints are relevant to a given ventilation strategy.
Here's the data transfer:
\newline Base schedule or input schedule $\longrightarrow$ \textit{HB Ventilation Control} with its settings $\longrightarrow$ \textit{HB Window Opening}\ $\longrightarrow$\textit{HB Model}\ $\longrightarrow$ \textit{HB Export to OSM} then the \glsxtrshort{OS} receives the data, also see in \cref{fig:HB VentiCtrl}. And the detailed instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/VentiCtrl.png}
	\caption{HB Ventilation Control}
	\label{fig:HB VentiCtrl}
    \hfill
\end{figure}

\subsubsection*{Input Parameters:}
\begin{itemize}
    \item \texttt{min\_in\_temp\_(Generic Data):} A number between -100 and 100 for the minimum indoor temperature at which to ventilate in Celsius. Typically, this variable is used to initiate ventilation with values around room temperature above which the windows will open (e.g., 22°C). (Default: -100°C).
    
    \item \texttt{max\_in\_temp\_(Generic Data):} A number between -100 and 100 for the maximum indoor temperature at which to ventilate in Celsius. This can be used to set a maximum temperature at which point ventilation is stopped and a cooling system is turned on. (Default: 100°C).
    
    \item \texttt{min\_out\_temp\_(Generic Data):} A number between -100 and 100 for the minimum outdoor temperature at which to ventilate in Celsius. This can be used to ensure ventilative cooling doesn't happen during the winter even if the Room is above the min\_in\_temp. (Default: -100°C).
    
    \item \texttt{max\_out\_temp\_(Generic Data):} A number between -100 and 100 for the maximum outdoor temperature at which to ventilate in Celsius. This can be used to set a limit for when it is considered too hot outside for ventilative cooling. (Default: 100°C).
    
    \item \texttt{delta\_temp\_(Generic Data):} A number between -100 and 100 for the temperature differential in Celsius between indoor and outdoor below which ventilation is shut off. This should usually be a positive number so that ventilation only occurs when the outdoors is cooler than the indoors. Negative numbers indicate how much hotter the outdoors can be than the indoors before ventilation is stopped. (Default: -100°C).
    
    \item \texttt{\_schedule\_(Generic Data):} An optional schedule for the ventilation over the course of the year. This can also be the name of a schedule to be looked up in the standards library. Note that this is applied on top of any setpoints. The type of this schedule should be On/Off, and values should be either 0 (no possibility of ventilation) or 1 (ventilation possible). (Default: "Always On").
\end{itemize}

\subsubsection*{Output Parameters:}
\texttt{vent\_cntrl\_(Generic Data):} HBZones with their airflow modified.

The math logic of this component can be translate in to the formula, for every specific moment \textit{j}, there are:
\begin{equation}
    \label{eq:Delta_T}
\RaggedRight
\Delta_{T}(j) = T_{i}(j) - T_{o}(j)
\end{equation}

\begin{equation}
    \label{eq:Condition_D}
\RaggedRight
D(j) = 
\begin{cases}
      1, & \text{if}\ \Delta_{T}(j) > \Delta_{t}\\
      0, & \text{otherwise}
    \end{cases}
\end{equation}

\begin{equation}
    \label{eq:Condition_In}
\RaggedRight
I(j) =     
\begin{cases}
      1, & \text{if}\ T_{i}(j)\in [\ min\_in\_temp,\ max\_in\_temp \ ] \\
      0, & \text{otherwise}
    \end{cases}
\end{equation}

\begin{equation}
    \label{eq:Condition_Out}
\RaggedRight
O(j) =     
\begin{cases}
      1, & \text{if}\ T_{o}(j)\in [\ min\_out\_temp,\ max\_out\_temp \ ] \\
      0, & \text{otherwise}
    \end{cases}
\end{equation}

where:
\begin{conditions}
\Delta_{T}(j)      &  the temperature difference at moment \textit{j} \\
\Delta_{t}       &   the component input "  \textit{delta\_temp}" \\
 T_{i}(j)    &  the indoor temperature at moment \textit{j}\\   
 T_{o}(j)    &  the outdoor temperature at moment \textit{j} \\
 D(j)    & the differential condition at moment \textit{j} \\
 I(j)        & the indoor condition at moment \textit{j} \\
 O(j)    & the indoor condition at moment \textit{j} \\

\end{conditions}

Note: \textit{min\_in\_temp, max\_in\_temp, min\_out\_temp, max\_out\_temp} are from the component's input.

~\\
And also with the \textbf{S}, the schedule condition defined by the input with the same name. E.g. there are 8760 hours of the year, conventionally, we define a schedule with 8760 boolean numbers. Then for every specific moment \textit{j}, there is \textbf{S(j)}. Based on these boolean numbers, we apply the \textit{HB Ventilation Control} calculation. From S(j), the new schedule can be written as:
\begin{equation}
    \label{eq:VTctrl}
\RaggedRight
VT_{ctrl}(j)=S(j)\cdot D(j)\cdot I(j)\cdot O(j)
\end{equation}
Notice that, the $\Delta_{t}$ i.e. the input parameter \textit{delta\_temp}, is one of the \textbf{Genomes} to be optimized. It subsequently effects on the D(j), and then effects the natural ventilation control, which eventually plays a role in the summer simulation.



\subsection{HB Export to OSM}
\label{subsec:HB Export to OSM}

Write a \glsxtrshort{HB} Model to an \glsxtrshort{OSM} file, which can then be translated to an \glsxtrshort{IDF} file and run through \glsxtrshort{EP}.
As we can see, it often run along with \textit{HB Simulation Output,\glsxtrshort{HB} Simulation Parameter} in \cref{fig:HB ExportToOSM}. This is the core component, it transfer to the \glsxtrshort{OS} per se. In addition, some commonly used setups is packaged into \textit{HB Simulation Output,\glsxtrshort{HB} Simulation Parameter}. On the other hand, the deeper interation with \glsxtrshort{EP}should employ the input of \textit{add\_str\_}, which is the as the command line interface work as \glsxtrshort{EP}itself. And the detailed instruction following is quoted from HB-Energy primer\cite{HB_Energy_Primer}.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/ExportToOSM.png}
	\caption{HB Export to OSM}
	\label{fig:HB ExportToOSM}
    \hfill
\end{figure}


\subsubsection*{Input Parameters:}
\begin{itemize}
    \item \texttt{\_model\_(Generic Data):} A \glsxtrshort{HB} model object possessing all geometry and corresponding energy simulation properties.
    
    \item \texttt{\_epw\_file\_(Generic Data):} Path to an .epw file on this computer as a text string.
    
    \item \texttt{\_sim\_par\_(Generic Data):} A \glsxtrshort{HB} Energy SimulationParameter object that describes all of the settings for the simulation. If None, some default simulation parameters will automatically be used.
    
    \item \texttt{measures\_(Generic Data):} An optional list of measures to apply to the \glsxtrshort{OS} model upon export. Use the "HB Load Measure" component to load a measure into \glsxtrshort{GH} and assign input arguments. Measures can be downloaded from the NREL Building Components Library (BCL) at \texttt{add\_str\_(Generic Data):} THIS OPTION IS JUST FOR ADVANCED USERS OF ENERGYPLUS. You can input additional text strings here that you would like written into the \glsxtrshort{IDF}. The input here should be complete \glsxtrshort{EP} objects as a single string following the \glsxtrshort{IDF} format. This input can be used to write objects into the \glsxtrshort{IDF} that are not currently supported by \glsxtrshort{HB}.
    
    \item \texttt{\_folder\_(Generic Data):} An optional folder on this computer, into which the \glsxtrshort{IDF} and result files will be written.
    
    \item \texttt{\_write\_(Generic Data):} Set to "True" to write out the \glsxtrshort{HB} JSONs (containing the \glsxtrshort{HB} Model and Simulation Parameters) and write the \glsxtrshort{OS} Workflow (.osw) file with instructions for executing the simulation.
    
    \item \texttt{run\_(Generic Data):} Set to "True" to translate the \glsxtrshort{HB} JSONs to an \glsxtrshort{OSM} (.osm) and EnergyPlus Input Data File (.idf) and then simulate the .idf in \glsxtrshort{EP}. This will ensure that all result files appear in their respective outputs from this component. This input can also be the integer "2," which will only translate the \glsxtrshort{HB} JSONs to an osm and \glsxtrshort{IDF} format without running the model through \glsxtrshort{EP}. It can also be the integer "3," which will run the whole translation and simulation silently (without any batch windows).
\end{itemize}

\subsubsection*{Output Parameters:}
\begin{itemize}
    \item \texttt{report\_(Text):} Check here to see a report of the \glsxtrshort{EP} run.
    
    \item \texttt{jsons\_(Generic Data):} The file paths to the \glsxtrshort{HB} JSON files that describe the Model and Simulation Parameter. These will be translated to an \glsxtrshort{OSM}.
    
    \item \texttt{osw\_(Generic Data):} File path to the \glsxtrshort{OS} Workflow JSON on this machine. This workflow is executed using the \glsxtrshort{OS} command line interface (CLI) and it includes measures to translate the \glsxtrshort{HB} model JSON as well as any other connected measures.
    
    \item \texttt{osm\_(Generic Data):} The file path to the \glsxtrshort{OSM} that has been generated on this computer.
    
    \item \texttt{idf\_(Generic Data):} The file path of the EnergyPlus \glsxtrshort{IDF} that has been generated on this computer.
    
    \item \texttt{sql\_(Generic Data):} The file path of the SQL result file that has been generated on this computer. This will be None unless \texttt{run\_} is set to True.
    
    \item \texttt{zsz\_(Generic Data):} Path to a .csv file containing detailed zone load information recorded over the course of the design days. This will be None unless \texttt{run\_} is set to True.
    
    \item \texttt{rdd\_(Generic Data):} The file path of the Result Data Dictionary (.rdd) file that is generated after running the file through \glsxtrshort{EP}. This file contains all possible outputs that can be requested from the EnergyPlus model. Use the "HB Read Result Dictionary" component to see what outputs can be requested.
    
    \item \texttt{html\_(Generic Data):} The HTML file path containing all requested Summary Reports.
\end{itemize}


\section{Lighting simulation}
\label{sec:Lighting simulation}

Annual daylight simulations are conducted employing the Radiance (v5.4a) engine, a freely available, highly accurate ray-tracing software system developed by the \glsxtrfull{DOE} with collaborative support from the Swiss Federal Government \cite{Radiance}. Radiance is extensively utilized by engineers and architects to anticipate and visualize daylighting distribution and assess visual comfort during the initial stages of the design process. The process involves exporting the zone to a RAD file, a text-based format that translates \glsxtrshort{HB} geometries and materials into the primary input file for Radiance. Key inputs and outputs relevant to this \glsxtrshort{HB} component are comprehensively discussed below.

~\\
In this section 3 missions are presented: \glsxtrshort{ALS} installation; Daylight simulation; Artificial lighting estimation.
Each of the a key component is introduced.

\subsection{HB Sensor Grid}
\label{subsec:HB Sensor Grid}
To build a \glsxtrshort{ALS} grid, it's better to keep the consistency of the whole workflow. So, we apply it to the\glsxtrshort{HB} model. Firstly, it's needed to deconstruct the\glsxtrshort{HB} object (which is created in \cref{sec:Model building}) via \textit{HB Visualize by Type}, which help us to extract all the horizontal faces. Secondly, based on these faces a grid is created via \textit{LB Generate Grid Point}. Lastly, we can use these points and faces to build up the \glsxtrshort{ALS} grid via \textit{HB Sensor Grid}.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/tables/SensorGrid.png}
	\caption{\glsxtrshort{ALS} grid to receive the daylight}
	\label{fig:Sensor Grid}
    \hfill
\end{figure}



\subsection{HB Annual Daylight}
\label{subsec:HB Annual Daylight}
In the \cref{fig:Annual Daylight}, we can see \textit{HB Object, Analysis Recipe} are connected to the component. This is the setting for the Radiance simulation engine. Nevertheless, before in-plugged to the component, the weather file should be translated via \textit{HB Wea From \glsxtrshort{EPW}}.
Here's the data transfer:
\newline Geometrical data is borrow from \textit{HB Object}(see \cref{sec:Model building}) via \textit{HB Visualize by Type}\ $\longrightarrow$ \textit{LB Generate Point Grid}$\longrightarrow$ \textit{HB Sensor Grid}\ $\longrightarrow$\textit{HB Assign Grids and Views}\ $\longrightarrow$ \textit{HB Get Grids and Views}\ $\longrightarrow$ \textit{HB Annual Daylight}\ $\longrightarrow$ \textit{HB Annual Results to Data}\ $\longrightarrow$ a data extractor(see \cref{Daylight estimation})\ $\longrightarrow$ the illuminance calculator(see \cref{fig:Illuminance})\ $\longrightarrow$ converted to electric consumption $\longrightarrow$ finally goes to the economic simulation sector.

\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/AnnualDaylight.png}
	\caption{HB Annual Daylight}
	\label{fig:Annual Daylight}
    \hfill
\end{figure}

\subsubsection{HB Object}
The\glsxtrshort{HB} object (which is created in \cref{sec:Model building}) is also needed, for its apertures information.

\subsubsection{Analysis recipe}
Radiance boasts diverse simulation capabilities, prompting \glsxtrshort{HB} to offer various analysis recipes for this input field. Among these options are daylight factor simulations, grid-based or image-based lighting analyses, and annual daylight simulations. For the scope of this research, the focus lies on the latter. Hence, the 'annualDaylightSimulation' recipe is constructed, utilizing the \glsxtrshort{EPW} file and creating a test points grid and mesh aligned with the zone's floor area.
\begin{itemize}
    \item \textbf{Number of CPUs:} Determine the desired number of CPUs for conducting the studies.
    \item \textbf{File name and working directory:} Define a project name and designate a directory for storing result files. Avoid using spaces in the directory name, similar to energy simulation constraints.
\end{itemize}
Daylight simulation is then initiated by setting the \texttt{writeRad} and \texttt{runRad} fields to \texttt{True}. ``Radiance requires more time (often several minutes) compared to \glsxtrshort{EP} to execute the analysis.''\cite[68]{rhino-gh}



\subsection{Daylight estimation}
\label{Daylight estimation}
Firstly, we filter the annual data, to extract the daylight data during the working hours. We use the occupancy schedule as the filter (see \cref{subsec:HB Weekly Schedule} and \cref{fig:GH section A}) via \textit{dispatch}. Then we employ the \textit{dispatch} again, to extract all the hour within the working period the daylight is insufficient to 500 lux.
\begin{figure}[h]
    \centering
	\includegraphics[width=\linewidth]{images/Component/Illuminance.png}
	\caption{Illuminance calculator}
	\label{fig:Illuminance}
    \hfill
\end{figure}

~\\
Daylight simulation is then run by setting to True the run fields.
Radiance usually takes up a longer time (several minutes) with respect to \glsxtrshort{EP}, but it can be shortened by minizing the grid numbers. However, the setting of Radiance is much more flexible and robust than the \glsxtrshort{EP}. Unlike \glsxtrshort{EP}all the faces should be well defined, if a\glsxtrshort{HB} model is only for radiance simulation, the geometry arrangement is less strict. Building a \textit{HB Modifier} is easier than \textit{HB Opaque Construction} as well. This is an example of so-called "hard for mankind, but easy for machine" issue.






\section{Economical simulation}
\label{sec:Economical simulation}
As we introduced, there're 2 kinds of costs: the initial cost and the annual cost. The initial cost refers to \cref{sec:static-design}, while the annual cost refering to \cref{sec:Operative-design} and \cref{Step IV: Operational Setting}.

Before the NPV is calculated, the 2 kinds of cost should be all prepared. And then the annual cost will be processes the NPV calculation. Lastly, the outcome will add up with the initial cost. The result is the final value, which is the \textbf{fitness value}, the goal of optimization.
\subsection{NPV calculator}
\label{NPV calculator}
The approach is based on the formula in \cref{eq:GloblalCost,eq:GloblalCost2}. The pseudocode is on \pageref{NPV calculator}:

\begin{algorithm}
	
\begin{minipage}[t]{.99\linewidth}

\caption{NPV Calculator}
\begin{algorithmic}[1]
    \Procedure{NPVL}{$\text{CashFlow\_OverTime}, \text{DiscountRate}, \text{NPV\_OverTime}$}
        \State $\text{NPV\_OT} \gets$ an empty list
        
        \For{$i \gets 0$ \textbf{to} $\text{length of } \text{CashFlow\_OverTime} - 1$}
            \State $\text{period} \gets i + 1$
            \State $D_n \gets (1 + \text{DiscountRate})^{\text{period}}$
            \State $\text{NPV\_S} \gets \text{CashFlow\_OverTime}[i] / D_n$
            \State $\text{NPV\_OT}.\text{add}(\text{NPV\_S})$
        \EndFor
        
        \State $\text{NPV\_OverTime} \gets \text{NPV\_OT}$
    \EndProcedure
\end{algorithmic}

\end{minipage}

\end{algorithm}

\section{Comfort simulation}
\label{sec:Comfort simulation}
It is suggested in the notation of the component, that different comfort assessment is used for different scenarios.
Conventionally, it follow the type of the space being assessed. Mainly there're 4 comfort metric can be selected: 
\begin{itemize}
         \setlength{\itemsep}{1pt}
         \setlength{\parskip}{0pt}
         \setlength{\parsep}{0pt}
            \item \textbf{\glsxtrshort{PMV} comfort:} mainly for the indoor space conditioned.
            \item \textbf{Adaptive comfort:} mainly for the indoor space without AC.
            \item \textbf{\glsxtrshort{UCTI} comfort:} can be used for the outdoor space.
            \item \textbf{\glsxtrshort{PET} Comfort:} estimating core body temperature and whether a given set of conditions is likely to induce hypothermia or hyperthermia in a specific individual.
\end{itemize}
Obviously, to analyse an indoor office, we choose \glsxtrshort{PMV} comfort as the method. In addition, we already consider the indoor - outdoor temperature in \cref{eq:Delta_T}. So here using the \glsxtrshort{PMV} can minimized the cross interference.

\subsection{LB PMV Comfort}
\label{LB PMV Comfort}
The methodology is introduced in \cref{subsec:Predicted Mean Vote}. The \_air\_temp, \_rel\_humid, \_mrt\_ are gained from the \textit{HB Read Room Comfort Result} after the simulation \textit{HB Export to OSM} is done. and the \_air\_speed\_ is set to $0.014 m^{3}/s.$\footnote{It should be pointed out that an air speed over 0.8 m/s could cause discomfort in orkplaces, as it tends to move office papers from the desks\cite{119}}. And it's discussed in \cref{Controlled Natural Ventilation}. And the detailed instruction following is quoted from HB-Energy primer \& Ladybug primer\cite{HB_Energy_Primer,LB_Primer}.

\subsubsection{Input Parameters:}
\begin{itemize}
    \item \textbf{\_air\_temp (Generic Data):} Data Collection or individual value for air temperature in C.
    \item \textbf{\_mrt\_ (Generic Data): Data Collection or individual value of mean radiant temperature (MRT) in C. Default is the same as the air\_temp.
    \item \textbf{\_rel\_humid (Generic Data):} Data Collection or individual value for relative humidity in \%. Note that percent values are between 0 and 100.
    \item \textbf{\_air\_speed\_ (Generic Data):} Data Collection or individual value for air speed in m/s. Default is a very low speed of 0.1 m/s, typical of room air speeds induced by \glsxtrshort{HVAC} systems.
    \item \textbf{\_met\_rate\_ (Generic Data):} Data Collection or individual value of metabolic rate in met. Default is set to 1.1 met for seated, typing. Typical values include:
    \begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}    
        \item - 1 met = Metabolic rate of a resting seated person
        \item - 1.2 met = Metabolic rate of a standing person
        \item - 2.4 met = Metabolic rate of a person walking at ~1 m/s (2 mph)
    \end{itemize}
    \item \textbf{\_clothing\_ (Generic Data):} Data Collection or individual value of clothing insulation in clo. Default is set to 0.7 clo for long sleeve shirt and pants. Typical values include:
    \begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}   
        \item - 1 clo = Three-piece suit
        \item - 0.5 clo = Shorts + T-shirt
        \item - 0 clo = No clothing
    \end{itemize}
    \item \textbf{pmv\_par\_ (Generic Data):} Optional comfort parameters from the "LB PMV Comfort Parameters" component to specify the criteria under which conditions are considered acceptable/comfortable. Default assumes a \glsxtrshort{PPD} threshold of 10\% and no absolute humidity constraints. 
    \item \textbf{\_run (Generic Data):} Set to True to run the component.
\end{itemize}

\subsubsection{Output Parameters:}
\begin{itemize}

    \item \textbf{report (Text):} Reports, errors, warnings, etc.
    \item \textbf{pmv (Generic Data):} \glsxtrlong{PMV}. \glsxtrshort{PMV} is a seven-point scale from cold (-3) to hot (+3) that was used in comfort surveys of P.O. Fanger. Each integer value of the scale indicates:
    \begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
        \item - -3 = Cold
        \item - -2 = Cool
        \item - -1 = Slightly Cool
        \item - 0 = Neutral
        \item - +1 = Slightly Warm
        \item - +2 = Warm
        \item - +3 = Hot
    \end{itemize}
       
    \item \textbf{ppd (Generic Data):} \glsxtrlong{PPD}. Indicates the percent of people who would have a \glsxtrshort{PMV} beyond acceptable thresholds (typically <-0.5 and >+0.5). Best achievable \glsxtrshort{PPD} is 5\% and most standards aim for \glsxtrshort{PPD} below 10\%.
    \item \textbf{set (Generic Data):} \glsxtrfull{SET} in Celsius, describing what the given input conditions "feel like" in relation to a standard environment.
    \item \textbf{comfort (Generic Data):} Integers noting whether the input conditions are acceptable according to the assigned comfort\_parameter. Values are:
    \begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
        \item - 0 = uncomfortable
        \item - 1 = comfortable
    \end{itemize}
        
    \item \textbf{condition (Generic Data):} Integers noting the thermal status of a subject according to the assigned comfort\_parameter. Values are:
    \begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}       
        \item - -2 = too dry (but thermally neutral)
        \item - -1 = cold
        \item - 0 = neutral
        \item - +1 = hot
        \item - +2 = too humid (but thermally neutral)
    \end{itemize}
    \item \textbf{heat\_loss (Generic Data):} A list of 6 terms for heat loss from the human energy balance calculation underlying \glsxtrshort{PMV}. Values are in W. Terms are ordered as follows: Conduction, Sweating, Latent Respiration, Dry Respiration, Radiation, Convection.
    \item \textbf{comf\_obj (Generic Data):} A Python object containing all inputs and results of the analysis. Can be used in components like the "Comfort Statistics" component to obtain further information.
\end{itemize}



\section{Optimization}
\label{sec:Optimization}

The optimization aims to identify optimal configurations among a defined set of parametric, independent design variables that ensure satisfactory levels of occupants' thermal and visual comfort without mechanical conditioning. This iterative process facilitates the exploration of a broad spectrum of potential design solutions, shedding light on both optimal and sub-optimal choices in construction and their impact on overall building performance. Given the multifaceted and often conflicting nature of factors influencing cost or \glsxtrshort{EUI} performance, addressing this as a multi-objective complex problem necessitates the utilization of Octopus, a Genetic Algorithm (GA)-based evolutionary simulator.

Octopus, employing the \glsxtrshort{SPEA2} combined with the  \glsxtrshort{HypE} algorithm, enables the concurrent optimization of multiple parameters \cite{129}. Its maturity appeals to many researchers to run their optimization on it.

~\\
Wallacei is catching up with Otcopus these day. Using \glsxtrshort{NSGA2} as the core, it benefits the researcher especially on the result analytic and expression. On the other hand, it also performs effectively in the optimization process. The search for optimal solutions encompasses balancing various objectives simultaneously. Thus, the most favorable solutions are those capable of reconciling the optimality of all considered objectives. This section delves into the theoretical foundation governing Wallacei' operations, detailing the chosen simulation parameters and objectives, and outlining the criteria for identifying optimal solutions.

\subsection{Wallacei X}
\label{Wallacei X}


\begin{figure}[h]
\label{fig:Wallacei X}
    \centering
    \includegraphics[width=\linewidth]{images/Component/WallaceiX.png}
    \caption[Wallacei X Component]{Wallacei X Component\protect\footnotemark}
\end{figure}
\footnotetext{If we name the gene or phenotype beginning with "wlc\_"  then the component can automatically select all the sliders and objectives via rightclick or Gene Pool and Slider Shuffler component.}



The Wallacei solver component, depicted in \cref{fig:Wallacei X} here aside, is utilized for optimization tasks. We can find the introduction and tutorials of it in \cite{WALLACEI_L}. Genetic information should be connected to the Genes field, while the Objectives field gathers the objectives of the simulation (fitness), with a minimum of two objectives. Both numerical and text parameters, representing the values and names of the objectives, can be input here. It is advisable to organize these elements into two separate lists: one for numerical values and the other for objective names. Optionally, ``a 3D mesh can be linked to Wallacei, defining the phenotype (P) and allowing visual assessment of the solutions'' \cite{Octopus_plug-in_manual}. ``Variations of the phenotype are compiled into a tree and outputted by the Wallacei component (Ps).''\cite[59]{rhino-gh} In this particular case, no mesh is included to prevent overloading the simulation. Here provides a list of the variables and objectives considered for the analysis developed.

Eight parameters are chosen to construct the genome: 
\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item Thickness of Insulation for Walls
    \item Thickness of Insulation for Roof
    \item Thickness of Insulation for Floor
    \item Glazing Type
    \item Louvers Count
    \item Window-to-Wall Ratio for South Facade (WWR\_S)
    \item Window-to-Wall Ratio for North Facade (WWR\_N)
    \item Delta Temperature
\end{itemize}
The fitness values:
\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item \glsxtrfull{PPD}
    \item \glsxtrfull{EUI}
    \item Cost
\end{itemize}

\subsection{Wallacei section}
\label{Wallacei section}
\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/Component/WallaceiSetting_0.png}
    \caption{Sections of Wallacei X}
    \label{fig:Wallacei section}
\end{figure}

In the \cref{fig:Wallacei section}
\begin{itemize}
    \item \textbf{Primary Buttons:}
    \begin{itemize}
        \item \textbf{Snap:} Takes a screen-shot of your screen and saves it to the desktop. It is recommended you maximise the user interface window before taking a screen shot for best results.
        \item \textbf{Start:} Clears any existing data in the solver and starts a new simulation. When the simulation finishes, a popup window is displayed informing the user that the simulation is complete.
        \item \textbf{Stop:} Stops the simulation. When clicked, a popup window is displayed informing the user that the simulation has been aborted.
        \item \textbf{Reset:} Clears any data stored in the solver and resets the simulation settings to the default values.
    \end{itemize}
    
    \item \textbf{Control Panel:}
    \begin{itemize}
        \item \textbf{Population:} Set the generation size (how many individuals per generation) and generation count (how many generations in the simulation) for your simulation.
        \item \textbf{Algorithm Parameters:}
        \begin{itemize}
            \item \textbf{Crossover Probability (0.0 to 1.0):} Percentage of solutions in the generation that will reproduce for the next generation.
            \item \textbf{Mutation Probability (0.0 to 1.0):} Percentage of mutations taking place in the generation.
            \item \textbf{Crossover and Mutation Distribution Index (0 to 100):} A large distribution index value gives a higher probability for creating offspring near parent solutions and a small distribution index value allows distant solutions to be selected as children solutions.
        \end{itemize}
        \item \textbf{Dynamic Graphs Preferences:}
        \begin{itemize}
            \item Toggle to allow Wallacei to draw different graphs live as the simulation is running.
        \end{itemize}
        \item \textbf{Autosave:}
        \begin{itemize}
            \item If Toggled, Wallacei will autosave the \glsxtrshort{GH} definition at the end of each generation evolved in the simulation.
        \end{itemize}
        \item \textbf{\glsxtrshort{SD} Charts:}
        \begin{itemize}
            \item Dynamically draws the Standard Deviation chart for each fitness objective independently.
        \end{itemize}
        \item \textbf{Objective Space:}
        \begin{itemize}
            \item Dynamically draws the objective space for each generation in the simulation, representing up to 6 dimensions.
        \end{itemize}
        \item \textbf{Objective Space - Draw entire population/Latest Generation:}
        \begin{itemize}
            \item Once the simulation is complete, this button becomes enabled allowing the user to display the objective space for all solutions or the last generation in the population.
        \end{itemize}
        \item \textbf{Parallel Coordinate Plot:}
        \begin{itemize}
            \item Dynamically draws the parallel coordinate plot for the simulation, reducing simulation runtime by drawing for the first and latest generation.
        \end{itemize}
    \end{itemize}
\end{itemize}

The Wallacei X is a strong component, not only the optimization can be conducted on it, also it can function as a observer to the data, using its analytic function. In \cref{fig:MachineL_Axon,fig:MachineL_Top} we can see the Pareto fronts' distribution in the Wallacei interface. Nevertheless, such these graphics can be generated outside the Wallacei interface, just using the Wallacei analytic component set. So that, the graphic is created in the format of \glsxtrshort{GH} geometry, which benefit us of the interaction of other \glsxtrshort{RH} functionality. We can see more examples in \cref{sec:Visualization}.


\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/WallaceiX/MachineL_Top.png}
    \caption[Clusters using Hierarchical of the Pareto fronts in the optimization of Torino]{Clusters using Hierarchical (complete linkage) of the Pareto fronts in the optimization of Torino. Cluster 2 and 3 show that many solutions are urged to crowd into the low cost field. It's a very common strategy we can detect in nearly every city's optimization. \protect\footnotemark}
    \label{fig:MachineL_Top}
\end{figure}
\footnotetext{This strategy we name it "cheap is the key", see the example in \cref{subsec:OsloStrategy}}

\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/WallaceiX/MachineL_Axon.png}
    \caption[Clusters using K-means of the Pareto fronts in the optimization of Torino]{Clusters using K-means of the Pareto fronts in the optimization of Torino. In the figure cluster 2 and 3 are the preferred solution. We can also see that in the low cost field(close to Z-axis) those solution share a distinctive bloodline, and the sharing a worse diversity. \protect\footnotemark}
    \label{fig:MachineL_Axon}
\end{figure}
\footnotetext{This figure indicated the heritage relationship of the referring solutions. Here it presents the heritage linkage of all the Pareto front. And we can complete bloodline in \cref{fig:Dendrogram}.}





\section{Visualization}
\label{sec:Visualization}
To visualize the data is to analyse it. And before analysing the result data, we'd better to arrange them and visualized them. In this section, we visualized the data into graphic and matrix, as it's done, some heretical patterns and survival strategies reveal. 

\subsection{Objective Space}
\label{subsec:Objective Space}
In \cref{fig:ObjectiveSpace_In}, all the solution are placed in a 3 dimensional space, and all the Pareto fronts are marked.
However, all the points are stacked together.
\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/WallaceiX/ObjectiveSpace_In.png}
    \caption{Objective space in the Wallacei interface of the Pareto fronts in the optimization of Torino}
    \label{fig:ObjectiveSpace_In}
\end{figure}

So in order to have a better view of the objective space, we developed a process to export the objective space via \textit{Wallacei Analytics\_Objective Space}. Note that this component can also generate the graphic with the fitness value from Octopus, and because of that, before inputting the fitness value an additional step should be applied, i.e.\textit{Wallacei Analytics\_Extract Octopus Text Files} for the Octopus data, and \textit{Wallacei Analytics\_Order FVs From WallaceiX} for the wallacei data.

\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/WallaceiX/ObjectiveSpace_Axon.png}
    \caption[OS presenting in \glsxtrshort{RH} Axonmetric]{Axonmetric objective space presenting in \glsxtrshort{RH} of all the solution in the optimization of Torino. The Delaunay mesh are created from \glsxtrshort{Gen}99. The blue balls the selected solutions from \glsxtrshort{Gen}99}
    \label{fig:ObjectiveSpace_Axon}
\end{figure}

\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/WallaceiX/ObjectiveSpace_Front.png}
    \caption[Objective space presenting in \glsxtrshort{RH} from front]{Front objective space presenting in \glsxtrshort{RH} of all the solution in the optimization of Torino. The greener the graphic is colored the denser the solutions are crowded in space.}
    \label{fig:ObjectiveSpace_Front}
\end{figure}

Exported to the \glsxtrshort{GH} environment, the perspective and the scale can be adjusted and calculated parametrically. In the optimization of Torino, in fact, only 440 unique solutions are generated. Meaning that up to 1500 solutions are the exact copies of the 440, sharing exactly the same genotypes. This is because for these fitness value, these genes are really competitive that survive to the end, all the solutions are just permutations and combinations from the same gene pool, and the same combination just shows up across generations, where the \textbf{Crowding distance computation} (introduced in \cref{subsec:Non-dominated Sorting Genetic Algorithm II}) isn't functioning expectedly. This is a shortage of our method, a small generation size limit the crowding distance computation performance, also over simplifying the Delaunay mesh in \cref{fig:ObjectiveSpace_Axon}. However, our method ensure the convergence become effective fully. Generally speaking, our method focus on quality rather than diversity over all the solutions.

\subsection{The Matrix}
The method to create the matrix is introduced \cref{subsec:Visualisation}. In this section, the content of the matrix will be in-lighted. 


\begin{figure}[h]
    \centering
    \includegraphics[width=\linewidth]{images/tables/Explaination.png}
    \caption[chromosome matrix introduction]{chromosome matrix introduction. The content of the matrix are the data displayed from Torino Optimization, generation 50.}
    \label{fig:chromosome matrix introduction}
\end{figure}

The idea of the method to present the chromosome of \cref{fig:chromosome matrix introduction}, comes from process of decoding and re-entwined of the \glsxtrshort{DNA} molecular and in-lighted by the \textit{Genomic Visualization}(Wallacei component) \footnote{The method is adaptive. Both the display color and scale can be modified. However, the objects to displayed are limited. Individuals of all the generations are exported in the same time. And it's hard for us to observe the variation generation by generation.}. The matrix is divided into 2 parts, where the left one is the field of genotypes, and the right is the field of phenotypes. The genetype, also known as, genomes are all the parameters that the program used to produce the digital model, and it's read via \textit{Decode Genome}(Wallacei component). So far it's modelling after the \textit{Genomic Visualization} method. And we add more information to it in the following process.

~\\
The first field on the right, is the the displaying of the phenotypes, which are the performances of the digital model. Among them, the key performances are \textbf{Fitness values} which are colored into green tones. Additionally, the darker color indicates this datum is closer to the optimal, while the paler one indicates worse performances.

In second field on the right, the grey colors are the groups of \glsxtrshort{EUI}. They're the subdivided usage numbers inside the \textit{TotEnergyConsumption}, showing more details from the energy consuming conditions. Similarly, the darker color indicates this datum is closer to the optimal and vise versa. All the values here and the equipment, lighting consumption, consist the \textit{TotEnergyConsumption} \footnote{Conventionally, this value consider the lighting as well. Since the \glsxtrshort{LEUI} is calculated aside, here the consumption is double added. But the lighting simulation of \glsxtrshort{HB} room isn't optimized, which mean it stays a constant value, making no harm to the final results of the optimization}.

The third field on the right are two columns of \glsxtrfull{cDA}. Obviously, the \glsxtrshort{cDA} are mainly influenced by the WWR of each directions. In some specific color range, a mirroring projection is observed.

Lastly, it's important to notice that the digital models can be measured in many ways. In addition to the \textbf{Fitness values}, there are hundreds of performances can be quantified. The phenotype matrix here is to present the key performance indicators, which help us to understand and compare the solutions.

\subsection{Pareto front mark}
\label{subsec:Pareto front mark}
Also in the \cref{fig:chromosome matrix introduction},between the 2 matrix there is a empty column for the Pareto front marks. If the \textit{gene-like mark} is put in the middle of a row, it means its representing individual is one of the Pareto front solutions. Notice that, only the firstly appeared combination of the genes is the Pareto front, will be mark with the icon. Even though the upcoming genotypes might have the same combination due to the genetic mechanism, they won't be marked. So that means each mark represents a single unique isolated Pareto front. As mentioned in \cref{subsec:Objective Space}, 440 unique solutions are provided where 146 of them are Pareto fronts.

~\\
Having completed the visualization process, the human can scan quickly the matrix to obtain the general understanding of the individuals. Then the human designers can select some solutions as the references in the early design stage. If more time is available, an analysis process can be conduct in order to know how the strategy wins out to the end.
~\\
"From designing to choosing" that is our ultimate goal. Among so many solutions provided in the late generations. How do we select? The Pareto front is one of the criterion. And it's a rational criteria.

\subsection{Selection criteria}
\label{subsec:Selection criteria}

\subsubsection{Primary selection}
Upon completion of the optimization process, solutions are compared to identify the optimal configuration of genes that best meets the objectives. ``In multi-objective optimization, a good set of solutions typically clusters near or aligns along the approximated Pareto front generated by the software. Named after Vilfredo Pareto, who first used this concept in his studies at the turn of the 19th and 20th centuries, Pareto front (or Pareto set) is described as `the set of non-dominated solutions, where each objective is considered as equally good'\cite{133}.''\cite[62]{rhino-gh}. It is represented by a geometric entity that could be either bidimensional or three-dimensional, depending on the number of fitness values considered. Non-dominated solutions, also called Pareto optimal or Pareto efficient, are those individuals for which "an optimal trade-off between two or more contradicting objectives" is achieved, and no change in the genes can lead to an improvement in some of the objectives' results without degrading the others \cite[p.~16]{132}. In contrast, dominated solutions are named because there is always a solution that is better than them in terms of goals values. The Pareto front concept is really helpful, as it allows the designers to restrict their attention to the set of solutions that are really optimal, rather than analyze every individual in search of the best ones.
Generally speaking, the first selection is based on the Pareto fronts.

~\\
\subsubsection{Secondary selection}

Not all Pareto-efficient solutions are deemed optimal for the design intent. So on top of the primary selection, the secondary ones are applied. As depicted in \cref{fig:ObjectiveSpace_Axon}, these solutions demonstrate a broad distribution in the 3D cubeview diagram, encompassing extremes in data. ``However, it is plausible that multiple optimal solutions exist within this context; the determination of the "best" one among them is the designer's prerogative. Optimal design solutions are often situated closer to the center of the graph, near the origin of the three Cartesian axes.''\cite[63]{rhino-gh} \cref{fig:ObjectiveSpace_Front} reveals that within the circle of optimal solutions. Indeed, as highlighted in \cite{129}, "each of these solutions falls within the most desirable range of outcomes, but individually possesses its own advantages and disadvantages that would make it more or less favorable for further design development." The preferred design option (or options) sought by the designer is one that effectively balances all 3 objectives (\glsxtrshort{PPD}, \glsxtrshort{EUI}, Cost). Design configurations lying outside the circle of optimal solutions are not considered truly optimal because, while one or two objectives might be significantly optimized, others are adversely affected. For instance, the non-optimal solution illustrated in \cref{fig:ObjectiveSpace_Front} exhibits commendable values in brightness and \glsxtrshort{EUI}, alongside a minimal cost value, yet at the expense of a compromised \glsxtrshort{PPD}.

~\\
Some of the criterion should be taken into consideration:
\begin{itemize}
    \item \textbf{Balance:} Because the mechanics of the \glsxtrshort{GA}, The apex points of each fitness values would be always preserved for de-crowding computation. Yet, those solutions in apex, are too extreme in reality, being unpractical from the aspects of designers. So these solutions should be neglected by the secondary selection. In other words, balanced ones are preferred.
    \item \textbf{Sufficient daylight:} The \glsxtrshort{GA} will provide the extremely low WWR solutions, which are unacceptable in the office building. I.e. the larger windows are preferred.
    \item \textbf{High performance:} Since this research is technique-motivated, being encouraged by the \glsxtrshort{EU} commission, to obtain a sustainable performance is the goal. I.e. the better \glsxtrshort{EUI} performance solutions are preferred.
\end{itemize}
