You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
\section{Isothermal flow around activated objects (\texorpdfstring{\textct{obst\_activation}}{obst\_activation})}
2915
-
\label{obst_activation_default}
2916
-
\label{obst_activation_ulmat}
2914
+
\section{Isothermal Flow Around Activated Objects (\texorpdfstring{\textct{obst\_activation}}{obst\_activation})}
2915
+
\label{obst_activation}
2917
2916
2918
-
The cases presented here are found in input files {\ct Pressure\_Solver/obst\_activation\_default.fds} and {\ct obst\_activation\_ulmat.fds}. The domain is split in 4 meshes and several obstacles are made to disappear and appear during the simulation. These obstacles can be completely embedded inside meshes, or either overlap or abut mesh boundaries. Default and ULMAT pressure solvers are used. In figure~\ref{obst_act_fig}, maximum simulated temperatures in the domain vs time and ambient (target) temperature are shown.
2917
+
The cases presented here are found in input files {\ct Pressure\_Solver/obst\_activation\_default.fds} and {\ct obst\_activation\_ulmat.fds}. The domain is split into four meshes and several obstacles are made to disappear and appear during the simulation. These obstacles can be completely embedded inside meshes, or either overlap or abut mesh boundaries. Default (FFT) and ULMAT pressure solvers are used. Figure~\ref{obst_act_fig} displays the maximum divergence in the domain. These values should be comparable to machine precision for double precision floating point arithmetic.
Fire simulations can become computationally expensive due to combustion calculations, especially when detailed chemistry is involved. Often, in parallel simulations, combustion is concentrated in only a few MPI processes, while other MPI processes remain idle, waiting for the combustion-related tasks to finish. To address this, FDS incorporates a load-balancing algorithm that evenly distributes the combustion workload across all MPI processes. This can significantly speed up the detailed chemistry simulations, with performance improvements ranging from 2 to 6 times, depending on the configuration.
3885
+
Fire simulations can become computationally expensive due to combustion calculations, especially when detailed chemistry is involved. Often, in parallel simulations, combustion is concentrated in only a few MPI processes, while other MPI processes remain idle, waiting for the combustion-related tasks to finish. To address this, FDS incorporates a load-balancing algorithm that evenly distributes the combustion workload across all MPI processes. This can significantly speed up the detailed chemistry simulations, with performance improvements ranging from 2 to 6 times, depending on the configuration.
3887
3886
3888
3887
Three cases are considered to verify the load-balancing algorithm: the first uses a detailed chemical mechanism (Methane\_Smooke, see Section ~\ref{ignition_delay}); the second uses two-step Arrhenius reactions; and the third involves two-step fast chemistry reactions. In all cases, gaseous fuel (methane or propane) is injected from the burner. To account for combustion in both regular cells and Immersed Boundary Cut-Cells, a sphere is placed above the burner, allowing the flame to propagate around it.
3889
3888
3890
3889
3891
-
Figure \ref{fig:comb_load_bal_methane_smooke} shows the load-balancing test for the Methane\_Smoke detailed chemical mechanism using Sundials CVODE solver. In this configuration, there are 24 meshes, corresponding to 24 MPI processes. The top-left plot shows that without load balancing, each MPI process spends varying amounts of time on chemistry calculations. In contrast, with load balancing, the time spent on chemistry calculations is distributed evenly across all processes. In the no-load-balancing case, MPI process 6 spends the most time on chemistry, causing other processes to wait in the MPI communication queue, as shown in the top-right plot. With load balancing, communication time is also more evenly distributed. The overall simulation speedup with load balancing is approximately 2.2x, as depicted in the bottom-left plot. Finally, the bottom-right plot demonstrates that the results are identical with and without load balancing by comparing the wall temperatures at three locations.
3890
+
Figure \ref{fig:comb_load_bal_methane_smooke} shows the load-balancing test for the Methane\_Smoke detailed chemical mechanism using Sundials CVODE solver. In this configuration, there are 24 meshes, corresponding to 24 MPI processes. The top-left plot shows that without load balancing, each MPI process spends varying amounts of time on chemistry calculations. In contrast, with load balancing, the time spent on chemistry calculations is distributed evenly across all processes. In the no-load-balancing case, MPI process 6 spends the most time on chemistry, causing other processes to wait in the MPI communication queue, as shown in the top-right plot. With load balancing, communication time is also more evenly distributed. The overall simulation speedup with load balancing is approximately 2.2x, as depicted in the bottom-left plot. Finally, the bottom-right plot demonstrates that the results are identical with and without load balancing by comparing the wall temperatures at three locations.
3892
3891
3893
3892
Figure \ref{fig:comb_load_bal_2step_Arrhenius} presents a similar load-balancing test for two-step Propane Arrhenius reactions using the FDS-RK2 ODE solver. In this configuration, there are 6 meshes, corresponding to 6 MPI processes. The load-balancing results show similar trends as observed with the detailed chemical mechanism. However, the time spent on combustion (FIRE) is significantly lower compared to the detailed chemistry case (20\% vs. 65\%). As a result, even with combustion load balancing, other processes dominate the total simulation time, limiting the speedup to just 1.2x.
0 commit comments