Passive scalars diverge (+/- 1e38) when using COMMON block mask in userf vs explicit geometric checks
春风复苏
Dear Nek community,
I am currently simulating flow over a staggered array of cubes involving passive scalars (Temperature + 2 pollutants). I am implementing a "vegetation drag" model (momentum sink) in userf, which applies a force only within specific geometric regions (above the cubes).
I have tested two different implementations for this geometric check. One works perfectly, but the other causes the passive scalar fields to explode (values ranging from -1e38 to +1e38) immediately, while the velocity field remains stable.
I am trying to understand why the second method fails, as it seems to be a memory/common block issue.
Case Setup:
3 Passive Scalars (ldimt = 4 in SIZE file).
Drag applied in userf based on spatial coordinates.
Method 1: Explicit Geometric Check (WORKS) In this version, I explicitly check if (x > ... and y > ...) inside userf at every time step.
Result: Works correctly. Scalar values are within physical range (~0.0 to 0.1).
Method 2: Pre-calculated Mask using COMMON block (FAILS) In this version, I calculate a mask array veg_mask in usrdat3 (set to 1.0 inside the vegetation zones, 0.0 outside) and store it in a COMMON block. Then, in userf, I simply multiply the drag force by this mask.
Result: Passive scalars (Field 2, 3, 4) immediately show values like +/- 1.0E+38.
Suspect: It seems like the COMMON block might be conflicting with Nek5000's internal memory or scratch arrays during the userf call.
My Question: Is there a specific restriction on using custom COMMON blocks inside userf? Or does userf operate in a memory context where defining such a large array (lx1*ly1*lz1*lelt) in a common block might overwrite the scalar fields (since scalars are failing, but velocity is fine)?
Any insights on how to safely pass this pre-calculated data to userf would be appreciated.
Thank you!
Bai
