<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.uni-due.de/agk/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Fynn.W</id>
	<title>Arbeitsgruppe Kuiper - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.uni-due.de/agk/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Fynn.W"/>
	<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Special:Contributions/Fynn.W"/>
	<updated>2026-05-20T06:11:08Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.39.10</generator>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1276</id>
		<title>MA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1276"/>
		<updated>2026-05-19T19:27:48Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: M: WIP – Local ionization equilibrium solver&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Initial Conditions =&lt;br /&gt;
&lt;br /&gt;
\( \color{red} TODO \color{black} \)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Problems =&lt;br /&gt;
&lt;br /&gt;
== Mean Photon Density in Irradiation Update (belt/src/Makemake2.1/Irradiation.c ~ Line 570) ==&lt;br /&gt;
&lt;br /&gt;
During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).&lt;br /&gt;
&lt;br /&gt;
In the following, only the absorption inside one cell is considered. The Attenuation factor in the code describes the geometrical dilution of the ray between the inner and outer cell face. Therefore, the derivation below focuses only on the local exponential absorption.&lt;br /&gt;
&lt;br /&gt;
Assuming a constant absorption coefficient inside the cell, the photon density decreases exponentially with distance \(s\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u(s) = u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\qquad , \qquad&lt;br /&gt;
0 \leq s \leq \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here \(\chi\) is the local ionizing absorption coefficient. For ionizing stellar photons,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\chi = n_\mathrm{H} \, y \, \sigma_\star ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
where \(n_\mathrm{H}\) is the hydrogen number density, \(y\) is the neutral fraction, and \(\sigma_\star\) is the ionization cross section. The optical depth across the full cell is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau = \chi \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The outgoing photon density at the right cell face is therefore&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
However, the local rate equations should not use only the right-face value. The photoionization term requires a representative photon density inside the cell. The physically motivated choice is the cell average,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x} u(s)\,\mathrm{d}s .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Inserting the exponential profile gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x}&lt;br /&gt;
u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\,\mathrm{d}s \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{u_\mathrm{L}}{\Delta x}&lt;br /&gt;
\frac{1 - e^{-\chi \Delta x}}{\chi} \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, the photon density used in the local ionization update should be&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\boxed{&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
instead of a simple arithmetic average between the left and right cell faces.&lt;br /&gt;
&lt;br /&gt;
Previously, the mean photon density was approximated as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{2}&lt;br /&gt;
\left(&lt;br /&gt;
u_\mathrm{L} + u_\mathrm{R}&lt;br /&gt;
\right) \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This approximation is reasonable only for optically thin cells. In this limit, both expressions agree to first order in \(\tau\). The cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
while the old arithmetic average gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2).&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, for \(\tau \ll 1\), both estimates are very similar.&lt;br /&gt;
&lt;br /&gt;
For optically thick cells, \(\tau \gg 1\), the outgoing photon density becomes nearly zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau} \rightarrow 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old approximation then approaches&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
\rightarrow&lt;br /&gt;
\frac{1}{2} u_\mathrm{L}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This overestimates the mean photon density in highly optically thick cells, because it assumes that roughly half of the incoming photon density is representative for the whole cell.&lt;br /&gt;
&lt;br /&gt;
The cell-averaged expression has the correct optically thick limiting behavior. For&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \gg 1:&lt;br /&gt;
\qquad&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{\tau},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
one obtains&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the right cell face can be almost completely dark while the cell-averaged photon density remains finite. However, it decreases with increasing optical depth as \(1/\tau\), instead of approaching the constant value \(u_\mathrm{L}/2\) from the old arithmetic average.&lt;br /&gt;
&lt;br /&gt;
[[File:Mean photon density optical depth.png]]&lt;br /&gt;
&lt;br /&gt;
In the crashing cell, the optical depth was extremely large,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \simeq 3.7\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
In this limit, the outgoing photon density is numerically zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R}&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L} e^{-\tau}&lt;br /&gt;
\approx&lt;br /&gt;
0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old arithmetic estimate therefore gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle_\mathrm{old}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{2}u_\mathrm{L},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
whereas the cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, for the crashing cell, the old estimate overestimated the photon density entering the local photoionization update by approximately&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{\langle u\rangle_\mathrm{old}}{\langle u\rangle}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{\tau}{2}&lt;br /&gt;
\sim&lt;br /&gt;
2\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This was likely problematic for the ionization iteration: the ray tracer treated the cell as optically thick enough to absorb essentially all ionizing photons, while the local rate equations still used a comparatively large photon density inside the same cell.&lt;br /&gt;
&lt;br /&gt;
The corresponding code change is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;c&amp;quot;&amp;gt;&lt;br /&gt;
dtau_ion   = nH * y * sigmastar * dx;&lt;br /&gt;
Extinction = exp(-dtau_ion);&lt;br /&gt;
ustarxr    = ustarxl * Attenuation * Extinction;&lt;br /&gt;
&lt;br /&gt;
/*&lt;br /&gt;
 * Old approximation:&lt;br /&gt;
 *     ustar = 0.5 * (ustarxl + ustarxr);&lt;br /&gt;
 */&lt;br /&gt;
