View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001667 | OpenFOAM | Bug | public | 2015-04-22 22:09 | 2015-04-28 22:29 |
| Reporter | amwouden | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Apple | OS | Mac | OS Version | OS X Yosemite |
| Summary | 0001667: Improper update of mesh dependent bc on dynamically rotating regions | ||||
| Description | While prescribed on a rotating mesh region, mesh-dependent boundary conditions do not update properly with the dynamic mesh rotation. | ||||
| Steps To Reproduce | 1- 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! | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
surfaceNormalFixedValue is not an appropriate BC for a moving wall, movingWallVelocity should be used. |
|
|
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. |
|
|
|
|
|
Video to large to upload, please use https://www.dropbox.com/s/3fw17vbzwx2uawb/errorDemo_surfaceNormalFixedValue.avi?dl=0 to access. |
|
|
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. |
|
|
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 |
|
|
Looks much better. Thank you. |
|
|
Resolved by commit 62f0ad175f8da1f9c3d8afba43991d7b62deab07 |
| 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: mixerVesselAMI2D_modAWouden.zip | |
| 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 | |
| 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 |
