View Issue Details

IDProjectCategoryView StatusLast Update
0001667OpenFOAM[All Projects] Bugpublic2015-04-28 22:29
ReporteramwoudenAssigned Tohenry 
Status resolvedResolutionfixed 
PlatformAppleOSMac OS VersionOS X Yosemite
Product Version 
Fixed in Version 
Summary0001667: Improper update of mesh dependent bc on dynamically rotating regions
DescriptionWhile prescribed on a rotating mesh region, mesh-dependent boundary conditions do not update properly with the dynamic mesh rotation.
Steps To Reproduce1- Start with tutorial: pimpleDyMFoam/mixerVesselAMI2D.
2- Modify the rotor boundary condition to "surfaceNormalFixedValue".
    2i- refValue is arbitrary, I used refValue = -1.
3- The solution is bogus, but most observable is the behavior at the rotor boundary: the velocity vector remains irrotational!
TagsNo tags attached.



2015-04-23 00:13

manager   ~0004644

It is not clear how the surfaceNormalFixedValue could be appropriate for a rotating boundary, are you setting the value to be a function of the radius? For a rotating wall the movingWallVelocity BC is appropriate.


2015-04-27 10:45

manager   ~0004660

surfaceNormalFixedValue is not an appropriate BC for a moving wall, movingWallVelocity should be used.


2015-04-27 16:29

reporter   ~0004664

Last edited: 2015-04-27 16:47

View 2 revisions

Thank you for quickly considering this case. I apologize for not attending to your comments sooner.

Nonetheless, I contest that you review this error more extensively.

I am aware that *in context* of the specific tutorial, mixerVesselAMI2D, that a movingWallVelocity should be used on the rotor; the tutorial is in fact set up with such a condition prior to modification.

Moreover, the error is not self-contained in *just* the surfaceNormalFixedValue. It is reproducible with *any* mesh-dependent boundary condition.

Please consider the error from a conceptual perspective, beyond the constraint of this particular tutorial. I chose the tutorial because it provided a straight-forward mechanism to reproduce the error without the lengthy process of constructing and attaching a demonstrative case intended for the proof of concept.

By definition the surfaceNormalFixedValue BC provides an inlet (or constrained outlet) velocity of magnitude of *refValue* in a direction *normal* to the specified patch. The boundary condition uses a normalized version of the vector Sf() to give direction to the user-specified magnitude.

In my particular application of coupled rotor-stator axial turbomachinery subject to *radial* flow, I intend to specify an inlet upon the rotary section - a patch that consists of a cylindrical shell. The flow proceeds radial outward across the rotor blades, through an AMI (also a cylindrical shell), impinging upon the stator blades, and exiting through an outlet (another cylindrical shell). In short: the flow progresses comprehensively from the rotating frame of the rotor through the fixed frame of the stator in a radial direction. Most particularly I intend to use the surfaceNormalFixedValue at the inlet because it provides a uniform radial inlet condition on the cylindrical shell.

Alternatively, I may use cylindricalInletVelocity. However, as both these patches are derived from the same parent class, the same error surfaces. The movingWallVelocity condition does not provide adequate constructs to specify a radial velocity on a cylindrical shell (and why should it, it is exactly intended for moving walls).

Now, if you would extend your reasoning beyond the context of this tutorial, you will see that, at initialization of runTime, the surfaceNormalFixedValue functions exactly as described above: a radial inlet is established. However, whether it is in the dynamicFvMesh library or the fvPatchField::surfaceNormalFixedValue subroutines, something is missing; the boundary condition does not update properly at successive timesteps with the mesh rotation; the velocity vector does not remain normal to the surface. Only the direction established by the initialization is used in latter timeSteps.

For demonstrative purposes I have attached a video of a Z-normal slice of mixerVesselAMI2D as detailed by the "steps to reproduce". The video displays the velocity vectors on the rotor patch. I point out the constancy of direction on all surfaces; the velocity is not obtaining an updated direction vector with each timeStep.

The case construct containing a timeStep files at every quarter turn of a complete revolution (0 0.25 0.5 0.75 1.0) is also attached.


2015-04-27 16:33

reporter (1,842,683 bytes)


2015-04-27 16:37

reporter   ~0004665

Video to large to upload, please use to access.


2015-04-27 16:52

manager   ~0004666

OK, I understand the issue and your application now. The problem is that the ptf.refValue_*ptf.patch().nf() is cached and not updated for moving-mesh cases.

I will consider suitable update strategies.


2015-04-27 20:24

manager   ~0004667

I have just pushed a fix to OpenFOAM-dev:
commit 9fb9a659527d5eaa81fdc82840c7f6a038f094b3

Could you test it and if it works as you expect I will make the same change to 2.3.x


2015-04-28 19:13

reporter   ~0004683

Looks much better. Thank you.


2015-04-28 22:28

manager   ~0004687

Resolved by commit 62f0ad175f8da1f9c3d8afba43991d7b62deab07

Issue History

Date Modified Username Field Change
2015-04-22 22:09 amwouden New Issue
2015-04-23 00:13 henry Note Added: 0004644
2015-04-27 10:45 henry Note Added: 0004660
2015-04-27 10:45 henry Status new => closed
2015-04-27 10:45 henry Assigned To => henry
2015-04-27 10:45 henry Resolution open => no change required
2015-04-27 16:29 amwouden Note Added: 0004664
2015-04-27 16:29 amwouden Status closed => feedback
2015-04-27 16:29 amwouden Resolution no change required => reopened
2015-04-27 16:33 amwouden File Added:
2015-04-27 16:37 amwouden Note Added: 0004665
2015-04-27 16:37 amwouden Status feedback => assigned
2015-04-27 16:47 amwouden Note Edited: 0004664 View Revisions
2015-04-27 16:52 henry Note Added: 0004666
2015-04-27 20:24 henry Note Added: 0004667
2015-04-28 19:13 amwouden Note Added: 0004683
2015-04-28 22:28 henry Note Added: 0004687
2015-04-28 22:28 henry Status assigned => resolved
2015-04-28 22:28 henry Resolution reopened => fixed