if (dtau_ion &amp;gt; 1e-12) {&lt;br /&gt;
    ustar = ustarxl * (1.0 - Extinction) / dtau_ion;&lt;br /&gt;
} else {&lt;br /&gt;
    /*&lt;br /&gt;
     * Optically thin limit:&lt;br /&gt;
     *     (1 - exp(-dtau_ion)) / dtau_ion -&amp;gt; 1&lt;br /&gt;
     *&lt;br /&gt;
     * Avoid numerical division by zero.&lt;br /&gt;
     */&lt;br /&gt;
    ustar = ustarxl;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
x = IonizationFractionRateEquation(ustar, urec, Tgas, nH, x);&lt;br /&gt;
y = NeutralFractionRateEquation(   ustar, urec, Tgas, nH, y);&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Temperature-Based Initialization of Missing Ionization Fields (obsolete) ==&lt;br /&gt;
&amp;lt;div style=&amp;quot;background-color: #f9f9f9; border-left: 7px solid #ccc; padding: 15px; color: #777;&amp;quot;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
For restarts without stored ionization fields, the ionized and neutral fractions have to be initialized manually. If all cells are initialized as fully neutral, hot gas close to the inner boundary can become artificially optically thick to EUV radiation, because the ionizing optical depth depends directly on the neutral fraction,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau_\mathrm{ion}&lt;br /&gt;
=&lt;br /&gt;
n_\mathrm{H} y \sigma_\star \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
To avoid this, the missing ionization fields are initialized once at startup using the gas temperature. This is only an initial condition for restarts without ionization data. A smooth temperature transition is used between \(T_0 = 1\cdot10^4 \,\mathrm{K}\) and \(T_1 = 2\cdot10^4 \,\mathrm{K}\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
s&lt;br /&gt;
=&lt;br /&gt;
\frac{T_\mathrm{gas} - T_0}{T_1 - T_0},&lt;br /&gt;
\qquad&lt;br /&gt;
0 \leq s \leq 1 ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
with \(s\) clipped to the interval \([0,1]\). The initial ionized fraction is then&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
x_\mathrm{init}&lt;br /&gt;
=&lt;br /&gt;
s^2(3-2s),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
and the neutral fraction is set consistently as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
y_\mathrm{init}&lt;br /&gt;
=&lt;br /&gt;
1 - x_\mathrm{init}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This prevents already hot gas from being initialized as fully neutral and therefore artificially opaque. After the initialization, \(x\) and \(y\) evolve normally through the ionization-recombination solver.&lt;br /&gt;
&lt;br /&gt;
\(\color{black}\)&lt;br /&gt;
&lt;br /&gt;
[[File:Inital ion fraction temperature.png]]&lt;br /&gt;
&amp;lt;/div&amp;gt;&lt;br /&gt;
&lt;br /&gt;
= Local ionization equilibrium solver (TODO) =&lt;br /&gt;
&lt;br /&gt;
== Motivation ==&lt;br /&gt;
&lt;br /&gt;
The ionization module [https://ui.adsabs.harvard.edu/abs/2020ApJS..250...13K/abstract Kuiper etal 2020] evolves the ionization fraction \(x\) and the neutral fraction \(y\) of hydrogen. In the current implementation, the local ionization and recombination rate equations are advanced in time using implicit Euler steps. Since the ionization and recombination timescales are assumed to be much shorter than the MHD timescale, this local time evolution is expected to relax the gas toward a quasi-stationary ionization state between two MHD updates.&lt;br /&gt;
&lt;br /&gt;
The aim of this test is to investigate whether this quasi-stationary state can be found more directly. Instead of approaching the local equilibrium through a sequence of implicit time steps, the stationary rate equation is solved for its root in each cell.&lt;br /&gt;
&lt;br /&gt;
This does not change the underlying local rate equation. The difference is only numerical: the current approach obtains the equilibrium state by integrating the rate equation in pseudo-time, while the tested approach tries to solve the stationary balance condition directly. During this local ionization update, the hydrodynamic transport terms are neglected and the gas density is treated as fixed.&lt;br /&gt;
&lt;br /&gt;
== Theory ==&lt;br /&gt;
&lt;br /&gt;
=== Starting point ===&lt;br /&gt;
&lt;br /&gt;
The rate equation for the ionization fraction \(x\) is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t(\rho_{\mathrm{gas}} x)&lt;br /&gt;
+&lt;br /&gt;
\vec{\nabla} \cdot (\rho_{\mathrm{gas}} x \vec{u}_{\mathrm{gas}})&lt;br /&gt;
=&lt;br /&gt;
\rho_{\mathrm{gas}}&lt;br /&gt;
\left[&lt;br /&gt;
(\sigma_{\mathrm{EUV}}u_{\mathrm{EUV}} + \sigma_{\mathrm{rec}}u_{\mathrm{rec}})c \, y&lt;br /&gt;
+&lt;br /&gt;
C(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x y&lt;br /&gt;
-&lt;br /&gt;
\alpha^{(1)}(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x^2&lt;br /&gt;
\right].&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
For the local ionization update, the advection term is neglected and the gas density is treated as constant:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\vec{\nabla} \cdot(\rho_{\mathrm{gas}} x \vec{u}_{\mathrm{gas}}) = 0,&lt;br /&gt;
\qquad&lt;br /&gt;
\partial_t(\rho_{\mathrm{gas}}x) = \rho_{\mathrm{gas}} \partial_t x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
After canceling \(\rho_{\mathrm{gas}}\), this gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t x&lt;br /&gt;
=&lt;br /&gt;
(\sigma_{\mathrm{EUV}}u_{\mathrm{EUV}} + \sigma_{\mathrm{rec}}u_{\mathrm{rec}})c \, y&lt;br /&gt;
+&lt;br /&gt;
C(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x y&lt;br /&gt;
-&lt;br /&gt;
\alpha^{(1)}(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x^2 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The terms correspond to direct and diffuse recombination photoionization, collisional ionization, and recombination.&lt;br /&gt;
&lt;br /&gt;
=== Cell-averaged direct EUV photon density ===&lt;br /&gt;
&lt;br /&gt;
Instead of using only the incoming photon density at the cell interface, a cell-averaged value is used for the direct EUV photon density:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u_{\mathrm{EUV}}\rangle&lt;br /&gt;
=&lt;br /&gt;
u_L \frac{1-e^{-\Delta\tau}}{\Delta\tau},&lt;br /&gt;
\qquad&lt;br /&gt;
\Delta\tau = n_{\mathrm{H}} \sigma_{\mathrm{EUV}} \Delta x \, y .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here, \(u_L\) is the incoming direct EUV photon number density at the left or inner cell interface. Inserting this into the direct photoionization term gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t x&lt;br /&gt;
=&lt;br /&gt;
\sigma_{\mathrm{EUV}} c \, y \,&lt;br /&gt;
u_L \frac{1-e^{-n_{\mathrm{H}}\sigma_{\mathrm{EUV}}\Delta x \, y}}&lt;br /&gt;
{n_{\mathrm{H}}\sigma_{\mathrm{EUV}}\Delta x \, y}&lt;br /&gt;
+&lt;br /&gt;
\sigma_{\mathrm{rec}}u_{\mathrm{rec}}c \, y&lt;br /&gt;
+&lt;br /&gt;
C(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x y&lt;br /&gt;
-&lt;br /&gt;
\alpha^{(1)}(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x^2 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The factor \(y\sigma_{\mathrm{EUV}}\) cancels in the first term, resulting in&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t x&lt;br /&gt;
=&lt;br /&gt;
\frac{c u_L}{n_{\mathrm{H}}\Delta x}&lt;br /&gt;
\left(&lt;br /&gt;
1-e^{-n_{\mathrm{H}}\sigma_{\mathrm{EUV}}\Delta x \, y}&lt;br /&gt;
\right)&lt;br /&gt;
+&lt;br /&gt;
\sigma_{\mathrm{rec}}u_{\mathrm{rec}}c \, y&lt;br /&gt;
+&lt;br /&gt;
C(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x y&lt;br /&gt;
-&lt;br /&gt;
\alpha^{(1)}(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x^2 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
With \(y=1-x\), the local rate equation becomes&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t x&lt;br /&gt;
=&lt;br /&gt;
\frac{c u_L}{n_{\mathrm{H}}\Delta x}&lt;br /&gt;
\left[&lt;br /&gt;
1-e^{-n_{\mathrm{H}}\sigma_{\mathrm{EUV}}\Delta x \, (1-x)}&lt;br /&gt;
\right]&lt;br /&gt;
+&lt;br /&gt;
\sigma_{\mathrm{rec}}u_{\mathrm{rec}}c \, (1-x)&lt;br /&gt;
+&lt;br /&gt;
C(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x(1-x)&lt;br /&gt;
-&lt;br /&gt;
\alpha^{(1)}(T_{\mathrm{gas}}) n_{\mathrm{H}} \, x^2 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
=== Compact form ===&lt;br /&gt;
&lt;br /&gt;
The following abbreviations are introduced:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
A_{\mathrm{E}} = \frac{c u_L}{n_{\mathrm{H}}\Delta x},&lt;br /&gt;
\qquad&lt;br /&gt;
q_{\mathrm{E}} = n_{\mathrm{H}}\sigma_{\mathrm{EUV}}\Delta x,&lt;br /&gt;
\qquad&lt;br /&gt;
A_{\mathrm{rec}} = \sigma_{\mathrm{rec}}u_{\mathrm{rec}}c,&lt;br /&gt;
\qquad&lt;br /&gt;
A_{\mathrm{C}} = C(T_{\mathrm{gas}}) n_{\mathrm{H}},&lt;br /&gt;
\qquad&lt;br /&gt;
A_{\mathrm{R}} = \alpha^{(1)}(T_{\mathrm{gas}}) n_{\mathrm{H}} .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t x&lt;br /&gt;
=&lt;br /&gt;
A_E&lt;br /&gt;
\left[&lt;br /&gt;
1-e^{-q_E(1-x)}&lt;br /&gt;
\right]&lt;br /&gt;
+&lt;br /&gt;
A_{\mathrm{rec}} \, (1-x)&lt;br /&gt;
+&lt;br /&gt;
A_{\mathrm{C}} \, x(1-x)&lt;br /&gt;
-&lt;br /&gt;
A_{\mathrm{R}} \, x^2 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
=== Stationary local equilibrium ===&lt;br /&gt;
&lt;br /&gt;
The stationary local equilibrium corresponds to the ionization state for which&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\partial_t x = 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the stationary ionization fraction is obtained as a root of&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
f(x)&lt;br /&gt;
=&lt;br /&gt;
A_E&lt;br /&gt;
\left[&lt;br /&gt;
1-e^{-q_E(1-x)}&lt;br /&gt;
\right]&lt;br /&gt;
+&lt;br /&gt;
A_{\mathrm{rec}} \, (1-x)&lt;br /&gt;
+&lt;br /&gt;
A_{\mathrm{C}} \, x(1-x)&lt;br /&gt;
-&lt;br /&gt;
A_{\mathrm{R}} \, x^2 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The solution must lie in the physical interval&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
0 \le x \le 1 .&lt;br /&gt;
\end{align}&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1259</id>
		<title>MA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1259"/>
		<updated>2026-05-12T19:05:53Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Plots + Initial Ion Fraction&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Initial Conditions =&lt;br /&gt;
&lt;br /&gt;
\( \color{red} TODO \color{black} \)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Problems =&lt;br /&gt;
&lt;br /&gt;
== Mean Photon Density in Irradiation Update (belt/src/Makemake2.1/Irradiation.c ~ Line 570) ==&lt;br /&gt;
&lt;br /&gt;
During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).&lt;br /&gt;
&lt;br /&gt;
In the following, only the absorption inside one cell is considered. The Attenuation factor in the code describes the geometrical dilution of the ray between the inner and outer cell face. Therefore, the derivation below focuses only on the local exponential absorption.&lt;br /&gt;
&lt;br /&gt;
Assuming a constant absorption coefficient inside the cell, the photon density decreases exponentially with distance \(s\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u(s) = u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\qquad , \qquad&lt;br /&gt;
0 \leq s \leq \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here \(\chi\) is the local ionizing absorption coefficient. For ionizing stellar photons,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\chi = n_\mathrm{H} \, y \, \sigma_\star ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
where \(n_\mathrm{H}\) is the hydrogen number density, \(y\) is the neutral fraction, and \(\sigma_\star\) is the ionization cross section. The optical depth across the full cell is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau = \chi \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The outgoing photon density at the right cell face is therefore&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
However, the local rate equations should not use only the right-face value. The photoionization term requires a representative photon density inside the cell. The physically motivated choice is the cell average,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x} u(s)\,\mathrm{d}s .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Inserting the exponential profile gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x}&lt;br /&gt;
u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\,\mathrm{d}s \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{u_\mathrm{L}}{\Delta x}&lt;br /&gt;
\frac{1 - e^{-\chi \Delta x}}{\chi} \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, the photon density used in the local ionization update should be&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\boxed{&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
instead of a simple arithmetic average between the left and right cell faces.&lt;br /&gt;
&lt;br /&gt;
Previously, the mean photon density was approximated as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{2}&lt;br /&gt;
\left(&lt;br /&gt;
u_\mathrm{L} + u_\mathrm{R}&lt;br /&gt;
\right) \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This approximation is reasonable only for optically thin cells. In this limit, both expressions agree to first order in \(\tau\). The cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
while the old arithmetic average gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2).&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, for \(\tau \ll 1\), both estimates are very similar.&lt;br /&gt;
&lt;br /&gt;
For optically thick cells, \(\tau \gg 1\), the outgoing photon density becomes nearly zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau} \rightarrow 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old approximation then approaches&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
\rightarrow&lt;br /&gt;
\frac{1}{2} u_\mathrm{L}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This overestimates the mean photon density in highly optically thick cells, because it assumes that roughly half of the incoming photon density is representative for the whole cell.&lt;br /&gt;
&lt;br /&gt;
The cell-averaged expression has the correct optically thick limiting behavior. For&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \gg 1:&lt;br /&gt;
\qquad&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{\tau},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
one obtains&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the right cell face can be almost completely dark while the cell-averaged photon density remains finite. However, it decreases with increasing optical depth as \(1/\tau\), instead of approaching the constant value \(u_\mathrm{L}/2\) from the old arithmetic average.&lt;br /&gt;
&lt;br /&gt;
[[File:Mean photon density optical depth.png]]&lt;br /&gt;
&lt;br /&gt;
In the crashing cell, the optical depth was extremely large,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \simeq 3.7\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
In this limit, the outgoing photon density is numerically zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R}&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L} e^{-\tau}&lt;br /&gt;
\approx&lt;br /&gt;
0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old arithmetic estimate therefore gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle_\mathrm{old}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{2}u_\mathrm{L},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
whereas the cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, for the crashing cell, the old estimate overestimated the photon density entering the local photoionization update by approximately&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{\langle u\rangle_\mathrm{old}}{\langle u\rangle}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{\tau}{2}&lt;br /&gt;
\sim&lt;br /&gt;
2\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This was likely problematic for the ionization iteration: the ray tracer treated the cell as optically thick enough to absorb essentially all ionizing photons, while the local rate equations still used a comparatively large photon density inside the same cell.&lt;br /&gt;
&lt;br /&gt;
The corresponding code change is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;c&amp;quot;&amp;gt;&lt;br /&gt;
dtau_ion   = nH * y * sigmastar * dx;&lt;br /&gt;
Extinction = exp(-dtau_ion);&lt;br /&gt;
ustarxr    = ustarxl * Attenuation * Extinction;&lt;br /&gt;
&lt;br /&gt;
/*&lt;br /&gt;
 * Old approximation:&lt;br /&gt;
 *     ustar = 0.5 * (ustarxl + ustarxr);&lt;br /&gt;
 */&lt;br /&gt;
if (dtau_ion &amp;gt; 1e-12) {&lt;br /&gt;
    ustar = ustarxl * (1.0 - Extinction) / dtau_ion;&lt;br /&gt;
} else {&lt;br /&gt;
    /*&lt;br /&gt;
     * Optically thin limit:&lt;br /&gt;
     *     (1 - exp(-dtau_ion)) / dtau_ion -&amp;gt; 1&lt;br /&gt;
     *&lt;br /&gt;
     * Avoid numerical division by zero.&lt;br /&gt;
     */&lt;br /&gt;
    ustar = ustarxl;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
x = IonizationFractionRateEquation(ustar, urec, Tgas, nH, x);&lt;br /&gt;
y = NeutralFractionRateEquation(   ustar, urec, Tgas, nH, y);&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Temperature-Based Initialization of Missing Ionization Fields ==&lt;br /&gt;
&lt;br /&gt;
For restarts without stored ionization fields, the ionized and neutral fractions have to be initialized manually. If all cells are initialized as fully neutral, hot gas close to the inner boundary can become artificially optically thick to EUV radiation, because the ionizing optical depth depends directly on the neutral fraction,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau_\mathrm{ion}&lt;br /&gt;
=&lt;br /&gt;
n_\mathrm{H} y \sigma_\star \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
To avoid this, the missing ionization fields are initialized once at startup using the gas temperature. This is only an initial condition for restarts without ionization data. A smooth temperature transition is used between \(T_0 = 1\cdot10^4 \,\mathrm{K}\) and \(T_1 = 2\cdot10^4 \,\mathrm{K}\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
s&lt;br /&gt;
=&lt;br /&gt;
\frac{T_\mathrm{gas} - T_0}{T_1 - T_0},&lt;br /&gt;
\qquad&lt;br /&gt;
0 \leq s \leq 1 ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
with \(s\) clipped to the interval \([0,1]\). The initial ionized fraction is then&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
x_\mathrm{init}&lt;br /&gt;
=&lt;br /&gt;
s^2(3-2s),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
and the neutral fraction is set consistently as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
y_\mathrm{init}&lt;br /&gt;
=&lt;br /&gt;
1 - x_\mathrm{init}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This prevents already hot gas from being initialized as fully neutral and therefore artificially opaque. After the initialization, \(x\) and \(y\) evolve normally through the ionization-recombination solver.&lt;br /&gt;
&lt;br /&gt;
[[File:Inital ion fraction temperature.png]]&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:MAFW_Mean_photon_density_optical_depth.png&amp;diff=1258</id>
		<title>File:MAFW Mean photon density optical depth.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:MAFW_Mean_photon_density_optical_depth.png&amp;diff=1258"/>
		<updated>2026-05-12T19:01:55Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Shows the new mean photon density and the older definition.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:MAFW_Inital_ion_fraction_temperature.png&amp;diff=1257</id>
		<title>File:MAFW Inital ion fraction temperature.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:MAFW_Inital_ion_fraction_temperature.png&amp;diff=1257"/>
		<updated>2026-05-12T18:59:27Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Shows how the ion fraction is set after restart based on temperature&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1256</id>
		<title>MA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1256"/>
		<updated>2026-05-12T17:41:11Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Initial Conditions =&lt;br /&gt;
&lt;br /&gt;
\( \color{red} TODO \color{black} \)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Problems =&lt;br /&gt;
&lt;br /&gt;
== Mean Photon Density in Irradiation Update (belt/src/Makemake2.1/Irradiation.c ~ Line 570) ==&lt;br /&gt;
&lt;br /&gt;
During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).&lt;br /&gt;
&lt;br /&gt;
In the following, only the absorption inside one cell is considered. The Attenuation factor in the code describes the geometrical dilution of the ray between the inner and outer cell face. Therefore, the derivation below focuses only on the local exponential absorption.&lt;br /&gt;
&lt;br /&gt;
Assuming a constant absorption coefficient inside the cell, the photon density decreases exponentially with distance \(s\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u(s) = u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\qquad , \qquad&lt;br /&gt;
0 \leq s \leq \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here \(\chi\) is the local ionizing absorption coefficient. For ionizing stellar photons,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\chi = n_\mathrm{H} \, y \, \sigma_\star ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
where \(n_\mathrm{H}\) is the hydrogen number density, \(y\) is the neutral fraction, and \(\sigma_\star\) is the ionization cross section. The optical depth across the full cell is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau = \chi \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The outgoing photon density at the right cell face is therefore&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
However, the local rate equations should not use only the right-face value. The photoionization term requires a representative photon density inside the cell. The physically motivated choice is the cell average,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x} u(s)\,\mathrm{d}s .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Inserting the exponential profile gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x}&lt;br /&gt;
u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\,\mathrm{d}s \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{u_\mathrm{L}}{\Delta x}&lt;br /&gt;
\frac{1 - e^{-\chi \Delta x}}{\chi} \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, the photon density used in the local ionization update should be&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\boxed{&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
instead of a simple arithmetic average between the left and right cell faces.&lt;br /&gt;
&lt;br /&gt;
Previously, the mean photon density was approximated as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{2}&lt;br /&gt;
\left(&lt;br /&gt;
u_\mathrm{L} + u_\mathrm{R}&lt;br /&gt;
\right) \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This approximation is reasonable only for optically thin cells. In this limit, both expressions agree to first order in \(\tau\). The cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
while the old arithmetic average gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2).&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, for \(\tau \ll 1\), both estimates are very similar.&lt;br /&gt;
&lt;br /&gt;
For optically thick cells, \(\tau \gg 1\), the outgoing photon density becomes nearly zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau} \rightarrow 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old approximation then approaches&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
\rightarrow&lt;br /&gt;
\frac{1}{2} u_\mathrm{L}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This overestimates the mean photon density in highly optically thick cells, because it assumes that roughly half of the incoming photon density is representative for the whole cell.&lt;br /&gt;
&lt;br /&gt;
The cell-averaged expression has the correct optically thick limiting behavior. For&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \gg 1:&lt;br /&gt;
\qquad&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{\tau},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
one obtains&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the right cell face can be almost completely dark while the cell-averaged photon density remains finite. However, it decreases with increasing optical depth as \(1/\tau\), instead of approaching the constant value \(u_\mathrm{L}/2\) from the old arithmetic average.&lt;br /&gt;
&lt;br /&gt;
In the crashing cell, the optical depth was extremely large,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \simeq 3.7\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
In this limit, the outgoing photon density is numerically zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R}&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L} e^{-\tau}&lt;br /&gt;
\approx&lt;br /&gt;
0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old arithmetic estimate therefore gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle_\mathrm{old}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{2}u_\mathrm{L},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
whereas the cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, for the crashing cell, the old estimate overestimated the photon density entering the local photoionization update by approximately&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{\langle u\rangle_\mathrm{old}}{\langle u\rangle}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{\tau}{2}&lt;br /&gt;
\sim&lt;br /&gt;
2\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This was likely problematic for the ionization iteration: the ray tracer treated the cell as optically thick enough to absorb essentially all ionizing photons, while the local rate equations still used a comparatively large photon density inside the same cell.&lt;br /&gt;
&lt;br /&gt;
The corresponding code change is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;c&amp;quot;&amp;gt;&lt;br /&gt;
dtau_ion   = nH * y * sigmastar * dx;&lt;br /&gt;
Extinction = exp(-dtau_ion);&lt;br /&gt;
ustarxr    = ustarxl * Attenuation * Extinction;&lt;br /&gt;
&lt;br /&gt;
/*&lt;br /&gt;
 * Old approximation:&lt;br /&gt;
 *     ustar = 0.5 * (ustarxl + ustarxr);&lt;br /&gt;
 */&lt;br /&gt;
if (dtau_ion &amp;gt; 1e-12) {&lt;br /&gt;
    ustar = ustarxl * (1.0 - Extinction) / dtau_ion;&lt;br /&gt;
} else {&lt;br /&gt;
    /*&lt;br /&gt;
     * Optically thin limit:&lt;br /&gt;
     *     (1 - exp(-dtau_ion)) / dtau_ion -&amp;gt; 1&lt;br /&gt;
     *&lt;br /&gt;
     * Avoid numerical division by zero.&lt;br /&gt;
     */&lt;br /&gt;
    ustar = ustarxl;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
x = IonizationFractionRateEquation(ustar, urec, Tgas, nH, x);&lt;br /&gt;
y = NeutralFractionRateEquation(   ustar, urec, Tgas, nH, y);&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1255</id>
		<title>MA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1255"/>
		<updated>2026-05-12T17:36:33Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Initial Conditions =&lt;br /&gt;
&lt;br /&gt;
\( \color{red} TODO \color{black} \)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Problems =&lt;br /&gt;
&lt;br /&gt;
== Mean Photon Density in Irradiation Update ( ==&lt;br /&gt;
&lt;br /&gt;
During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).&lt;br /&gt;
&lt;br /&gt;
In the following, only the absorption inside one cell is considered. The Attenuation factor in the code describes the geometrical dilution of the ray between the inner and outer cell face. Therefore, the derivation below focuses only on the local exponential absorption.&lt;br /&gt;
&lt;br /&gt;
Assuming a constant absorption coefficient inside the cell, the photon density decreases exponentially with distance \(s\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u(s) = u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\qquad , \qquad&lt;br /&gt;
0 \leq s \leq \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here \(\chi\) is the local ionizing absorption coefficient. For ionizing stellar photons,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\chi = n_\mathrm{H} \, y \, \sigma_\star ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
where \(n_\mathrm{H}\) is the hydrogen number density, \(y\) is the neutral fraction, and \(\sigma_\star\) is the ionization cross section. The optical depth across the full cell is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau = \chi \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The outgoing photon density at the right cell face is therefore&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
However, the local rate equations should not use only the right-face value. The photoionization term requires a representative photon density inside the cell. The physically motivated choice is the cell average,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x} u(s)\,\mathrm{d}s .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Inserting the exponential profile gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x}&lt;br /&gt;
u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\,\mathrm{d}s \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{u_\mathrm{L}}{\Delta x}&lt;br /&gt;
\frac{1 - e^{-\chi \Delta x}}{\chi} \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, the photon density used in the local ionization update should be&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\boxed{&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
instead of a simple arithmetic average between the left and right cell faces.&lt;br /&gt;
&lt;br /&gt;
Previously, the mean photon density was approximated as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{2}&lt;br /&gt;
\left(&lt;br /&gt;
u_\mathrm{L} + u_\mathrm{R}&lt;br /&gt;
\right) \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This approximation is reasonable only for optically thin cells. In this limit, both expressions agree to first order in \(\tau\). The cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
while the old arithmetic average gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2).&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, for \(\tau \ll 1\), both estimates are very similar.&lt;br /&gt;
&lt;br /&gt;
For optically thick cells, \(\tau \gg 1\), the outgoing photon density becomes nearly zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau} \rightarrow 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old approximation then approaches&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
\rightarrow&lt;br /&gt;
\frac{1}{2} u_\mathrm{L}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This overestimates the mean photon density in highly optically thick cells, because it assumes that roughly half of the incoming photon density is representative for the whole cell.&lt;br /&gt;
&lt;br /&gt;
The cell-averaged expression has the correct optically thick limiting behavior. For&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \gg 1:&lt;br /&gt;
\qquad&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{\tau},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
one obtains&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the right cell face can be almost completely dark while the cell-averaged photon density remains finite. However, it decreases with increasing optical depth as \(1/\tau\), instead of approaching the constant value \(u_\mathrm{L}/2\) from the old arithmetic average.&lt;br /&gt;
&lt;br /&gt;
In the crashing cell, the optical depth was extremely large,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \simeq 3.7\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
In this limit, the outgoing photon density is numerically zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R}&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L} e^{-\tau}&lt;br /&gt;
\approx&lt;br /&gt;
0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old arithmetic estimate therefore gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle_\mathrm{old}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{2}u_\mathrm{L},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
whereas the cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, for the crashing cell, the old estimate overestimated the photon density entering the local photoionization update by approximately&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{\langle u\rangle_\mathrm{old}}{\langle u\rangle}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{\tau}{2}&lt;br /&gt;
\sim&lt;br /&gt;
2\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This was likely problematic for the ionization iteration: the ray tracer treated the cell as optically thick enough to absorb essentially all ionizing photons, while the local rate equations still used a comparatively large photon density inside the same cell.&lt;br /&gt;
&lt;br /&gt;
The corresponding code change is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;c&amp;quot;&amp;gt;&lt;br /&gt;
dtau_ion   = nH * y * sigmastar * dx;&lt;br /&gt;
Extinction = exp(-dtau_ion);&lt;br /&gt;
ustarxr    = ustarxl * Attenuation * Extinction;&lt;br /&gt;
&lt;br /&gt;
/*&lt;br /&gt;
 * Old approximation:&lt;br /&gt;
 *     ustar = 0.5 * (ustarxl + ustarxr);&lt;br /&gt;
 */&lt;br /&gt;
if (dtau_ion &amp;gt; 1e-12) {&lt;br /&gt;
    ustar = ustarxl * (1.0 - Extinction) / dtau_ion;&lt;br /&gt;
} else {&lt;br /&gt;
    /*&lt;br /&gt;
     * Optically thin limit:&lt;br /&gt;
     *     (1 - exp(-dtau_ion)) / dtau_ion -&amp;gt; 1&lt;br /&gt;
     *&lt;br /&gt;
     * Avoid numerical division by zero.&lt;br /&gt;
     */&lt;br /&gt;
    ustar = ustarxl;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
x = IonizationFractionRateEquation(ustar, urec, Tgas, nH, x);&lt;br /&gt;
y = NeutralFractionRateEquation(   ustar, urec, Tgas, nH, y);&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1254</id>
		<title>MA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1254"/>
		<updated>2026-05-12T17:34:09Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Initial Conditions =&lt;br /&gt;
&lt;br /&gt;
\( \color{red} TODO \color{black} \)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Problems =&lt;br /&gt;
&lt;br /&gt;
== Mean Photon Density in Irradiation Update ( ==&lt;br /&gt;
&lt;br /&gt;
During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).&lt;br /&gt;
&lt;br /&gt;
In the following, only the absorption inside one cell is considered. The Attenuation factor in the code describes the geometrical dilution of the ray between the inner and outer cell face. Therefore, the derivation below focuses only on the local exponential absorption.&lt;br /&gt;
&lt;br /&gt;
Assuming a constant absorption coefficient inside the cell, the photon density decreases exponentially with distance \(s\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u(s) = u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\qquad , \qquad&lt;br /&gt;
0 \leq s \leq \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here \(\chi\) is the local ionizing absorption coefficient. For ionizing stellar photons,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\chi = n_\mathrm{H} \, y \, \sigma_\star ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
where \(n_\mathrm{H}\) is the hydrogen number density, \(y\) is the neutral fraction, and \(\sigma_\star\) is the ionization cross section. The optical depth across the full cell is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau = \chi \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The outgoing photon density at the right cell face is therefore&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
However, the local rate equations should not use only the right-face value. The photoionization term requires a representative photon density inside the cell. The physically motivated choice is the cell average,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x} u(s)\,\mathrm{d}s .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Inserting the exponential profile gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x}&lt;br /&gt;
u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\,\mathrm{d}s \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{u_\mathrm{L}}{\Delta x}&lt;br /&gt;
\frac{1 - e^{-\chi \Delta x}}{\chi} \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, the photon density used in the local ionization update should be&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\boxed{&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
instead of a simple arithmetic average between the left and right cell faces.&lt;br /&gt;
&lt;br /&gt;
Previously, the mean photon density was approximated as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{2}&lt;br /&gt;
\left(&lt;br /&gt;
u_\mathrm{L} + u_\mathrm{R}&lt;br /&gt;
\right) \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This approximation is reasonable only for optically thin cells. In this limit, both expressions agree to first order in \(\tau\). The cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
while the old arithmetic average gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2).&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, for \(\tau \ll 1\), both estimates are very similar.&lt;br /&gt;
&lt;br /&gt;
For optically thick cells, \(\tau \gg 1\), the outgoing photon density becomes nearly zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau} \rightarrow 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old approximation then approaches&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
\rightarrow&lt;br /&gt;
\frac{1}{2} u_\mathrm{L}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This overestimates the mean photon density in highly optically thick cells, because it assumes that roughly half of the incoming photon density is representative for the whole cell.&lt;br /&gt;
&lt;br /&gt;
The cell-averaged expression has the correct optically thick limiting behavior. For&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \gg 1:&lt;br /&gt;
\qquad&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{\tau},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
one obtains&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the right cell face can be almost completely dark while the cell-averaged photon density remains finite. However, it decreases with increasing optical depth as \(1/\tau\), instead of approaching the constant value \(u_\mathrm{L}/2\) from the old arithmetic average.&lt;br /&gt;
&lt;br /&gt;
In the crashing cell, the optical depth was extremely large,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \simeq 3.7\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
In this limit, the outgoing photon density is numerically zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R}&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L} e^{-\tau}&lt;br /&gt;
\approx&lt;br /&gt;
0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old arithmetic estimate therefore gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle_\mathrm{old}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{2}u_\mathrm{L},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
whereas the cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, for the crashing cell, the old estimate overestimated the photon density entering the local photoionization update by approximately&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{\langle u\rangle_\mathrm{old}}{\langle u\rangle}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{\tau}{2}&lt;br /&gt;
\sim&lt;br /&gt;
2\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This was likely problematic for the ionization iteration: the ray tracer treated the cell as optically thick enough to absorb essentially all ionizing photons, while the local rate equations still used a comparatively large photon density inside the same cell.&lt;br /&gt;
&lt;br /&gt;
The corresponding code change is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;c&amp;quot;&amp;gt;&lt;br /&gt;
dtau_ion   = nH * y * sigmastar * dx;&lt;br /&gt;
Extinction = exp(-dtau_ion);&lt;br /&gt;
ustarxr    = ustarxl * Attenuation * Extinction;&lt;br /&gt;
&lt;br /&gt;
/*&lt;br /&gt;
 * Old approximation:&lt;br /&gt;
 *     ustar = 0.5 * (ustarxl + ustarxr);&lt;br /&gt;
 */&lt;br /&gt;
