Skip to content

Question about wall-cell ordering dependence in COMPUTE_VISCOSITY #16288

@mxd45za

Description

@mxd45za

Hello FDS team,

My name is Xinming Xiao, a student at Sun Yat-sen University. While testing a cold-flow case with an S-shaped obstruction geometry (SSS.fds), I noticed a possible wall-cell ordering dependence in velo.f90, inside COMPUTE_VISCOSITY. The SSS.fds case is only a test case that exposes the behavior; the same issue may also appear in other complex obstruction or corner configurations. This is related to the current FDS development source code.

I would like to ask about the intended algorithmic interpretation of this part of the code.

In COMPUTE_VISCOSITY, the near-wall gas-cell viscosity averaging for SOLID_BOUNDARY cells and the boundary/ghost-cell copying for boundary cells are performed inside the same IW wall loop.

From my diagnostic tracing, the wall cells are processed according to the wall-cell list order. In my case, external boundary wall cells were processed first, followed by obstruction wall cells.

For SOLID_BOUNDARY, the adjacent gas-cell viscosity is updated using CELL_COUNTER and a moving average, schematically:

CELL_COUNTER(IIG,JJG,KKG) = CELL_COUNTER(IIG,JJG,KKG) + 1
MU(IIG,JJG,KKG) = moving_average(...)

Later in the same IW loop, the current gas-cell value can be copied to a solid/open/mirror boundary or ghost cell, for example:

IF (CELL(CELL_INDEX(II,JJ,KK))%SOLID) MU(II,JJ,KK) = MU(IIG,JJG,KKG)

and

CASE(OPEN_BOUNDARY,MIRROR_BOUNDARY)
   MU(II,JJ,KK) = MU(IIG,JJG,KKG)

My question is about the ordering dependence of this logic.

If multiple wall cells contribute to the same adjacent gas cell, then MU(IIG,JJG,KKG) may still be an intermediate moving-average value when MU(II,JJ,KK) is copied. Therefore, the final boundary/ghost-cell value may depend on whether that boundary/ghost copy occurs before or after the related SOLID_BOUNDARY averaging operations in the IW order.

For example, an OPEN_BOUNDARY ghost-cell assignment may copy MU(IIG,JJG,KKG) before all related obstruction-wall contributions to the same gas cell have been accumulated. In that case, the OPEN ghost cell receives an intermediate MU value rather than the final averaged gas-cell value.

I also observed a similar overwrite behavior for KRES. In my SSS.fds test case, the same boundary/ghost cell can be reached by multiple wall cells, but with different adjacent gas cells. Since the current logic uses an overwrite assignment,

KRES(II,JJ,KK) = KRES(IIG,JJG,KKG)

the final KRES value depends on which wall cell is processed last.

For example:

Same boundary/ghost cell:
II,JJ,KK = (15, 1, 13)

Previous wall cell:
IW = 9041
IIG,JJG,KKG = (14, 1, 13)
KRES = 3.10146E-06

Current wall cell:
IW = 9321
IIG,JJG,KKG = (15, 1, 14)
KRES = 2.36394E-05

Another example:

Same boundary/ghost cell:
II,JJ,KK = (30, 1, 8)

Previous wall cell:
IW = 9381
IIG,JJG,KKG = (29, 1, 8)
KRES = 6.33005E-06

Current wall cell:
IW = 9901
IIG,JJG,KKG = (30, 1, 7)
KRES = 5.95271E-05

These examples suggest that, near complex obstruction corners or edges, the final boundary/ghost-cell KRES value depends on the final IW that writes to it.

My questions are:

  1. Is this wall-cell ordering dependence intended for complex obstruction corners and edges?

  2. Should the boundary/ghost-cell MU and KRES values preserve the current IW-order overwrite behavior?

  3. Would it be algorithmically equivalent, or at least acceptable, to split this part into separate stages, such as:

    • First complete all SOLID_BOUNDARY near-wall gas-cell MU averaging.
    • Then perform the MU and KRES boundary/ghost-cell copies using the final gas-cell values.

This would separate the computation of gas-cell effective viscosity from the filling of boundary/ghost-cell values. I am not sure whether this would change any intended behavior, so I would appreciate your clarification.

I have attached the SSS.fds test case as SSS.zip. I can also provide the diagnostic output if helpful.

Thank you.

Best regards,
Xinming Xiao
Sun Yat-sen University

SSS.zip

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions