dynamicMeshDict sub-block

#1 · September 24, 2026, 3:42 pm

Hello Admin,

I ran a Vortex induced Vibration case (vibrating cylinder with spring+damping, 1 degree of freedom) and i noticed something weird about the dynamicMeshDist block arrangement.

1. In original dynamicMeshDict, the "restraint" block is not located under "rigidBodyMotionCoeffs" block. when i ran the simulation, my subject body (circular cylinder) drifted to -y axis. it looks like the "spring" has not taken into account. (refer image 1 & upper part of .pdf)

2. For second case (same spec as 1), i re-located the "restraints" block under "rigidBodyMotionCoeffs" block, and the vibration simulated as expected according to literature. (refer image 2 and lower part of .pdf)

Am I correct here? Is this bug/glitch from the software side?

Uploaded files:

dynamicMeshDict_default__modified.pdf

#2 · September 28, 2026, 4:11 pm

Hello,

The “restraint” section was incorrectly written in the openFOAM dictionary. We apologize for not testing it thoroughly enough. Thank you for finding the bug. We will fix it.

Thanks,

#3 · September 28, 2026, 4:56 pm

Quote from bykima5230416a7 on September 28, 2026, 4:11 pm

Hello,

The “restraint” section was incorrectly written in the openFOAM dictionary. We apologize for not testing it thoroughly enough. Thank you for finding the bug. We will fix it.

Thanks,

Hello admin,

There is no need for apologizing. This the the least I can do to support BaramCFD.

p/s: Is there any plan to add "wall resolved" in the GUI? It is hard to change the BC condition files in "0" folder manually, especially when running in parallel.

Cheers!

#4 · October 14, 2026, 3:50 pm

Hi Rookie,

The fix will be included in the next release.

By the way, could you tell me more about "wall resolved" in the GUI?

I have no idea what the "wall resolved" means.

Thank you.

Best regards,
Jake

#5 · October 14, 2026, 4:06 pm

Hi Jake,

Great, thanks for the update!

Sorry, I should have explained better. By “wall resolved” I mean running with a very fine mesh near the wall (y+ around 1), so the boundary layer is solved directly instead of using wall functions.

Right now BARAM sets wall functions on the walls by default. For my y+ ~1 cases with k-omega SST, I have to go into the 0 folder and change the wall BCs by hand (k = 0, nut = nutLowReWallFunction, etc.). It’s okay for serial runs, but in parallel I have to edit every processor folder too, which gets annoying.

It would be really nice to have a simple option in the GUI, something like “wall function” or “wall resolved (y+ ~1)” for each wall, so BARAM writes the right BCs automatically.

Just a suggestion. Thanks again!

Cheers,
Rookie

#6 · October 14, 2026, 8:25 pm

Hi Rookie,

BARAM is using Spalding wall function BC for walls in k-omega SST turbulence model.
And it is more practical than nutLowReWallFunction since it can handle the cells that has larger yPlus than 1.

They show almost same result where yPlus is around 1.

Could you let me know the reason why you need exactly nutLowReWallFunction in detail?
I need to fully understand the specific requirement(needs) to design the user interface.

Thank you.

-- Jake

#7 · October 15, 2026, 8:42 pm

Hi Jake,

Thanks for the clear explanation. You’re right.

I was carrying over a habit from other softwares (Ansys, Altair, Flow-3D), where I learned to use wall functions for y+ > 30 and a wall-resolved approach for y+ < 5. That rule of thumb has stuck with me since I first learned CFD, so I assumed I had to switch the BCs manually. Since Spalding’s wall function covers the whole y+ range, I’ll keep BARAM’s default.

p/s: This is my first time using openfoam/Baram. The reason i jump into openfoam is because of Baram. So the confusion between software's requirement (rule of thumb) is real.

Thanks again for the fix and your help!

Cheers,
Rookie