if (dtau_ion &amp;gt; 1e-12) {&lt;br /&gt;
    ustar = ustarxl * (1.0 - Extinction) / dtau_ion;&lt;br /&gt;
} else {&lt;br /&gt;
    /*&lt;br /&gt;
     * Optically thin limit:&lt;br /&gt;
     *     (1 - exp(-dtau_ion)) / dtau_ion -&amp;gt; 1&lt;br /&gt;
     *&lt;br /&gt;
     * Avoid numerical division by zero.&lt;br /&gt;
     */&lt;br /&gt;
    ustar = ustarxl;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
x = IonizationFractionRateEquation(ustar, urec, Tgas, nH, x);&lt;br /&gt;
y = NeutralFractionRateEquation(   ustar, urec, Tgas, nH, y);&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This change makes the photon density used in the local update consistent with the optical depth used by the ray tracer. In optically thin cells, the result is essentially unchanged. In optically thick cells, however, the representative photon density is reduced from approximately \(u_\mathrm{L}/2\) to approximately \(u_\mathrm{L}/\tau\), which is physically more consistent with the exponential attenuation inside the cell.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1253</id>
		<title>MA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=MA_Fynn_Wawrzyniak&amp;diff=1253"/>
		<updated>2026-05-12T17:33:32Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Created page with &amp;quot;= Initial Conditions =  \( \color{red} TODO \color{black} \)   = Problems =  == Mean Photon Density in Irradiation Update ( ==  During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).  In the following...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Initial Conditions =&lt;br /&gt;
&lt;br /&gt;
\( \color{red} TODO \color{black} \)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Problems =&lt;br /&gt;
&lt;br /&gt;
== Mean Photon Density in Irradiation Update ( ==&lt;br /&gt;
&lt;br /&gt;
During the iterative irradiation update, the local ionization update requires a representative photon density inside each cell for the photoionization term. The ray tracer knows the incoming photon density at the left cell face, \(u_\mathrm{L}\), and computes the outgoing photon density at the right cell face, \(u_\mathrm{R}\).&lt;br /&gt;
&lt;br /&gt;
In the following, only the absorption inside one cell is considered. &#039;&#039;&#039;Attenuation&#039;&#039;&#039; factor in the code describes the geometrical dilution of the ray between the inner and outer cell face. Therefore, the derivation below focuses only on the local exponential absorption.&lt;br /&gt;
&lt;br /&gt;
Assuming a constant absorption coefficient inside the cell, the photon density decreases exponentially with distance \(s\):&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u(s) = u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\qquad , \qquad&lt;br /&gt;
0 \leq s \leq \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Here \(\chi\) is the local ionizing absorption coefficient. For ionizing stellar photons,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\chi = n_\mathrm{H} \, y \, \sigma_\star ,&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
where \(n_\mathrm{H}\) is the hydrogen number density, \(y\) is the neutral fraction, and \(\sigma_\star\) is the ionization cross section. The optical depth across the full cell is&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau = \chi \Delta x .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The outgoing photon density at the right cell face is therefore&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
However, the local rate equations should not use only the right-face value. The photoionization term requires a representative photon density inside the cell. The physically motivated choice is the cell average,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x} u(s)\,\mathrm{d}s .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Inserting the exponential profile gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{\Delta x}&lt;br /&gt;
\int_0^{\Delta x}&lt;br /&gt;
u_\mathrm{L} e^{-\chi s}&lt;br /&gt;
\,\mathrm{d}s \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{u_\mathrm{L}}{\Delta x}&lt;br /&gt;
\frac{1 - e^{-\chi \Delta x}}{\chi} \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, the photon density used in the local ionization update should be&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\boxed{&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
instead of a simple arithmetic average between the left and right cell faces.&lt;br /&gt;
&lt;br /&gt;
Previously, the mean photon density was approximated as&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
\frac{1}{2}&lt;br /&gt;
\left(&lt;br /&gt;
u_\mathrm{L} + u_\mathrm{R}&lt;br /&gt;
\right) \\&lt;br /&gt;
&amp;amp;=&lt;br /&gt;
u_\mathrm{L}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This approximation is reasonable only for optically thin cells. In this limit, both expressions agree to first order in \(\tau\). The cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2),&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
while the old arithmetic average gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{1 + e^{-\tau}}{2}&lt;br /&gt;
=&lt;br /&gt;
1 - \frac{\tau}{2}&lt;br /&gt;
+&lt;br /&gt;
\mathcal{O}(\tau^2).&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, for \(\tau \ll 1\), both estimates are very similar.&lt;br /&gt;
&lt;br /&gt;
For optically thick cells, \(\tau \gg 1\), the outgoing photon density becomes nearly zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R} = u_\mathrm{L} e^{-\tau} \rightarrow 0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old approximation then approaches&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle_\mathrm{old}&lt;br /&gt;
\rightarrow&lt;br /&gt;
\frac{1}{2} u_\mathrm{L}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This overestimates the mean photon density in highly optically thick cells, because it assumes that roughly half of the incoming photon density is representative for the whole cell.&lt;br /&gt;
&lt;br /&gt;
The cell-averaged expression has the correct optically thick limiting behavior. For&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \gg 1:&lt;br /&gt;
\qquad&lt;br /&gt;
\frac{1 - e^{-\tau}}{\tau}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{\tau},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
one obtains&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u \rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Therefore, the right cell face can be almost completely dark while the cell-averaged photon density remains finite. However, it decreases with increasing optical depth as \(1/\tau\), instead of approaching the constant value \(u_\mathrm{L}/2\) from the old arithmetic average.&lt;br /&gt;
&lt;br /&gt;
In the crashing cell, the optical depth was extremely large,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\tau \simeq 3.7\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
In this limit, the outgoing photon density is numerically zero,&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
u_\mathrm{R}&lt;br /&gt;
=&lt;br /&gt;
u_\mathrm{L} e^{-\tau}&lt;br /&gt;
\approx&lt;br /&gt;
0 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
The old arithmetic estimate therefore gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle_\mathrm{old}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{1}{2}u_\mathrm{L},&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
whereas the cell-averaged expression gives&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\langle u\rangle&lt;br /&gt;
\approx&lt;br /&gt;
\frac{u_\mathrm{L}}{\tau}.&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Thus, for the crashing cell, the old estimate overestimated the photon density entering the local photoionization update by approximately&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{\langle u\rangle_\mathrm{old}}{\langle u\rangle}&lt;br /&gt;
\approx&lt;br /&gt;
\frac{\tau}{2}&lt;br /&gt;
\sim&lt;br /&gt;
2\times 10^4 .&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
This was likely problematic for the ionization iteration: the ray tracer treated the cell as optically thick enough to absorb essentially all ionizing photons, while the local rate equations still used a comparatively large photon density inside the same cell.&lt;br /&gt;
&lt;br /&gt;
The corresponding code change is&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;c&amp;quot;&amp;gt;&lt;br /&gt;
dtau_ion   = nH * y * sigmastar * dx;&lt;br /&gt;
Extinction = exp(-dtau_ion);&lt;br /&gt;
ustarxr    = ustarxl * Attenuation * Extinction;&lt;br /&gt;
&lt;br /&gt;
/*&lt;br /&gt;
 * Old approximation:&lt;br /&gt;
 *     ustar = 0.5 * (ustarxl + ustarxr);&lt;br /&gt;
 */&lt;br /&gt;
