Windtunnel/Boundary Conditions/on Object - Revision history

Lothar.brendel: /* Open Questions */ +Solid Boundaries near CPU boundaries (found by Beat)

2025-06-12T14:52:02Z

Open Questions: +Solid Boundaries near CPU boundaries (found by Beat)

← Older revision		Revision as of 16:52, 12 June 2025
Line 2:		Line 2:

	= Open Questions =		= Open Questions =

			== Neighbor Data ==

			In function <code>Boundary()</code>, function <code>UserDefBoundary()</code> is called with <code>side=0</code> '''before''' data is exchanged with neighboring domains. Hence, when working on BCs for internal boundaries, oldold data are used?

			== Solid Boundaries near CPU boundaries ==

			[[File:PLUTO solid vs CPU-boundary.png\|center\|400px\|no caption with center]]
			Data fetch problem in PLUTO (assuming 2 ghost cells): If the solid extends into the neighboring CPU domain by one cell, the data to be copied into the ''solid ghost cell'' needs to come from a domain cell beyond the ''CPU ghost cells'' of CPU ''i''.

			Solutions?

			* Don't to a clean reflection, rather take the data for both ''solid ghost cells'' from the same domain cell (which is available).
			* <s>Abort with error, since the probability for this situation is (hoped to be) small.</s>

	== Cells with >1 Boundary ==		== Cells with >1 Boundary ==

Lothar.brendel: +up

2025-05-23T15:52:09Z

+up

← Older revision		Revision as of 17:52, 23 May 2025
Line 1:		Line 1:
			[[Windtunnel/Boundary Conditions\|up]]

	= Open Questions =		= Open Questions =

	== Cells with >1 Boundary ==		== Cells with >1 Boundary ==

	The values of ghost cells ~~must be~~ set in order to yield interpolated values on their corresponding boundary which fulfill the boundary conditions. Cells within object can serve as ghost cells (provided the object is nowhere too thin!), but what ~~to do with~~ ghost cells, which correspond to more than one boundary?		The values of ghost cells are set in order to yield interpolated values on their corresponding "target boundary" which fulfill the boundary conditions. Cells within object can serve as ghost cells (provided the object is nowhere too thin!), but what about ghost cells, which correspond to more than one boundary?

	* A priori, cells with flag <code>FLAG_INTERNAL_BOUNDARY</code> are merely frozen, the flag doesn't lead to any boundary conditions fixing.		* A priori, cells with flag <code>FLAG_INTERNAL_BOUNDARY</code> are merely frozen, the flag doesn't lead to any boundary conditions fixing.

Lothar.brendel: new

2025-05-23T15:41:33Z

new

New page

= Open Questions =

== Cells with >1 Boundary ==

The values of ghost cells must be set in order to yield interpolated values on their corresponding boundary which fulfill the boundary conditions. Cells within object can serve as ghost cells (provided the object is nowhere too thin!), but what to do with ghost cells, which correspond to more than one boundary?

* A priori, cells with flag <code>FLAG_INTERNAL_BOUNDARY</code> are merely frozen, the flag doesn't lead to any boundary conditions fixing.
* This changes with INTERNAL_BOUNDARY_REFLECT=YES, which makes <code>FluidInterfaceBoundary()</code> setting ghost cell values according to a no-shear boundary condition (an extension to no-slip was carried out by Joshua). Alas, this is heeded only for the hyperbolic fluxes, while the viscous flux is unaffected.

Currently, only "½-off" boundary conditions for no-slip can be reached, due to a static zero velocity in the (center of the) ghost cells.

Solutions?

* Rolfs proposition for the object boundary: Set the mass ''flux'' at the boundary to zero after the Riemann solver has computed it.