if (dtau_ion &amp;gt; 1e-12) {&lt;br /&gt;
    ustar = ustarxl * (1.0 - Extinction) / dtau_ion;&lt;br /&gt;
} else {&lt;br /&gt;
    /*&lt;br /&gt;
     * Optically thin limit:&lt;br /&gt;
     *     (1 - exp(-dtau_ion)) / dtau_ion -&amp;gt; 1&lt;br /&gt;
     *&lt;br /&gt;
     * Avoid numerical division by zero.&lt;br /&gt;
     */&lt;br /&gt;
    ustar = ustarxl;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
x = IonizationFractionRateEquation(ustar, urec, Tgas, nH, x);&lt;br /&gt;
y = NeutralFractionRateEquation(   ustar, urec, Tgas, nH, y);&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This change makes the photon density used in the local update consistent with the optical depth used by the ray tracer. In optically thin cells, the result is essentially unchanged. In optically thick cells, however, the representative photon density is reduced from approximately \(u_\mathrm{L}/2\) to approximately \(u_\mathrm{L}/\tau\), which is physically more consistent with the exponential attenuation inside the cell.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=716</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=716"/>
		<updated>2025-03-20T20:47:02Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Update Datenformat&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
== Struktureller Aufbau ==&lt;br /&gt;
Die Windtunnel-Online-GUI ist dafür entwickelt worden, um durch &#039;&#039;PLUTO&#039;&#039; generierte Simulationsdatensätze effizient in einer Webanwendung darzustellen. Die Herausforderung dabei liegt in der Größe der Datensätze, die oft sehr umfangreich sind. Diese müssen so aufbereitet werden, dass sie auf einer Website sinnvoll visualisiert werden können, ohne dass es zu langen Ladezeiten oder Performance-Problemen kommt.&lt;br /&gt;
&lt;br /&gt;
Das Problem ist daher in zwei zentrale Bereiche unterteilt:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Server-Side:&#039;&#039;&#039; Hier sind die vollständigen Datensätze aus &#039;&#039;PLUTO&#039;&#039; gespeichert. Die Hauptaufgabe besteht darin, diese Daten effizient zu verwalten, in einem geeigneten Format aufzubereiten und auf Anfrage an den Client zu senden.&lt;br /&gt;
* &#039;&#039;&#039;Client-Side:&#039;&#039;&#039; Auf der Client-Seite werden die vorbereiteten Daten empfangen, dekomprimiert und visuell dargestellt. Zudem gibt es eine Benutzeroberfläche, über die verschiedene Parameter angepasst werden können. Ändert der Nutzer eine Einstellung, müssen neue Daten vom Server angefordert werden, um die Visualisierung entsprechend zu aktualisieren.&lt;br /&gt;
&lt;br /&gt;
Die folgende Grafik gibt einen Überblick über den strukturellen Aufbau und die Interaktion dieser Komponenten:&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
=== Client Side ===&lt;br /&gt;
..... in Bearbeitung ...&lt;br /&gt;
&lt;br /&gt;
=== Sever Side ===&lt;br /&gt;
... in Bearbeitung ....&lt;br /&gt;
&lt;br /&gt;
== Datenformat (Wrong - Small Changes in Code) ==&lt;br /&gt;
Für jeden Zeitschritt werden drei physikalische Felder – das betrachtete Feld (z. B. Dichte) sowie die Geschwindigkeitskomponenten vx1 und vx2 – in einem &#039;&#039;&#039;Frame&#039;&#039;&#039; versendet. Mehrere dieser Frames werden zu einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst, sodass mehrere Zeitschritte effizient in einer einzigen Nachricht übertragen werden können. Die folgende Grafik zeigt den Aufbau eines solchen Frame-Batches:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:WINDTUNNEL GUI Frame Batch Diagram.jpg|border|frameless|964x964px]]&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Frame&#039;&#039;&#039; besteht aus zwei Hauptteilen:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Header&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält Metadaten zur Verwaltung der Daten und stellt sicher, dass die Übertragung korrekt erfolgt.&lt;br /&gt;
** &#039;&#039;&#039;Version (1 Byte):&#039;&#039;&#039; Gibt die Version des Frame-Formats an.&lt;br /&gt;
** &#039;&#039;&#039;Body Length (4 Byte):&#039;&#039;&#039; Speichert die Größe des Frame-Bodies in Byte.&lt;br /&gt;
** &#039;&#039;&#039;Checksum (4 Byte):&#039;&#039;&#039; Eine Prüfsumme zur Validierung der übertragenen Daten.&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Body&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält die eigentlichen Simulationsdaten.&lt;br /&gt;
** &#039;&#039;&#039;Time Index (4 Byte):&#039;&#039;&#039; Gibt an, zu welchem Zeitschritt der Frame gehört.&lt;br /&gt;
** &#039;&#039;&#039;Shape (4 + 4 Byte):&#039;&#039;&#039; Speichert die Dimensionen des Datenfeldes (Anzahl der Zeilen und Spalten).&lt;br /&gt;
** &#039;&#039;&#039;Normierung:&#039;&#039;&#039; Jeder Wert wird normalisiert, indem der minimale Wert und ein Divider berechnet werden. Falls das Maximum gleich dem Minimum ist, wird der Divider auf 1 gesetzt, um eine Division durch Null zu vermeiden.&lt;br /&gt;
** &#039;&#039;&#039;Datenfelder (3 × ROWS × COLUMNS × 1 Byte):&#039;&#039;&#039; Enthält die Werte für Dichte, vx1 und vx2.&lt;br /&gt;
&lt;br /&gt;
Da eine Simulation viele Zeitschritte umfasst, werden die Frames in einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst:&lt;br /&gt;
&lt;br /&gt;
* Ein &#039;&#039;&#039;Batch&#039;&#039;&#039; enthält mehrere Frames hintereinander, sodass mehrere Zeitschritte in einer einzigen Übertragung gesendet werden können.&lt;br /&gt;
* Vor dem Versand kann die Batch mit &#039;&#039;&#039;LZ4&#039;&#039;&#039; komprimiert, um die Datenmenge zu reduzieren.&lt;br /&gt;
* Auf der Client-Seite werden die Daten nach dem Empfang &#039;&#039;&#039;dekomprimiert und decodiert&#039;&#039;&#039;, bevor sie für die Visualisierung genutzt werden können.&lt;br /&gt;
&lt;br /&gt;
== Performance Untersuchung (&amp;lt;small&amp;gt;In Bearbeitung&amp;lt;/small&amp;gt;)==&lt;br /&gt;
Nachdem eine erste Version mit allen wichtigen Features implementiert wurde, wurden einige Messungen zur Performance durchgeführt, die in diesem Abschnitt zusammengefasst werden. &lt;br /&gt;
&lt;br /&gt;
# &#039;&#039;&#039;Lesen (~400 MB/s):&#039;&#039;&#039; Das Einlesen einer Double-Datei in ein Numpy-Array durch PlutoPlot.&lt;br /&gt;
# &#039;&#039;&#039;Zu Byte-Str (~360 MB/s):&#039;&#039;&#039; Die Konvertierung des Numpy-Float-Arrays nach dem Einlesen in ein UInt8-Array, anschließend die Umwandlung in eine Byte-Str und das Aneinanderhängen dieser.&lt;br /&gt;
# &#039;&#039;&#039;Frames Erstellen (~100 MB/s):&#039;&#039;&#039; Der gesamte Prozess vom Laden der Daten bis zur vollständigen Konvertierung in das zuvor beschriebene Datenformat.&lt;br /&gt;
# ..... &#039;&#039;&#039;(Netzwerk:&#039;&#039;&#039; Die theoretisch mögliche Geschwindigkeit im Uni-Netzwerk liegt bei circa &#039;&#039;&#039;30 MB/s&#039;&#039;&#039;) ......&lt;br /&gt;
# &#039;&#039;&#039;Im Browser (~7 MB/s):&#039;&#039;&#039; Bei der genutzten Frame-Größe ergibt sich eine unkomprimierte Wiedergabe von etwa &#039;&#039;&#039;22 Frames pro Sekunde&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
.... in Bearbeitung ....&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;**&amp;lt;/nowiki&amp;gt;TODO**&lt;br /&gt;
&lt;br /&gt;
- Test mit pyinstrument auf Uni server zum vergleich zu meinen Laptop&lt;br /&gt;
&lt;br /&gt;
=Wahl des GUI-Frameworks  ✅=&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
==ThreeJS==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
===ThreeJS Prototyp===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
===ThreeJS 2.0===&lt;br /&gt;
&lt;br /&gt;
Für das Windtunnel-Projekt wurde mittlerweile ein grundlegendes Framework auf Basis von Three.js entwickelt, das verschiedene Simulationen visuell darstellen kann. Der Fokus lag dabei auf einem flexiblen und modularen Aufbau, der es ermöglicht, zukünftige Erweiterungen und Anpassungen einfacher umzusetzen. Eine genauere Erklärung sowie einige technische Hintergründe sind im Abschnitt &#039;&#039;&#039;&#039;&#039;Windtunnel-Online-GUI&#039;&#039;&#039;&#039;&#039; beschrieben.&lt;br /&gt;
&lt;br /&gt;
Mit diesem Schritt ist die &#039;&#039;&#039;Wahl des GUI-Frameworks vorerst abgeschlossen&#039;&#039;&#039;, sodass der Fokus nun auf Optimierungen und die Weiterentwicklung einiger wichtiger Features gelegt werden kann.&lt;br /&gt;
&lt;br /&gt;
==Streamlit==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
===Streamlit Prototyp===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
==H5P==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=714</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=714"/>
		<updated>2025-02-18T23:49:08Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
== Struktureller Aufbau ==&lt;br /&gt;
Die Windtunnel-Online-GUI ist dafür entwickelt worden, um durch &#039;&#039;PLUTO&#039;&#039; generierte Simulationsdatensätze effizient in einer Webanwendung darzustellen. Die Herausforderung dabei liegt in der Größe der Datensätze, die oft sehr umfangreich sind. Diese müssen so aufbereitet werden, dass sie auf einer Website sinnvoll visualisiert werden können, ohne dass es zu langen Ladezeiten oder Performance-Problemen kommt.&lt;br /&gt;
&lt;br /&gt;
Das Problem ist daher in zwei zentrale Bereiche unterteilt:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Server-Side:&#039;&#039;&#039; Hier sind die vollständigen Datensätze aus &#039;&#039;PLUTO&#039;&#039; gespeichert. Die Hauptaufgabe besteht darin, diese Daten effizient zu verwalten, in einem geeigneten Format aufzubereiten und auf Anfrage an den Client zu senden.&lt;br /&gt;
* &#039;&#039;&#039;Client-Side:&#039;&#039;&#039; Auf der Client-Seite werden die vorbereiteten Daten empfangen, dekomprimiert und visuell dargestellt. Zudem gibt es eine Benutzeroberfläche, über die verschiedene Parameter angepasst werden können. Ändert der Nutzer eine Einstellung, müssen neue Daten vom Server angefordert werden, um die Visualisierung entsprechend zu aktualisieren.&lt;br /&gt;
&lt;br /&gt;
Die folgende Grafik gibt einen Überblick über den strukturellen Aufbau und die Interaktion dieser Komponenten:&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
=== Client Side ===&lt;br /&gt;
..... in Bearbeitung ...&lt;br /&gt;
&lt;br /&gt;
=== Sever Side ===&lt;br /&gt;
... in Bearbeitung ....&lt;br /&gt;
&lt;br /&gt;
== Datenformat ==&lt;br /&gt;
Für jeden Zeitschritt werden drei physikalische Felder – das betrachtete Feld (z. B. Dichte) sowie die Geschwindigkeitskomponenten vx1 und vx2 – in einem &#039;&#039;&#039;Frame&#039;&#039;&#039; versendet. Mehrere dieser Frames werden zu einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst, sodass mehrere Zeitschritte effizient in einer einzigen Nachricht übertragen werden können. Die folgende Grafik zeigt den Aufbau eines solchen Frame-Batches:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:WINDTUNNEL GUI Frame Batch Diagram.jpg|border|frameless|964x964px]]&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Frame&#039;&#039;&#039; besteht aus zwei Hauptteilen:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Header&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält Metadaten zur Verwaltung der Daten und stellt sicher, dass die Übertragung korrekt erfolgt.&lt;br /&gt;
** &#039;&#039;&#039;Version (1 Byte):&#039;&#039;&#039; Gibt die Version des Frame-Formats an.&lt;br /&gt;
** &#039;&#039;&#039;Body Length (4 Byte):&#039;&#039;&#039; Speichert die Größe des Frame-Bodies in Byte.&lt;br /&gt;
** &#039;&#039;&#039;Checksum (4 Byte):&#039;&#039;&#039; Eine Prüfsumme zur Validierung der übertragenen Daten.&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Body&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält die eigentlichen Simulationsdaten.&lt;br /&gt;
** &#039;&#039;&#039;Time Index (4 Byte):&#039;&#039;&#039; Gibt an, zu welchem Zeitschritt der Frame gehört.&lt;br /&gt;
** &#039;&#039;&#039;Shape (4 + 4 Byte):&#039;&#039;&#039; Speichert die Dimensionen des Datenfeldes (Anzahl der Zeilen und Spalten).&lt;br /&gt;
** &#039;&#039;&#039;Normierung:&#039;&#039;&#039; Jeder Wert wird normalisiert, indem der minimale Wert und ein Divider berechnet werden. Falls das Maximum gleich dem Minimum ist, wird der Divider auf 1 gesetzt, um eine Division durch Null zu vermeiden.&lt;br /&gt;
** &#039;&#039;&#039;Datenfelder (3 × ROWS × COLUMNS × 1 Byte):&#039;&#039;&#039; Enthält die Werte für Dichte, vx1 und vx2.&lt;br /&gt;
&lt;br /&gt;
Da eine Simulation viele Zeitschritte umfasst, werden die Frames in einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst:&lt;br /&gt;
&lt;br /&gt;
* Ein &#039;&#039;&#039;Batch&#039;&#039;&#039; enthält mehrere Frames hintereinander, sodass mehrere Zeitschritte in einer einzigen Übertragung gesendet werden können.&lt;br /&gt;
* Vor dem Versand kann die Batch mit &#039;&#039;&#039;LZ4&#039;&#039;&#039; komprimiert, um die Datenmenge zu reduzieren.&lt;br /&gt;
* Auf der Client-Seite werden die Daten nach dem Empfang &#039;&#039;&#039;dekomprimiert und decodiert&#039;&#039;&#039;, bevor sie für die Visualisierung genutzt werden können.&lt;br /&gt;
&lt;br /&gt;
== Performance Untersuchung (&amp;lt;small&amp;gt;In Bearbeitung&amp;lt;/small&amp;gt;)==&lt;br /&gt;
Nachdem eine erste Version mit allen wichtigen Features implementiert wurde, wurden einige Messungen zur Performance durchgeführt, die in diesem Abschnitt zusammengefasst werden. &lt;br /&gt;
&lt;br /&gt;
# &#039;&#039;&#039;Lesen (~400 MB/s):&#039;&#039;&#039; Das Einlesen einer Double-Datei in ein Numpy-Array durch PlutoPlot.&lt;br /&gt;
# &#039;&#039;&#039;Zu Byte-Str (~360 MB/s):&#039;&#039;&#039; Die Konvertierung des Numpy-Float-Arrays nach dem Einlesen in ein UInt8-Array, anschließend die Umwandlung in eine Byte-Str und das Aneinanderhängen dieser.&lt;br /&gt;
# &#039;&#039;&#039;Frames Erstellen (~100 MB/s):&#039;&#039;&#039; Der gesamte Prozess vom Laden der Daten bis zur vollständigen Konvertierung in das zuvor beschriebene Datenformat.&lt;br /&gt;
# ..... &#039;&#039;&#039;(Netzwerk:&#039;&#039;&#039; Die theoretisch mögliche Geschwindigkeit im Uni-Netzwerk liegt bei circa &#039;&#039;&#039;30 MB/s&#039;&#039;&#039;) ......&lt;br /&gt;
# &#039;&#039;&#039;Im Browser (~7 MB/s):&#039;&#039;&#039; Bei der genutzten Frame-Größe ergibt sich eine unkomprimierte Wiedergabe von etwa &#039;&#039;&#039;22 Frames pro Sekunde&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
.... in Bearbeitung ....&lt;br /&gt;
&lt;br /&gt;
&amp;lt;nowiki&amp;gt;**&amp;lt;/nowiki&amp;gt;TODO**&lt;br /&gt;
&lt;br /&gt;
- Test mit pyinstrument auf Uni server zum vergleich zu meinen Laptop&lt;br /&gt;
&lt;br /&gt;
=Wahl des GUI-Frameworks  ✅=&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
==ThreeJS==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
===ThreeJS Prototyp===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
===ThreeJS 2.0===&lt;br /&gt;
&lt;br /&gt;
Für das Windtunnel-Projekt wurde mittlerweile ein grundlegendes Framework auf Basis von Three.js entwickelt, das verschiedene Simulationen visuell darstellen kann. Der Fokus lag dabei auf einem flexiblen und modularen Aufbau, der es ermöglicht, zukünftige Erweiterungen und Anpassungen einfacher umzusetzen. Eine genauere Erklärung sowie einige technische Hintergründe sind im Abschnitt &#039;&#039;&#039;&#039;&#039;Windtunnel-Online-GUI&#039;&#039;&#039;&#039;&#039; beschrieben.&lt;br /&gt;
&lt;br /&gt;
Mit diesem Schritt ist die &#039;&#039;&#039;Wahl des GUI-Frameworks vorerst abgeschlossen&#039;&#039;&#039;, sodass der Fokus nun auf Optimierungen und die Weiterentwicklung einiger wichtiger Features gelegt werden kann.&lt;br /&gt;
&lt;br /&gt;
==Streamlit==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
===Streamlit Prototyp===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
==H5P==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=713</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=713"/>
		<updated>2025-02-15T11:42:16Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Data Format Update + Begin off other chapters&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
== Struktureller Aufbau ==&lt;br /&gt;
Die Windtunnel-Online-GUI ist dafür entwickelt worden, um durch &#039;&#039;PLUTO&#039;&#039; generierte Simulationsdatensätze effizient in einer Webanwendung darzustellen. Die Herausforderung dabei liegt in der Größe der Datensätze, die oft sehr umfangreich sind. Diese müssen so aufbereitet werden, dass sie auf einer Website sinnvoll visualisiert werden können, ohne dass es zu langen Ladezeiten oder Performance-Problemen kommt.&lt;br /&gt;
&lt;br /&gt;
Das Problem ist daher in zwei zentrale Bereiche unterteilt:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Server-Side:&#039;&#039;&#039; Hier sind die vollständigen Datensätze aus &#039;&#039;PLUTO&#039;&#039; gespeichert. Die Hauptaufgabe besteht darin, diese Daten effizient zu verwalten, in einem geeigneten Format aufzubereiten und auf Anfrage an den Client zu senden.&lt;br /&gt;
* &#039;&#039;&#039;Client-Side:&#039;&#039;&#039; Auf der Client-Seite werden die vorbereiteten Daten empfangen, dekomprimiert und visuell dargestellt. Zudem gibt es eine Benutzeroberfläche, über die verschiedene Parameter angepasst werden können. Ändert der Nutzer eine Einstellung, müssen neue Daten vom Server angefordert werden, um die Visualisierung entsprechend zu aktualisieren.&lt;br /&gt;
&lt;br /&gt;
Die folgende Grafik gibt einen Überblick über den strukturellen Aufbau und die Interaktion dieser Komponenten:&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
=== Client Side ===&lt;br /&gt;
..... in Bearbeitung ...&lt;br /&gt;
&lt;br /&gt;
=== Sever Side ===&lt;br /&gt;
... in Bearbeitung ....&lt;br /&gt;
&lt;br /&gt;
== Datenformat ==&lt;br /&gt;
Für jeden Zeitschritt werden drei physikalische Felder – das betrachtete Feld (z. B. Dichte) sowie die Geschwindigkeitskomponenten vx1 und vx2 – in einem &#039;&#039;&#039;Frame&#039;&#039;&#039; versendet. Mehrere dieser Frames werden zu einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst, sodass mehrere Zeitschritte effizient in einer einzigen Nachricht übertragen werden können. Die folgende Grafik zeigt den Aufbau eines solchen Frame-Batches:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:WINDTUNNEL GUI Frame Batch Diagram.jpg|border|frameless|964x964px]]&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Frame&#039;&#039;&#039; besteht aus zwei Hauptteilen:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Header&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält Metadaten zur Verwaltung der Daten und stellt sicher, dass die Übertragung korrekt erfolgt.&lt;br /&gt;
** &#039;&#039;&#039;Version (1 Byte):&#039;&#039;&#039; Gibt die Version des Frame-Formats an.&lt;br /&gt;
** &#039;&#039;&#039;Body Length (4 Byte):&#039;&#039;&#039; Speichert die Größe des Frame-Bodies in Byte.&lt;br /&gt;
** &#039;&#039;&#039;Checksum (4 Byte):&#039;&#039;&#039; Eine Prüfsumme zur Validierung der übertragenen Daten.&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Body&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält die eigentlichen Simulationsdaten.&lt;br /&gt;
** &#039;&#039;&#039;Time Index (4 Byte):&#039;&#039;&#039; Gibt an, zu welchem Zeitschritt der Frame gehört.&lt;br /&gt;
** &#039;&#039;&#039;Shape (4 + 4 Byte):&#039;&#039;&#039; Speichert die Dimensionen des Datenfeldes (Anzahl der Zeilen und Spalten).&lt;br /&gt;
** &#039;&#039;&#039;Normierung:&#039;&#039;&#039; Jeder Wert wird normalisiert, indem der minimale Wert und ein Divider berechnet werden. Falls das Maximum gleich dem Minimum ist, wird der Divider auf 1 gesetzt, um eine Division durch Null zu vermeiden.&lt;br /&gt;
** &#039;&#039;&#039;Datenfelder (3 × ROWS × COLUMNS × 1 Byte):&#039;&#039;&#039; Enthält die Werte für Dichte, vx1 und vx2.&lt;br /&gt;
&lt;br /&gt;
Da eine Simulation viele Zeitschritte umfasst, werden die Frames in einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst:&lt;br /&gt;
&lt;br /&gt;
* Ein &#039;&#039;&#039;Batch&#039;&#039;&#039; enthält mehrere Frames hintereinander, sodass mehrere Zeitschritte in einer einzigen Übertragung gesendet werden können.&lt;br /&gt;
* Vor dem Versand kann die Batch mit &#039;&#039;&#039;LZ4&#039;&#039;&#039; komprimiert, um die Datenmenge zu reduzieren.&lt;br /&gt;
* Auf der Client-Seite werden die Daten nach dem Empfang &#039;&#039;&#039;dekomprimiert und decodiert&#039;&#039;&#039;, bevor sie für die Visualisierung genutzt werden können.&lt;br /&gt;
&lt;br /&gt;
== Performance Untersuchung (&amp;lt;small&amp;gt;In Bearbeitung&amp;lt;/small&amp;gt;)==&lt;br /&gt;
Nachdem eine erste Version mit allen wichtigen Features implementiert wurde, wurden einige Messungen zur Performance durchgeführt, die in diesem Abschnitt zusammengefasst werden. &lt;br /&gt;
&lt;br /&gt;
# &#039;&#039;&#039;Lesen (~400 MB/s):&#039;&#039;&#039; Das Einlesen einer Double-Datei in ein Numpy-Array durch PlutoPlot.&lt;br /&gt;
# &#039;&#039;&#039;Zu Byte-Str (~360 MB/s):&#039;&#039;&#039; Die Konvertierung des Numpy-Float-Arrays nach dem Einlesen in ein UInt8-Array, anschließend die Umwandlung in eine Byte-Str und das Aneinanderhängen dieser.&lt;br /&gt;
# &#039;&#039;&#039;Frames Erstellen (~100 MB/s):&#039;&#039;&#039; Der gesamte Prozess vom Laden der Daten bis zur vollständigen Konvertierung in das zuvor beschriebene Datenformat.&lt;br /&gt;
# ..... &#039;&#039;&#039;(Netzwerk:&#039;&#039;&#039; Die theoretisch mögliche Geschwindigkeit im Uni-Netzwerk liegt bei circa &#039;&#039;&#039;30 MB/s&#039;&#039;&#039;) ......&lt;br /&gt;
# &#039;&#039;&#039;Im Browser (~7 MB/s):&#039;&#039;&#039; Bei der genutzten Frame-Größe ergibt sich eine unkomprimierte Wiedergabe von etwa &#039;&#039;&#039;22 Frames pro Sekunde&#039;&#039;&#039;.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
.... in Bearbeitung ....&lt;br /&gt;
&lt;br /&gt;
=Wahl des GUI-Frameworks  ✅=&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
==ThreeJS==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
===ThreeJS Prototyp===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
===ThreeJS 2.0===&lt;br /&gt;
&lt;br /&gt;
Für das Windtunnel-Projekt wurde mittlerweile ein grundlegendes Framework auf Basis von Three.js entwickelt, das verschiedene Simulationen visuell darstellen kann. Der Fokus lag dabei auf einem flexiblen und modularen Aufbau, der es ermöglicht, zukünftige Erweiterungen und Anpassungen einfacher umzusetzen. Eine genauere Erklärung sowie einige technische Hintergründe sind im Abschnitt &#039;&#039;&#039;&#039;&#039;Windtunnel-Online-GUI&#039;&#039;&#039;&#039;&#039; beschrieben.&lt;br /&gt;
&lt;br /&gt;
Mit diesem Schritt ist die &#039;&#039;&#039;Wahl des GUI-Frameworks vorerst abgeschlossen&#039;&#039;&#039;, sodass der Fokus nun auf Optimierungen und die Weiterentwicklung einiger wichtiger Features gelegt werden kann.&lt;br /&gt;
&lt;br /&gt;
==Streamlit==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
===Streamlit Prototyp===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
==H5P==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=712</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=712"/>
		<updated>2025-02-14T20:39:13Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Daten Format Update&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
== Struktureller Aufbau ==&lt;br /&gt;
Die Windtunnel-Online-GUI ist dafür entwickelt worden, um durch &#039;&#039;PLUTO&#039;&#039; generierte Simulationsdatensätze effizient in einer Webanwendung darzustellen. Die Herausforderung dabei liegt in der Größe der Datensätze, die oft sehr umfangreich sind. Diese müssen so aufbereitet werden, dass sie auf einer Website sinnvoll visualisiert werden können, ohne dass es zu langen Ladezeiten oder Performance-Problemen kommt.&lt;br /&gt;
&lt;br /&gt;
Das Problem ist daher in zwei zentrale Bereiche unterteilt:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Server-Side:&#039;&#039;&#039; Hier sind die vollständigen Datensätze aus &#039;&#039;PLUTO&#039;&#039; gespeichert. Die Hauptaufgabe besteht darin, diese Daten effizient zu verwalten, in einem geeigneten Format aufzubereiten und auf Anfrage an den Client zu senden.&lt;br /&gt;
* &#039;&#039;&#039;Client-Side:&#039;&#039;&#039; Auf der Client-Seite werden die vorbereiteten Daten empfangen, dekomprimiert und visuell dargestellt. Zudem gibt es eine Benutzeroberfläche, über die verschiedene Parameter angepasst werden können. Ändert der Nutzer eine Einstellung, müssen neue Daten vom Server angefordert werden, um die Visualisierung entsprechend zu aktualisieren.&lt;br /&gt;
&lt;br /&gt;
Die folgende Grafik gibt einen Überblick über den strukturellen Aufbau und die Interaktion dieser Komponenten:&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
== Datenformat ==&lt;br /&gt;
Für jeden Zeitschritt werden drei physikalische Felder – das betrachtete Feld (z. B. Dichte) sowie die Geschwindigkeitskomponenten vx1 und vx2 – in einem &#039;&#039;&#039;Frame&#039;&#039;&#039; versendet. Mehrere dieser Frames werden zu einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst, sodass mehrere Zeitschritte effizient in einer einzigen Nachricht übertragen werden können. Die folgende Grafik zeigt den Aufbau eines solchen Frame-Batches:&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:WINDTUNNEL GUI Frame Batch Diagram.jpg|border|frameless|964x964px]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Frame&#039;&#039;&#039; besteht aus zwei Hauptteilen:&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Header&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält Metadaten zur Verwaltung der Daten und stellt sicher, dass die Übertragung korrekt erfolgt.&lt;br /&gt;
** &#039;&#039;&#039;Version (1 Byte):&#039;&#039;&#039; Gibt die Version des Frame-Formats an.&lt;br /&gt;
** &#039;&#039;&#039;Body Length (4 Byte):&#039;&#039;&#039; Speichert die Größe des Frame-Bodies in Byte.&lt;br /&gt;
** &#039;&#039;&#039;Checksum (4 Byte):&#039;&#039;&#039; Eine Prüfsumme zur Validierung der übertragenen Daten.&lt;br /&gt;
* &#039;&#039;&#039;&amp;lt;u&amp;gt;Body&amp;lt;/u&amp;gt;:&#039;&#039;&#039; Enthält die eigentlichen Simulationsdaten.&lt;br /&gt;
** &#039;&#039;&#039;Time Index (4 Byte):&#039;&#039;&#039; Gibt an, zu welchem Zeitschritt der Frame gehört.&lt;br /&gt;
** &#039;&#039;&#039;Shape (4 + 4 Byte):&#039;&#039;&#039; Speichert die Dimensionen des Datenfeldes (Anzahl der Zeilen und Spalten).&lt;br /&gt;
** &#039;&#039;&#039;Normierung:&#039;&#039;&#039; Jeder Wert wird normalisiert, indem der minimale Wert und ein Divider berechnet werden. Falls das Maximum gleich dem Minimum ist, wird der Divider auf 1 gesetzt, um eine Division durch Null zu vermeiden.&lt;br /&gt;
** &#039;&#039;&#039;Datenfelder (3 × ROWS × COLUMNS × 1 Byte):&#039;&#039;&#039; Enthält die Werte für Dichte, vx1 und vx2.&lt;br /&gt;
&lt;br /&gt;
Da eine Simulation viele Zeitschritte umfasst, werden die Frames in einem &#039;&#039;&#039;Batch&#039;&#039;&#039; zusammengefasst:&lt;br /&gt;
&lt;br /&gt;
* Ein &#039;&#039;&#039;Batch&#039;&#039;&#039; enthält mehrere Frames hintereinander, sodass mehrere Zeitschritte in einer einzigen Übertragung gesendet werden können.&lt;br /&gt;
* Vor dem Versand kann die Batch mit &#039;&#039;&#039;LZ4&#039;&#039;&#039; komprimiert, um die Datenmenge zu reduzieren.&lt;br /&gt;
* Auf der Client-Seite werden die Daten nach dem Empfang &#039;&#039;&#039;dekomprimiert und decodiert&#039;&#039;&#039;, bevor sie für die Visualisierung genutzt werden können.&lt;br /&gt;
&lt;br /&gt;
== Wichtige Punkte TODO ==&lt;br /&gt;
&lt;br /&gt;
* Wie sieht das Datenformat fürs Senden aus&lt;br /&gt;
** Gründe der Wahl&lt;br /&gt;
* Welche Struktur hat der Code der Client Visualisierung&lt;br /&gt;
** Modularer Aufbau für zukünftige Features und Maintainability&lt;br /&gt;
** Fehlersuche vereinfachen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Wahl des GUI-Frameworks  ✅ =&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
== ThreeJS ==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS 2.0 ===&lt;br /&gt;
&lt;br /&gt;
Für das Windtunnel-Projekt wurde mittlerweile ein grundlegendes Framework auf Basis von Three.js entwickelt, das verschiedene Simulationen visuell darstellen kann. Der Fokus lag dabei auf einem flexiblen und modularen Aufbau, der es ermöglicht, zukünftige Erweiterungen und Anpassungen einfacher umzusetzen. Eine genauere Erklärung sowie einige technische Hintergründe sind im Abschnitt &#039;&#039;&#039;&#039;&#039;Windtunnel-Online-GUI&#039;&#039;&#039;&#039;&#039; beschrieben.&lt;br /&gt;
&lt;br /&gt;
Mit diesem Schritt ist die &#039;&#039;&#039;Wahl des GUI-Frameworks vorerst abgeschlossen&#039;&#039;&#039;, sodass der Fokus nun auf Optimierungen und die Weiterentwicklung einiger wichtiger Features gelegt werden kann.&lt;br /&gt;
&lt;br /&gt;
== Streamlit ==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
=== Streamlit Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
== H5P ==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:WINDTUNNEL_GUI_Frame_Batch_Diagram.jpg&amp;diff=711</id>
		<title>File:WINDTUNNEL GUI Frame Batch Diagram.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:WINDTUNNEL_GUI_Frame_Batch_Diagram.jpg&amp;diff=711"/>
		<updated>2025-02-14T20:34:14Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Grafik die den Aufbau einer Frame Batch zeigt.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=710</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=710"/>
		<updated>2025-02-14T19:20:25Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Wahl des GUI-Frameworks fertig&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
Die Grafik zeigt den Aufbau und die Interaktion der verschiedenen Komponenten der Windtunnel-Online-GUI. Sie ist in zwei Hauptbereiche unterteilt: die Server-Seite und die Client-Seite, die jeweils unterschiedliche Aufgaben übernehmen.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
== Datenformat ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#0000FF&amp;quot;&amp;gt;&lt;br /&gt;
In Bearbeitung und grade nur Notizen:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Für jeden Output der Simulation kann ein sogenannter Frame erstellt werden. Dieser Frame soll das betrachtete Feld (z. B. Dichtefeld) und die Geschwindigkeitsfelder in x- und y-Richtung für einen gegebenen zeitlichen Index enthalten. Ein solcher Frame wird bearbeitet und anschließend in binärer Form versendet. Der Aufbau ist dabei wie folgt:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Frame = header + frame_data &lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
header = Byte {Version} + UInt32 {Länge eines frame_data in byte} + UInt32 {Checksum Validieren der übertragenen Daten}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
frame_data = UInt32 {TimeIndex} + UInt32(2) {Shape = [ROWS, COLS]} + 3 * field_data&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
field_data = Float32 {min(feld)} + Float(32) {divider = (a_max - a_min) if a_max != a_min else 1} + UInt8(ROWS * COLS) {Feld Daten}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Diese Frames werden dann in einem Batch angefragt. Für eine Anzahl von N Zeitpunkten wird eine Anfrage gestellt. Für die jeweiligen Zeitpunkte wird dann ein Frame erstellt. Alle Frames werden anschließend in einer binären Nachricht hintereinander angeordnet (Batch). Die Nachricht wird dann mit LZ4 komprimiert und versendet. Also:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Batch = N * Frame&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Auf der Client seite kann dann zunächst dekompremiert werden und dann decoded.&lt;br /&gt;
&lt;br /&gt;
== Wichtige Punkte TODO ==&lt;br /&gt;
&lt;br /&gt;
* Wie sieht das Datenformat fürs Senden aus&lt;br /&gt;
** Gründe der Wahl&lt;br /&gt;
* Welche Struktur hat der Code der Client Visualisierung&lt;br /&gt;
** Modularer Aufbau für zukünftige Features und Maintainability&lt;br /&gt;
** Fehlersuche vereinfachen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Wahl des GUI-Frameworks  ✅ =&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
== ThreeJS ==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS 2.0 ===&lt;br /&gt;
&lt;br /&gt;
Für das Windtunnel-Projekt wurde mittlerweile ein grundlegendes Framework auf Basis von Three.js entwickelt, das verschiedene Simulationen visuell darstellen kann. Der Fokus lag dabei auf einem flexiblen und modularen Aufbau, der es ermöglicht, zukünftige Erweiterungen und Anpassungen einfacher umzusetzen. Eine genauere Erklärung sowie einige technische Hintergründe sind im Abschnitt &#039;&#039;&#039;&#039;&#039;Windtunnel-Online-GUI&#039;&#039;&#039;&#039;&#039; beschrieben.&lt;br /&gt;
&lt;br /&gt;
Mit diesem Schritt ist die &#039;&#039;&#039;Wahl des GUI-Frameworks vorerst abgeschlossen&#039;&#039;&#039;, sodass der Fokus nun auf Optimierungen und die Weiterentwicklung einiger wichtiger Features gelegt werden kann.&lt;br /&gt;
&lt;br /&gt;
== Streamlit ==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
=== Streamlit Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
== H5P ==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=693</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=693"/>
		<updated>2024-10-30T15:44:10Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Notizen fürs Datenformat&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
Die Grafik zeigt den Aufbau und die Interaktion der verschiedenen Komponenten der Windtunnel-Online-GUI. Sie ist in zwei Hauptbereiche unterteilt: die Server-Seite und die Client-Seite, die jeweils unterschiedliche Aufgaben übernehmen.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
== Datenformat ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:#0000FF&amp;quot;&amp;gt;&lt;br /&gt;
In Bearbeitung und grade nur Notizen:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Für jeden Output der Simulation kann ein sogenannter Frame erstellt werden. Dieser Frame soll das betrachtete Feld (z. B. Dichtefeld) und die Geschwindigkeitsfelder in x- und y-Richtung für einen gegebenen zeitlichen Index enthalten. Ein solcher Frame wird bearbeitet und anschließend in binärer Form versendet. Der Aufbau ist dabei wie folgt:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Frame = header + frame_data &lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
header = Byte {Version} + UInt32 {Länge eines frame_data in byte} + UInt32 {Checksum Validieren der übertragenen Daten}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
frame_data = UInt32 {TimeIndex} + UInt32(2) {Shape = [ROWS, COLS]} + 3 * field_data&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
field_data = Float32 {min(feld)} + Float(32) {divider = (a_max - a_min) if a_max != a_min else 1} + UInt8(ROWS * COLS) {Feld Daten}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Diese Frames werden dann in einem Batch angefragt. Für eine Anzahl von N Zeitpunkten wird eine Anfrage gestellt. Für die jeweiligen Zeitpunkte wird dann ein Frame erstellt. Alle Frames werden anschließend in einer binären Nachricht hintereinander angeordnet (Batch). Die Nachricht wird dann mit LZ4 komprimiert und versendet. Also:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Batch = N * Frame&lt;br /&gt;
&lt;br /&gt;
&amp;lt;span style=&amp;quot;color:red&amp;quot;&amp;gt;&lt;br /&gt;
Auf der Client seite kann dann zunächst dekompremiert werden und dann decoded.&lt;br /&gt;
&lt;br /&gt;
== Wichtige Punkte TODO ==&lt;br /&gt;
&lt;br /&gt;
* Wie sieht das Datenformat fürs Senden aus&lt;br /&gt;
** Gründe der Wahl&lt;br /&gt;
* Welche Struktur hat der Code der Client Visualisierung&lt;br /&gt;
** Modularer Aufbau für zukünftige Features und Maintainability&lt;br /&gt;
** Fehlersuche vereinfachen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Wahl des GUI-Frameworks =&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
== ThreeJS ==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS 2.0 ===&lt;br /&gt;
&lt;br /&gt;
Zu jetztigen Zeitpunkt gilt es für das Windtunnel Projekt ein Framework zu erstellen, mit welchen verschiedenste Experimente im Online-Windtunnel darstellen zu können. Grundlegende Ideen werden dazu im Abschnitt &amp;quot;Windtunnel-Online-GUI&amp;quot; erklärt&lt;br /&gt;
&lt;br /&gt;
== Streamlit ==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
=== Streamlit Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
== H5P ==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windtunnel_online&amp;diff=691</id>
		<title>Windtunnel online</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windtunnel_online&amp;diff=691"/>
		<updated>2024-10-29T12:37:21Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: streamlit -&amp;gt; threes&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;vom [https://www.uni-due.de/zhqe/foerderprogr_lehr-lern-inno.php LLI-Programm] gefördertes Projekt „Windkanal Online“&lt;br /&gt;
&lt;br /&gt;
= Ziele =&lt;br /&gt;
&lt;br /&gt;
# belt/PLUTO kann alle relevanten [[Windtunnel/Boundary Conditions|Randbedingungen]] rechnen.&lt;br /&gt;
# belt/PLUTO erzeugt einen großen Datensatz an Ergebnissen (Felder) für verschiedene Parameter&lt;br /&gt;
# Ein [[Windkanal/GUI|GUI]] (&#039;&#039;ThreeJS&#039;&#039;) kann die Datensätze interaktiv darstellen.&lt;br /&gt;
# Integration des GUIs in Moodle&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* Modifikation von belt/PLUTO und Tests der Modifikationen:&lt;br /&gt;
** Tests der Randbedingungen für die Wände&lt;br /&gt;
** Tests der Randbedingungen am angeströmten Objekt &lt;br /&gt;
* Geeignetes GUI finden, [https://h5p.org H5P] ist schon in Moodle integriert.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=690</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=690"/>
		<updated>2024-10-29T12:27:32Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Beginn Hauptabschnitt &amp;quot;Windtunnel-Online-GUI&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
Die Grafik zeigt den Aufbau und die Interaktion der verschiedenen Komponenten der Windtunnel-Online-GUI. Sie ist in zwei Hauptbereiche unterteilt: die Server-Seite und die Client-Seite, die jeweils unterschiedliche Aufgaben übernehmen.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui konzept 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
== Wichtige Punkte TODO ==&lt;br /&gt;
&lt;br /&gt;
* Wie sieht das Datenformat fürs Senden aus&lt;br /&gt;
** Gründe der Wahl&lt;br /&gt;
* Welche Struktur hat der Code der Client Visualisierung&lt;br /&gt;
** Modularer Aufbau für zukünftige Features und Maintainability&lt;br /&gt;
** Fehlersuche vereinfachen&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Wahl des GUI-Frameworks =&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
== ThreeJS ==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS 2.0 ===&lt;br /&gt;
&lt;br /&gt;
Zu jetztigen Zeitpunkt gilt es für das Windtunnel Projekt ein Framework zu erstellen, mit welchen verschiedenste Experimente im Online-Windtunnel darstellen zu können. Grundlegende Ideen werden dazu im Abschnitt &amp;quot;Windtunnel-Online-GUI&amp;quot; erklärt&lt;br /&gt;
&lt;br /&gt;
== Streamlit ==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
=== Streamlit Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
== H5P ==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_konzept_1.png&amp;diff=689</id>
		<title>File:Windtunnel online gui konzept 1.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_konzept_1.png&amp;diff=689"/>
		<updated>2024-10-29T12:16:45Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Fynn.W uploaded a new version of File:Windtunnel online gui konzept 1.png&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Konzept Bild für den Aufbau der GUI&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_konzept_1.png&amp;diff=688</id>
		<title>File:Windtunnel online gui konzept 1.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_konzept_1.png&amp;diff=688"/>
		<updated>2024-10-29T12:12:00Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Konzept Bild für den Aufbau der GUI&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=687</id>
		<title>Windkanal/GUI</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windkanal/GUI&amp;diff=687"/>
		<updated>2024-10-29T10:52:34Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: ThreeJS + Prototypen + Updates&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[Windkanal online|up]]&lt;br /&gt;
&lt;br /&gt;
= Windtunnel-Online-GUI =&lt;br /&gt;
&lt;br /&gt;
todo&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Wahl des GUI-Frameworks =&lt;br /&gt;
&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
== ThreeJS ==&lt;br /&gt;
&lt;br /&gt;
Three.js ist eine JavaScript-Bibliothek, die zur Erstellung und Darstellung von 3D-Grafiken im Webbrowser genutzt werden kann. Mithilfe von Three.js werden Datenfelder direkt im Browser visualisiert, was eine interaktive und ansprechende Darstellung ermöglicht. Der Browser erhält die benötigten Datenfelder von einem Server, der ausschließlich für die Verarbeitung und Vorbereitung der Daten zuständig ist. Die eigentliche &#039;&#039;&#039;Visualisierung erfolgt dann clientseitig&#039;&#039;&#039;, wodurch Ressourcen effizient genutzt werden.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; von Three.js ist die hohe Anpassbarkeit. Es kann genau das umgesetzt werden, was gewünscht ist, und es ermöglicht die Gestaltung moderner Oberflächen. Die Interaktivität ist durch die vielfältigen Module von Three.js sehr groß.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; ist jedoch der aufwendige Implementationsprozess.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um zu zeigen, dass ThreeJS eine gute Grundlage liefert um die Visualisierung des Online-Windtunnels entwickeln zu können, wurde folgender Prototyp entwickelt.&lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui threejs prototyp 1.png|750px|Ein erste Prototyp der Visualisierung mit ThreeJS]]&lt;br /&gt;
&lt;br /&gt;
Es zeigt sich am Prototyp, dass das Konzept und die Grundidee funktionieren. Der zeitliche Verlauf im Windtunnel lässt sich untersuchen, wobei man zoomen, pausieren, spulen und die Simulationsparameter wechseln kann. In diesem ersten Prototyp wurden somit bereits alle grundlegenden Funktionalitäten eingebaut.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Probleme&#039;&#039;&#039; bestehen derzeit noch bei der Framerate, wenn die Anwendung nicht lokal ausgeführt wird. Dies kann aber voraussichtlich durch Performance-Verbesserungen behoben werden. Ein Vorteil, der sich aufzeigt, ist, dass alle Wege offenstehen und grundsätzlich alle Ideen theoretisch umsetzbar sind.&lt;br /&gt;
&lt;br /&gt;
=== ThreeJS 2.0 ===&lt;br /&gt;
&lt;br /&gt;
Zu jetztigen Zeitpunkt gilt es für das Windtunnel Projekt ein Framework zu erstellen, mit welchen verschiedenste Experimente im Online-Windtunnel darstellen zu können. Grundlegende Ideen werden dazu im Abschnitt &amp;quot;Windtunnel-Online-GUI&amp;quot; erklärt&lt;br /&gt;
&lt;br /&gt;
== Streamlit ==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
=== Streamlit Prototyp ===&lt;br /&gt;
&lt;br /&gt;
Um die Eignung von Streamlit zu testen, wurde folgender Prototyp entwickelt: &lt;br /&gt;
&lt;br /&gt;
[[File:Windtunnel online gui streamlit prototyp.png|750px|Ein erste Prototyp, welcher die Simulierten Daten des Windtunnels in einer WebApp visualisieren soll]]&lt;br /&gt;
&lt;br /&gt;
Bei der Entwicklung des Prototyps sind jedoch einige weitere Probleme aufgefallen. Die gesamte Seite wird bei jeder Interaktion komplett neu geladen, abgesehen von einigen Zuständen, die gespeichert werden können. Dies führt zu Problemen bei der effizienten Darstellung von Daten. Da die Felder mit Matplotlib visualisiert werden, benötigt die Darstellung für einen einzelnen Zeitpunkt mehrere Sekunden. Dadurch kann beispielsweise der zeitliche Verlauf nicht wie ein Video abgespielt werden. Und dabei fanden alle Tests nur lokal statt.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Vorteil&#039;&#039;&#039; ist weiterhin die sehr einfache Implementierung. Der Prototyp besteht nur aus etwa 60 Zeilen Code.&lt;br /&gt;
&lt;br /&gt;
== H5P ==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_threejs_prototyp_1.png&amp;diff=686</id>
		<title>File:Windtunnel online gui threejs prototyp 1.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_threejs_prototyp_1.png&amp;diff=686"/>
		<updated>2024-10-29T10:28:08Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Erster ThreeJS Prototyp&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_streamlit_prototyp.png&amp;diff=685</id>
		<title>File:Windtunnel online gui streamlit prototyp.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:Windtunnel_online_gui_streamlit_prototyp.png&amp;diff=685"/>
		<updated>2024-10-29T10:03:43Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Zeigt einen Prototyp für die Visualisierung des Windtunnel mit Streamlit und Matplotlib&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=459</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=459"/>
		<updated>2024-05-21T12:22:34Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Streamline für verschiedene Auflösung&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|700px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 3: Plot des Druckes über Theta, für verschiedene R, für das ursprüngliche Setup]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig.4: Plot des Druckes über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 5:Plot des Druckes über Theta, für verschiedene R, für eine größere Auflösung.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|250px|thumb|right|Fig. 6: Plot des Drucks über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 7: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei ursprünglicher Auflösung]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 8: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 9: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei größerer Auflösung]]&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 17:55, 17 May 2024‎ (CEST)&lt;br /&gt;
: Ich verstehe das mit dem \(X_2=\theta\in[-\pi,\pi]\) nicht. Geht das einfach so, rechnet der dann echt beide Hälften der x/z-Ebene unabhängig? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 18:12, 17 May 2024 (CEST)&lt;br /&gt;
:: Da bin ich mir auch nicht ganz sicher. Ich bin jetzt erstmal davon ausgegangen, weil mir in Visit das Mesh richtig angezeigt wurde und weil die Ergebnisse wie erwartet aussehen. Bis jetzt ist mir aber auch noch keine Idee gekommen, wie ich testen könnte, ob sich das Grid so verhält, wie ich es mir erhoffe. Emilio hatte auch angemerkt, dass \(X_2=\theta\) in Kugelkoordinaten nur für \(X_2=\theta\in[0,\pi]\) definiert ist. Belt hat aber zumindest keine Fehler ausgegeben. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 11:19, 18 May 2024 (CEST)&lt;br /&gt;
::: Ich bin verblüfft, dass es überhaupt funktioniert. Aber Du könntest das Feld über \(\theta\in[-0.4,0.4]\) plotten, dann sollte doch klar werden, ob es korrekt interpretiert wurde.&amp;lt;br&amp;gt; Das [https://plutocode.ph.unito.it/userguide.pdf Manual] sagt übrigens auf Seite 18, Du solltest &amp;lt;code&amp;gt;polaraxis&amp;lt;/code&amp;gt; statt &amp;lt;code&amp;gt;axisymmetric&amp;lt;/code&amp;gt; als RB für \(\theta\in[0,\pi]\) benutzen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 17:16, 18 May 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:::: Es scheint so als würde das Grid von Pluto richtig erstellt werden (Fig. 10) --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 01:21, 20 May 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-FULL-DOMAIN-SHOWCASE.png|700px|thumb|center|Fig. 10: Plot des Druckes für den Fall mit der verschobenen X2-BEG Boundary bei originaler Auflösung. In diesem Fall ist in der &#039;pluto.ini&#039; Theta:  \(\theta\in[-\pi,\pi]\). Im Plot ist dieses Verhalten erkennbar]]&lt;br /&gt;
&lt;br /&gt;
::: Ach, hast Du ja in den FULL-DOMAINs [[:File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|Nr. 1]] und [[:File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|Nr. 2]] längst gemacht. Nun, dem Manual nach ist die Koordinatensingularität (\(\sin\theta=0\)) nicht unproblematisch, und die hast Du dann ja auch bei Deinen FULL-DOMAIN-Rechnungen. Es liest sich aber auch nicht so, als würde &amp;lt;code&amp;gt;polaraxis&amp;lt;/code&amp;gt; statt &amp;lt;code&amp;gt;axisymmetric&amp;lt;/code&amp;gt; das Problem tatsächlich lösen, es scheint eher nur für 3D relevant zu sein. Aber einen Versuch ist es ja mal wert. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 08:16, 19 May 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Streamlines für verschiedene Auflösungen ===&lt;br /&gt;
&lt;br /&gt;
Mir ist grade auch aufgefallen, dass für verschiedene Auflösungen die Streamlines andres aussehen. Die Streamlines in dem Plot werden auf folgender Line gestartet und in beide Richtungen entwickelt. Dabei sind die Startpunkte auf dieser Line uniform verteilt:&lt;br /&gt;
&lt;br /&gt;
Streamline-Startpunkte:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
lineStart: x=0       z=2e-06&lt;br /&gt;
lineEnd:   x=3e-06   z=2e-06&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-JET-PROBLEM-STREAMLINE-RES.png|900px|thumb|center|Fig. 11: Links ist ein Beispiel mit geringer Auflösung und rechts mit etwa doppelt so großer Auflösung. Der Plot &amp;quot;hinter&amp;quot; den Streamlines ist der Druck. Für den Fall niedriger Auflösung ist der Jet deutlicher zu erkennen. Die unterschiedlichen Farben liegen an der Skala der Colorbar. Außerdem sieht man wie unterschiedlich das Verhalten der Streamlines ist. Die unterschiedliche Form der Streamlines ist auch im Geschwindigkeits-Feld als dieser &amp;quot;Cone&amp;quot; zu erkennen]]&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-JET-PROBLEM-STREAMLINE-RES.png&amp;diff=452</id>
		<title>File:BA-FW-JET-PROBLEM-STREAMLINE-RES.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-JET-PROBLEM-STREAMLINE-RES.png&amp;diff=452"/>
		<updated>2024-05-21T12:16:06Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Visit Plots showing the difference of the streamline for different resolutions&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=447</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=447"/>
		<updated>2024-05-19T23:22:15Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Plot für begrenzte Theta&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|700px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 3: Plot des Druckes über Theta, für verschiedene R, für das ursprüngliche Setup]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig.4: Plot des Druckes über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 5:Plot des Druckes über Theta, für verschiedene R, für eine größere Auflösung.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|250px|thumb|right|Fig. 6: Plot des Drucks über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 7: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei ursprünglicher Auflösung]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 8: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 9: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei größerer Auflösung]]&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 17:55, 17 May 2024‎ (CEST)&lt;br /&gt;
: Ich verstehe das mit dem \(X_2=\theta\in[-\pi,\pi]\) nicht. Geht das einfach so, rechnet der dann echt beide Hälften der x/z-Ebene unabhängig? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 18:12, 17 May 2024 (CEST)&lt;br /&gt;
:: Da bin ich mir auch nicht ganz sicher. Ich bin jetzt erstmal davon ausgegangen, weil mir in Visit das Mesh richtig angezeigt wurde und weil die Ergebnisse wie erwartet aussehen. Bis jetzt ist mir aber auch noch keine Idee gekommen, wie ich testen könnte, ob sich das Grid so verhält, wie ich es mir erhoffe. Emilio hatte auch angemerkt, dass \(X_2=\theta\) in Kugelkoordinaten nur für \(X_2=\theta\in[0,\pi]\) definiert ist. Belt hat aber zumindest keine Fehler ausgegeben. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 11:19, 18 May 2024 (CEST)&lt;br /&gt;
::: Ich bin verblüfft, dass es überhaupt funktioniert. Aber Du könntest das Feld über \(\theta\in[-0.4,0.4]\) plotten, dann sollte doch klar werden, ob es korrekt interpretiert wurde.&amp;lt;br&amp;gt; Das [https://plutocode.ph.unito.it/userguide.pdf Manual] sagt übrigens auf Seite 18, Du solltest &amp;lt;code&amp;gt;polaraxis&amp;lt;/code&amp;gt; statt &amp;lt;code&amp;gt;axisymmetric&amp;lt;/code&amp;gt; als RB für \(\theta\in[0,\pi]\) benutzen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 17:16, 18 May 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:::: Es scheint so als würde das Grid von Pluto richtig erstellt werden (Fig. 10) --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 01:21, 20 May 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-FULL-DOMAIN-SHOWCASE.png|700px|thumb|center|Fig. 10: Plot des Druckes für den Fall mit der verschobenen X2-BEG Boundary bei originaler Auflösung. In diesem Fall ist in der &#039;pluto.ini&#039; Theta:  \(\theta\in[-\pi,\pi]\). Im Plot ist dieses Verhalten erkennbar]]&lt;br /&gt;
&lt;br /&gt;
::: Ach, hast Du ja in den FULL-DOMAINs [[:File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|Nr. 1]] und [[:File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|Nr. 2]] längst gemacht. Nun, dem Manual nach ist die Koordinatensingularität (\(\sin\theta=0\)) nicht unproblematisch, und die hast Du dann ja auch bei Deinen FULL-DOMAIN-Rechnungen. Es liest sich aber auch nicht so, als würde &amp;lt;code&amp;gt;polaraxis&amp;lt;/code&amp;gt; statt &amp;lt;code&amp;gt;axisymmetric&amp;lt;/code&amp;gt; das Problem tatsächlich lösen, es scheint eher nur für 3D relevant zu sein. Aber einen Versuch ist es ja mal wert. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 08:16, 19 May 2024 (CEST)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-FULL-DOMAIN-SHOWCASE.png&amp;diff=446</id>
		<title>File:BA-FW-FULL-DOMAIN-SHOWCASE.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-FULL-DOMAIN-SHOWCASE.png&amp;diff=446"/>
		<updated>2024-05-19T23:14:51Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Plot der X2=Theta beschränkt und so das von Belt ausgegebene Grid überprüft&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=444</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=444"/>
		<updated>2024-05-19T13:25:46Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: image size fix&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|700px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 3: Plot des Druckes über Theta, für verschiedene R, für das ursprüngliche Setup]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig.4: Plot des Druckes über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 5:Plot des Druckes über Theta, für verschiedene R, für eine größere Auflösung.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|250px|thumb|right|Fig. 6: Plot des Drucks über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 2: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei ursprünglicher Auflösung]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 2: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei größerer Auflösung]]&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 17:55, 17 May 2024‎ (CEST)&lt;br /&gt;
: Ich verstehe das mit dem \(X_2=\theta\in[-\pi,\pi]\) nicht. Geht das einfach so, rechnet der dann echt beide Hälften der x/z-Ebene unabhängig? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 18:12, 17 May 2024 (CEST)&lt;br /&gt;
:: Da bin ich mir auch nicht ganz sicher. Ich bin jetzt erstmal davon ausgegangen, weil mir in Visit das Mesh richtig angezeigt wurde und weil die Ergebnisse wie erwartet aussehen. Bis jetzt ist mir aber auch noch keine Idee gekommen, wie ich testen könnte, ob sich das Grid so verhält, wie ich es mir erhoffe. Emilio hatte auch angemerkt, dass \(X_2=\theta\) in Kugelkoordinaten nur für \(X_2=\theta\in[0,\pi]\) definiert ist. Belt hat aber zumindest keine Fehler ausgegeben. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 11:19, 18 May 2024 (CEST)&lt;br /&gt;
::: Ich bin verblüfft, dass es überhaupt funktioniert. Aber Du könntest das Feld über \(\theta\in[-0.4,0.4]\) plotten, dann sollte doch klar werden, ob es korrekt interpretiert wurde.&amp;lt;br&amp;gt; Das [https://plutocode.ph.unito.it/userguide.pdf Manual] sagt übrigens auf Seite 18, Du solltest &amp;lt;code&amp;gt;polaraxis&amp;lt;/code&amp;gt; statt &amp;lt;code&amp;gt;axisymmetric&amp;lt;/code&amp;gt; als RB für \(\theta\in[0,\pi]\) benutzen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 17:16, 18 May 2024 (CEST)&lt;br /&gt;
::: Ach, hast Du ja in den FULL-DOMAINs [[:File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|Nr. 1]] und [[:File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|Nr. 2]] längst gemacht. Nun, dem Manual nach ist die Koordinatensingularität (\(\sin\theta=0\)) nicht unproblematisch, und die hast Du dann ja auch bei Deinen FULL-DOMAIN-Rechnungen. Es liest sich aber auch nicht so, als würde &amp;lt;code&amp;gt;polaraxis&amp;lt;/code&amp;gt; statt &amp;lt;code&amp;gt;axisymmetric&amp;lt;/code&amp;gt; das Problem tatsächlich lösen, es scheint eher nur für 3D relevant zu sein. Aber einen Versuch ist es ja mal wert. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 08:16, 19 May 2024 (CEST)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=438</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=438"/>
		<updated>2024-05-18T11:10:30Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: PRS über THETA Plots&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|700px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 3: Plot des Druckes über Theta, für verschiedene R, für das ursprüngliche Setup]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig.4: Plot des Druckes über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 5:Plot des Druckes über Theta, für verschiedene R, für eine größere Auflösung.]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|250px|thumb|right|Fig. 6: Plot des Drucks über Theta und R, für eine größere Auflösung (1110x200)]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png|700px|thumb|center|Fig. 2: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei ursprünglicher Auflösung]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|50px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png|700px|thumb|center|Fig. 2: Plot des Druckes über Theta, für verschiedene R, für eine Verschiebung der X2-BEG Boundary bei größerer Auflösung]]&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 17:55, 17 May 2024‎ (CEST)&lt;br /&gt;
: Ich verstehe das mit dem \(X_2=\theta\in[-\pi,\pi]\) nicht. Geht das einfach so, rechnet der dann echt beide Hälften der x/z-Ebene unabhängig? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 18:12, 17 May 2024 (CEST)&lt;br /&gt;
:: Da bin ich mir auch nicht ganz sicher. Ich bin jetzt erstmal davon ausgegangen, weil mir in Visit das Mesh richtig angezeigt wurde und weil die Ergebnisse wie erwartet aussehen. Bis jetzt ist mir aber auch noch keine Idee gekommen, wie ich testen könnte, ob sich das Grid so verhält, wie ich es mir erhoffe. Emilio hatte auch angemerkt, dass \(X_2=\theta\) in Kugelkoordinaten nur für \(X_2=\theta\in[0,\pi]\) definiert ist. Belt hat aber zumindest keine Fehler ausgegeben. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 11:19, 18 May 2024 (CEST)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png&amp;diff=437</id>
		<title>File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-LOW-RES-PRS-THETA.png&amp;diff=437"/>
		<updated>2024-05-18T10:43:03Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Der Plot stellt den Druck über Theta da für verschiedene Radien. Dabei ist das Jet-Problem zu erkennen. Hier ist X2=[0,pi] und kleinere Auflösung&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png&amp;diff=436</id>
		<title>File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES-PRS-THETA.png&amp;diff=436"/>
		<updated>2024-05-18T10:43:02Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Der Plot stellt den Druck über Theta da für verschiedene Radien. Dabei ist das Jet-Problem zu erkennen. Hier ist X2=[0,pi] und größere Auflösung&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png&amp;diff=435</id>
		<title>File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-LOW-RES-PRS-THETA.png&amp;diff=435"/>
		<updated>2024-05-18T10:42:55Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Der Plot stellt den Druck über Theta da für verschiedene Radien. Dabei ist das Jet-Problem zu erkennen. Hier ist X2=[-pi,pi] und kleinere Auflösung&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png&amp;diff=434</id>
		<title>File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES-PRS-THETA.png&amp;diff=434"/>
		<updated>2024-05-18T10:39:53Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Der Plot stellt den Druck über Theta da für verschiedene Radien. Dabei ist das Jet-Problem zu erkennen&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=433</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=433"/>
		<updated>2024-05-18T09:20:09Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Antwort Lothar theta -pi bis pi&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|800px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 17:55, 17 May 2024‎ (CEST)&lt;br /&gt;
: Ich verstehe das mit dem \(X_2=\theta\in[-\pi,\pi]\) nicht. Geht das einfach so, rechnet der dann echt beide Hälften der x/z-Ebene unabhängig? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 18:12, 17 May 2024 (CEST)&lt;br /&gt;
:: Da bin ich mir auch nicht ganz sicher. Ich bin jetzt erstmal davon ausgegangen, weil mir in Visit das Mesh richtig angezeigt wurde und weil die Ergebnisse wie erwartet aussehen. Bis jetzt ist mir aber auch noch keine Idee gekommen, wie ich testen könnte, ob sich das Grid so verhält, wie ich es mir erhoffe. Emilio hatte auch angemerkt, dass \(X_2=\theta\) in Kugelkoordinaten nur für \(X_2=\theta\in[0,\pi]\) definiert ist. Belt hat aber zumindest keine Fehler ausgegeben. --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 11:19, 18 May 2024 (CEST)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=430</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=430"/>
		<updated>2024-05-17T15:55:46Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Bilder vergessen&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|800px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png|250px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=429</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=429"/>
		<updated>2024-05-17T15:54:01Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|center|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|800px|thumb|center|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
== Änderung des Gitters ==&lt;br /&gt;
&lt;br /&gt;
Da in den obigen Simulation der Jet immer nur an den nächsten Zellen zur X2-BEG Boundary zu beobachten war, habe ich für selbe Setup mir verschiedene Gittereinstellungen angeguckt. Geändert habe ich dabei die Position der X2-BEG Boundary und die Auflösung des Gitters. Das Gitter aus den vorherigen Simulation (Auflösung : 550x100) hatte folgende Form:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     550    l+    20.0         &lt;br /&gt;
X2-grid    1    0.0      100    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0       1    u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Größere Auflösung (1110x200) ===&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png|400px|thumb|right|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für den Fall größerer Auflösung ist der &amp;quot;Jet&amp;quot; deutlich kleiner. Dazu dieser nicht mehr an der innersten Zelle der X2-BEG Boundary. &lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6     1110   l+    20.0         &lt;br /&gt;
X2-grid    1    0        200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0      1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        axisymmetric&lt;br /&gt;
X2-end        axisymmetric&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei originaler Auflösung (550x200) ===&lt;br /&gt;
&lt;br /&gt;
Für dieses Grid-Setup entsteht ein sehr ähnlicher Fehler zu dem mit der selben Auflösung aber der originellen X2-BEG Boundary Position.&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                550    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      200    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== Verschieben der X2-BEG Boundary bei größere Auflösung (1110x500) ===&lt;br /&gt;
&lt;br /&gt;
Für diesen Fall ist erneut der &amp;quot;Jet&amp;quot; sehr klein und kaum erkennbar.&lt;br /&gt;
&lt;br /&gt;
Gitter-Setup in der &#039;&#039;pluto.ini&#039;&#039;:&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;ini&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
[Grid]&lt;br /&gt;
X1-grid    1    1e-6                1110    l+    20.0         &lt;br /&gt;
X2-grid    1    -3.14159265359      500    u     3.14159265359&lt;br /&gt;
X3-grid    1    0.0                 1      u     6.28318530718&lt;br /&gt;
&lt;br /&gt;
[Boundary]&lt;br /&gt;
X1-beg        userdef&lt;br /&gt;
X1-end        userdef&lt;br /&gt;
X2-beg        periodic&lt;br /&gt;
X2-end        periodic&lt;br /&gt;
X3-beg        periodic&lt;br /&gt;
X3-end        periodic&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=== Schlüsse aus den Simulationen mit verschiedenen Grid-Setups ===&lt;br /&gt;
&lt;br /&gt;
Ich glaube das die X2 Boundary nicht direkt die Ursache für dieses Fehler sein kann, da der Jet auch auftritt, wenn ich diese verschiebe.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png&amp;diff=428</id>
		<title>File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HALF-DOMAIN-HIGH-RES.png&amp;diff=428"/>
		<updated>2024-05-17T15:53:07Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Jet M25 Theta 0 bis -Pi&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png&amp;diff=427</id>
		<title>File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN.png&amp;diff=427"/>
		<updated>2024-05-17T15:52:19Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Jet M25 Theta -Pi bis Pi&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png&amp;diff=426</id>
		<title>File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-FULL-DOMAIN-HIGH-RES.png&amp;diff=426"/>
		<updated>2024-05-17T15:52:15Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Jet M25 Theta -Pi bis Pi für große Auflösung&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HIGH-RES.png&amp;diff=425</id>
		<title>File:BA-FW-PROBLEM-JET-M25-HIGH-RES.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-HIGH-RES.png&amp;diff=425"/>
		<updated>2024-05-17T15:23:45Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Jet Problem shown in Sim for higher resolution (M25)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=367</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=367"/>
		<updated>2024-05-15T14:39:54Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Problem &amp;quot;Jet&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
= Problem &amp;quot;Jet&amp;quot; =&lt;br /&gt;
&lt;br /&gt;
[[File:BA-FW-PROBLEM-JET-M25-ENDE.jpg|thumb|400px|Fig. 1: Plot des Druck-Feldes über Theta und R, Darstellung in cgs-Einheiten. Für Mach 25]]&lt;br /&gt;
&lt;br /&gt;
Für größere Mach Zahlen sind in Druck und Dichte Feld ein &amp;quot;Jet&amp;quot; (Shaghayegh) zu erkennen (s. Fig. 1). Der Fehler tritt nur an der X2-Boundary auf, welche in der &#039;pluto.ini&#039; als &#039;axisymmetric&#039; definiert wird.&lt;br /&gt;
&lt;br /&gt;
Für das Feld in Fig. 1 wurde auch der minimale Druck aus der &#039;Restrictions.conf&#039; entfernt, welcher zuvor auf den Wert 1e-16 (in cgs-Einheiten) festgelegt wurde, um die Fehler zu Beginn der Simulation vermeiden zu können. Ich habe diesen Entfernt, weil der unterschied des Minimalen Drucks in der Simulation dem in &#039;Restrictions.conf sehr ähnlich wurde. &lt;br /&gt;
&lt;br /&gt;
Um zu überprüfen ob die Einstellung des minimalen Drucks eine Auswirkung auf den &amp;quot;Jet&amp;quot; hat, habe ich die selbe Simulation mit einem Minimalen Druck von 1e-17 (cgs) druchgeführt. Das Ergebnis ist das selbe. Wenn ich allerdings Versuche den Druck noch kleiner einzustellen treten die Fehler von zuvor wieder auf (ConsToPrim(): p(E) &amp;lt; 0).&lt;br /&gt;
&lt;br /&gt;
[[File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png|400px|thumb|Fig. 2: Plots für unterschiedliche Theta über R. Selbe Daten wie in Fig. 1]]&lt;br /&gt;
&lt;br /&gt;
Ich habe auch einmal den Druck in den Zellen für verschiedene Theta geplottet (Fig. 2). Dabei erkennt man, dass die innersten Zellen (\( \theta \approx 0.016 \)) sich vom Verlaufen stark von dass Nachbarn unterscheiden.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png&amp;diff=365</id>
		<title>File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BW-FW-PROBLEM-JET-M25-LINE-PLOT.png&amp;diff=365"/>
		<updated>2024-05-15T14:33:33Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;PRS of Cells for different THETA over R&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-ENDE.jpg&amp;diff=362</id>
		<title>File:BA-FW-PROBLEM-JET-M25-ENDE.jpg</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=File:BA-FW-PROBLEM-JET-M25-ENDE.jpg&amp;diff=362"/>
		<updated>2024-05-15T13:49:28Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Plot of PRS over THETA und R, Zeigt Jet Problem&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=290</id>
		<title>BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=290"/>
		<updated>2024-04-26T17:34:25Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: /* Einströmgeschwindigkeit konstant */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Einströmgeschwindigkeit konstant =&lt;br /&gt;
&lt;br /&gt;
Damit die Auflösung des Grids für verschiedene Machzahlen nicht geändert werden muss, wird die Einströmgeschwindikeit als konstant gewählt und die Schallgeschwindigkeit variiert. Für die Schallgeschwindigkeit gilt:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
\frac{v_{\infty}}{\mathcal{M}} = c_{\infty}  = \sqrt{\gamma \cdot \frac{p_{\infty}}{\rho_{\infty}}}&lt;br /&gt;
\end{align}&lt;br /&gt;
	\(  \)&lt;br /&gt;
Wenn die Einströmgeschwindigkeit \(v_{\infty}\) und die Dichte \( \rho_{\infty} \) als Konstanten gegeben sind und die Machzahl \( \mathcal{M} \) sowie der adiabatische Index \( \gamma \) als unabhängige Parameter einstellbar sind, lässt sich der Druck in folgender Form ausdrücken:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} \biggl(  \frac{v_{\infty}}{\mathcal{M}} \biggr)^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Oder auch:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} c_{\infty}^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Des Weiteren gilt für den Druck folgender Zusammenhang mit der Temperatur:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty} T_{\infty} R}{\mu}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Hier ist \( R \) die Gaskonstante und \( \mu \) die molare Masse. Aus diesem beiden Gleichungen folgt diese Proportionalität, wenn für verschiedene Mach Zahlen die Einströmgeschwindigkeit konstant bleiben soll:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
T \propto \frac{1}{\mathcal{M}^2}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
= Probleme =&lt;br /&gt;
	&lt;br /&gt;
Für Machzahlen \( \mathcal{M} &amp;gt; 10 \) tritt kurz nach Beginn der Simulation folgender Fehler auf:&lt;br /&gt;
&lt;br /&gt;
-&amp;gt; ! ConsToPrim(): p(E) &amp;lt; 0 (-1.01e-07), @step = 552 (stage = 1); [i,j = 2, 7], [x1,x2 = 0.000001, 0.172788]&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel &amp;quot;RunFolder&amp;quot;, in welchem dieser Fehler auftritt, ist in Nextcloud hochgeladen. In diesem sollte die &amp;quot;init.c&amp;quot; mit meiner Rechnung, die Log-Files und &amp;quot;pluto.ini&amp;quot; zu finden sein.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=289</id>
		<title>BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=289"/>
		<updated>2024-04-26T16:41:45Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: T Proportionalität&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Einströmgeschwindigkeit konstant =&lt;br /&gt;
&lt;br /&gt;
Damit die Auflösung des Grids für verschiedene Machzahlen nicht geändert werden muss, wird die Einströmgeschwindikeit als konstant gewählt und die Schallgeschwindigkeit variiert. Für die Schallgeschwindigkeit gilt:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
c_{\infty}  = \frac{v_{\infty}}{\mathcal{M}}=\sqrt{\gamma \cdot \frac{p_{\infty}}{\rho_{\infty}}}&lt;br /&gt;
\end{align}&lt;br /&gt;
	\(  \)&lt;br /&gt;
Wenn die Einströmgeschwindigkeit \(v_{\infty}\) und die Dichte \( \rho_{\infty} \) als Konstanten gegeben sind und die Machzahl \( \mathcal{M} \) sowie der adiabatische Index \( \gamma \) als unabhängige Parameter einstellbar sind, lässt sich der Druck in folgender Form ausdrücken:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} \biggl(  \frac{v_{\infty}}{\mathcal{M}} \biggr)^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Oder auch:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} c_{\infty}^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Des Weiteren gilt für den Druck folgender Zusammenhang mit der Temperatur:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty} T_{\infty} R}{\mu}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Hier ist \( R \) die Gaskonstante und \( \mu \) die molare Masse. Aus diesem beiden Gleichungen folgt diese Proportionalität, wenn für verschiedene Mach Zahlen die Einströmgeschwindigkeit konstant bleiben soll:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
T \propto \frac{1}{\mathcal{M}^2}&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
= Probleme =&lt;br /&gt;
	&lt;br /&gt;
Für Machzahlen \( \mathcal{M} &amp;gt; 10 \) tritt kurz nach Beginn der Simulation folgender Fehler auf:&lt;br /&gt;
&lt;br /&gt;
-&amp;gt; ! ConsToPrim(): p(E) &amp;lt; 0 (-1.01e-07), @step = 552 (stage = 1); [i,j = 2, 7], [x1,x2 = 0.000001, 0.172788]&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel &amp;quot;RunFolder&amp;quot;, in welchem dieser Fehler auftritt, ist in Nextcloud hochgeladen. In diesem sollte die &amp;quot;init.c&amp;quot; mit meiner Rechnung, die Log-Files und &amp;quot;pluto.ini&amp;quot; zu finden sein.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=284</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=284"/>
		<updated>2024-04-26T12:58:14Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Antwort&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;br /&gt;
: Aha, die Schrittweitensteuerung fährt den Zeitschritt wieder rauf (klar), macht ihn dabei aber zu groß. Die Grenze scheint bei \(10^{-11}\) zu liegen. --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 09:59, 26 April 2024 (CEST)&lt;br /&gt;
: Die Ausgabe &amp;lt;code&amp;gt;[Mach =&amp;lt;/code&amp;gt;... ist das Maximum über alle Zellen? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 10:28, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
:: So wie es aussieht handelt es sich um die Maximale Mach Zahl --[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 14:58, 26 April 2024 (CEST)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=272</id>
		<title>Talk:BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Talk:BA_Fynn_Wawrzyniak&amp;diff=272"/>
		<updated>2024-04-26T07:51:44Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: logs für dt=1e-10,dt=1e-15,dt=1e-20&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= ConsToPrim(): p(E) &amp;lt; 0 =&lt;br /&gt;
&lt;br /&gt;
Hilf ein Absenken des initialen Zeitschritts? --[[User:Lothar.brendel|Lothar]] ([[User talk:Lothar.brendel|talk]]) 07:53, 26 April 2024 (CEST)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Es scheint, dass das Absenken des initialen Zeitschritts nicht hilft. Ich habe einfach mal die logs für verschiedene Einstellung des initialen Zeitschritts beigefügt.&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-10} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-10; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-2.34e-05),   @step = 66 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.27e-05),   @step = 66 (stage = 1); [i,j = 2, 74], [x1,x2 =  0.000001, 2.277655]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-15} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-15; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-10; dt = 1.3781e-11; 0.0 %&lt;br /&gt;
          [Mach = 49.995660]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-3.49e-06),   @step = 186 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-1.84e-06),   @step = 187 (stage = 1); [i,j = 2, 72], [x1,x2 =  0.000001, 2.214823]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Für \( dt=10^{-20} \)&lt;br /&gt;
&lt;br /&gt;
&amp;lt;syntaxhighlight lang=&amp;quot;text&amp;quot; line=&amp;quot;1&amp;quot; start=&amp;quot;1&amp;quot;&amp;gt;&lt;br /&gt;
&amp;gt; Starting computation... &lt;br /&gt;
&lt;br /&gt;
step:0; t = 0.0000e+00; dt = 1.0000e-20; 0.0 %&lt;br /&gt;
        [Mach = 49.994517]&lt;br /&gt;
step:100; t = 1.3780e-15; dt = 1.3781e-16; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:200; t = 1.8991e-11; dt = 1.8991e-12; 0.0 %&lt;br /&gt;
          [Mach = 49.994517]&lt;br /&gt;
step:300; t = 1.3811e-07; dt = 5.1143e-09; 0.0 %&lt;br /&gt;
          [Mach = 57.016462]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-7.80e-06),   @step = 307 (stage = 1); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
! ConsToPrim(): p(E) &amp;lt; 0 (-8.17e-06),   @step = 307 (stage = 2); [i,j = 2, 73], [x1,x2 =  0.000001, 2.246239]&lt;br /&gt;
&amp;lt;/syntaxhighlight&amp;gt;&lt;br /&gt;
--[[User:Fynn.W|Fynn.W]] ([[User talk:Fynn.W|talk]]) 09:51, 26 April 2024 (CEST)&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=269</id>
		<title>BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=269"/>
		<updated>2024-04-25T20:46:27Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: edit&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Einströmgeschwindigkeit Konstant =&lt;br /&gt;
&lt;br /&gt;
Damit die Auflösung des Grid&#039;s für verschiedene Machzahlen nicht geändert werden muss, wird die Einströmgeschwindikeit als Konstant angesehen und die Schallgeschwindigkeit variiert. Für die Schallgeschwindigkeit gilt:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
c_{\infty}  = \frac{v_{\infty}}{\mathcal{M}}=\sqrt{\gamma \cdot \frac{p_{\infty}}{\rho_{\infty}}}&lt;br /&gt;
\end{align}&lt;br /&gt;
	\(  \)&lt;br /&gt;
Wenn die Einströmgeschwindigkeit \(v_{\infty}\) und die Dichte \( \rho_{\infty} \) als Konstanten gegeben sind und die Machzahl \( \mathcal{M} \) sowie der adiabatische Index \( \gamma \) als unabhängige Parameter einstellbar sind, lässt sich der Druck in folgender Form ausdrücken:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} \biggl(  \frac{v_{\infty}}{\mathcal{M}} \biggr)^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
Oder auch:&lt;br /&gt;
&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} c_{\infty}^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
= Probleme =&lt;br /&gt;
	&lt;br /&gt;
Für Machzahlen \( \mathcal{M} &amp;gt; 10 \) tritt kurz nach Beginn der Simulation folgender Fehler auf:&lt;br /&gt;
&lt;br /&gt;
-&amp;gt; ! ConsToPrim(): p(E) &amp;lt; 0 (-1.01e-07), @step = 552 (stage = 1); [i,j = 2, 7], [x1,x2 = 0.000001, 0.172788]&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel &amp;quot;RunFolder&amp;quot;, in welchem dieser Fehler auftritt, ist in Nextcloud hochgeladen. In diesem sollte die &amp;quot;init.c&amp;quot; mit meiner Rechnung, die Log-Files und &amp;quot;pluto.ini&amp;quot; zu finden sein.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=268</id>
		<title>BA Fynn Wawrzyniak</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=BA_Fynn_Wawrzyniak&amp;diff=268"/>
		<updated>2024-04-25T20:42:16Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: new&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= Einströmgeschwindigkeit Konstant =&lt;br /&gt;
&lt;br /&gt;
Damit die Auflösung des Grid&#039;s für verschiedene Machzahlen nicht geändert werden muss, wird Einströmgeschwindikeit als Konstant angesehen und die Schallgeschwindigkeit variiert. Für die Schallgeschwindigkeit gilt:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
c_{\infty}  = \frac{v_{\infty}}{\mathcal{M}}=\sqrt{\gamma \cdot \frac{p_{\infty}}{\rho_{\infty}}}&lt;br /&gt;
\end{align}&lt;br /&gt;
	\(  \)&lt;br /&gt;
Wenn die Einströmgeschwindigkeit \(v_{\infty}\) und die Dichte \( \rho_{\infty} \) als Konstanten gegeben sind und die Machzahl \( \mathcal{M} \) sowie der adiabatische Index \( \gamma \) als unabhängige Parameter einstellbar sind, lässt sich der Druck in folgender Form ausdrücken:&lt;br /&gt;
	&lt;br /&gt;
\begin{align}&lt;br /&gt;
p_{\infty} = \frac{\rho_{\infty}}{\gamma} \biggl(  \frac{v_{\infty}}{\mathcal{M}} \biggr)^2&lt;br /&gt;
\end{align}&lt;br /&gt;
&lt;br /&gt;
= Probleme =&lt;br /&gt;
	&lt;br /&gt;
Für Machzahlen \( \mathcal{M} &amp;gt; 10 \) tritt kurz nach Beginn der Simulation folgender Fehler auf:&lt;br /&gt;
&lt;br /&gt;
-&amp;gt; ! ConsToPrim(): p(E) &amp;lt; 0 (-1.01e-07), @step = 552 (stage = 1); [i,j = 2, 7], [x1,x2 = 0.000001, 0.172788]&lt;br /&gt;
&lt;br /&gt;
Ein Beispiel &amp;quot;RunFolder&amp;quot;, in welchem dieser Fehler auftritt, ist in Nextcloud hochgeladen. In diesem sollte die &amp;quot;init.c&amp;quot; mit meiner Rechnung, die Log-Files und &amp;quot;pluto.ini&amp;quot; zu finden sein.&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
	<entry>
		<id>https://wiki.uni-due.de/agk/index.php?title=Windtunnel_online&amp;diff=239</id>
		<title>Windtunnel online</title>
		<link rel="alternate" type="text/html" href="https://wiki.uni-due.de/agk/index.php?title=Windtunnel_online&amp;diff=239"/>
		<updated>2024-04-21T17:27:55Z</updated>

		<summary type="html">&lt;p&gt;Fynn.W: Eintrag zu Wahl des GUI-Frameworks&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;vom [https://www.uni-due.de/zhqe/foerderprogr_lehr-lern-inno.php LLI-Programm] gefördertes Projekt „Windkanal Online“&lt;br /&gt;
&lt;br /&gt;
= Ziele =&lt;br /&gt;
&lt;br /&gt;
# belt/PLUTO kann alle relevanten Randbedingungen rechnen.&lt;br /&gt;
# belt/PLUTO erzeugt einen großen Datensatz an Ergebnissen (Felder) für verschiedene Parameter&lt;br /&gt;
# Ein GUI (&#039;&#039;streamlit&#039;&#039;?) kann die Datensätze interaktiv darstellen.&lt;br /&gt;
# Integration des GUIs in Moodle&lt;br /&gt;
&lt;br /&gt;
= TODO =&lt;br /&gt;
&lt;br /&gt;
* Modifikation von belt/PLUTO und Tests der Modifikationen:&lt;br /&gt;
** Tests der Randbedingungen für die Wände&lt;br /&gt;
** Tests der Randbedingungen am angeströmten Objekt &lt;br /&gt;
* Geeignetes GUI finden, [https://h5p.org H5P] ist schon in Moodle integriert.&lt;br /&gt;
&lt;br /&gt;
=GUI=&lt;br /&gt;
Die Auswahl eines GUI-Frameworks hängt stark von den gewünschten Funktionen ab. Zunächst erscheint Streamlit jedoch als eine geeignete Wahl zur Darstellung und Interaktion mit verschiedenen Datensätzen.&lt;br /&gt;
&lt;br /&gt;
== Streamlit ==&lt;br /&gt;
Das Python-Framework Streamlit ermöglicht es, interaktive Web-Apps zur Datenvisualisierung einfach zu erstellen. Dabei bietet Streamlit eine Vielzahl vorgefertigter Widgets([https://docs.streamlit.io/develop/api-reference Streamlit API-Reference]), die es Benutzern ermöglichen, Daten leicht und anschaulich zu visualisieren.&lt;br /&gt;
&lt;br /&gt;
Streamlit bietet auch verschiedene Möglichkeiten zur Optimierung der Performance von Web-Apps. Funktionen wie &amp;lt;code&amp;gt;st.cache_data&amp;lt;/code&amp;gt; können dazu beitragen, Ladezeiten deutlich zu verkürzen.&lt;br /&gt;
&lt;br /&gt;
Ein &#039;&#039;&#039;Nachteil&#039;&#039;&#039; des einfachen Aufbaus einer Streamlit-App ist, dass komplexere User-Interaktionen nur schwer realisibar sind. Ein Grund dafür ist, dass Streamlit für jeden User-Input die gesamte Web-App aktualisiert.&lt;br /&gt;
&lt;br /&gt;
== H5P ==&lt;br /&gt;
H5P (HTML5 Package) ist ein Open-Source-Framework zur Erstellung interaktiver Lerninhalte. Seit 2020 können diese Lerninhalte in Moodle ohne zusätzliches Plugin verwendet werden.&lt;br /&gt;
&lt;br /&gt;
Dieses Framework ist besonders für die Erstellung von Lerninhalten wie Multiple-Choice-Tests oder interaktive Videos mit integrierten Fragen geeignet, weniger jedoch für die Visualisierung von Daten.&lt;br /&gt;
&lt;br /&gt;
Im Moodle der Uni-Due existiert ein Kurs zur Erstellung digitaler Lerninhalte mit H5P ([https://moodle.uni-due.de/course/view.php?id=11029 Moodle-Kompetenzzentrum: Erste Schritte in H5P]).&lt;/div&gt;</summary>
		<author><name>Fynn.W</name></author>
	</entry>
</feed>