View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002380OpenFOAM[All Projects] Bugpublic2016-12-08 14:332018-07-10 11:18
ReporterSolidnoAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntu OS Version16.04
Product Version 
Fixed in Versiondev 
Summary0002380: MRF solver for omega=0 does not reproduce simpleFoam solver results
DescriptionI'm running simpleFoam solver with MRF cellZone being whole mesh, and encounter a bug explained below. The bug occures regardless if boundary conditions for U and p are freestream or Dirichlet on inlet and Neumann on outlet for U, and opposite for p ("traditional":)

For freestream boundary conditions U field value boundary conditions are slowly drifted by the solver, while for traditional boundary conditions value is immediately changed by solver upon start to vector::zero. Thus, for omega=0 in MRFproperties simpleFoam produces different results compared to simpleFoam without MRF.

I've checked in older versions of OpenFoam and it seems like an older bug.

Steps To Reproduce$ ./AllrunFS
reproduces bug for freestream
$ ./AllrunT
reproduces bug for traditional boundary conditions

TagsNo tags attached.

Activities

Solidno

2016-12-08 14:33

reporter  

Report_bug-MRF.tgz (4,258 bytes)

henry

2016-12-08 15:21

manager   ~0007431

Your case setup is a bit odd. By default walls in the MRF zone are assumed to rotate with the MRF and hence if omega is 0 the wall velocity is set to 0. If you want to explicity set the velocity of patches in the MRF zone you need to specify them to be non-rotating in MRFProperties:

nonRotatingPatches (outlet inlet walls);

Solidno

2016-12-08 17:55

reporter   ~0007432

I made a mistake, I didn't want any wall patches. I am sending fixed case. But referring on sentence up "For freestream boundary conditions U field, value boundary conditions are slowly drifted by the solver, while for traditional boundary conditions value is immediately changed by solver upon start to vector::zero. Thus, for omega=0 in MRFproperties simpleFoam produces different results compared to simpleFoam without MRF." is for patches inlet and outlet.

Report_bug-MRF.tar.gz (4,206 bytes)

henry

2016-12-08 18:06

manager   ~0007433

Could you provide the steps to reproduce the problem?

Solidno

2016-12-08 18:30

reporter   ~0007434

run AllrunFS, after that go to 10/U and after

}
    inlet
    {
        type freestream;
        freestreamValue uniform (0 -30 0);
        value nonuniform List<vector>
45
(
(-2.49822 -38.3344 -2.84088)
(20.797 -28.8032 0.448504)
(3.49157 -36.5005 2.97346)
(-4.0257 -47.7144 -30.8864)
(-1.44647 -0.563724 -7.91937)
(3.26572 -27.1627 17.4214)

the velocity in y-axis should be -30, but it is not.

henry

2016-12-08 18:52

manager   ~0007435

I notice that you have not put the bounary patches in nonRotatingPatches:

    // Fixed patches (by default they 'move' with the MRF zone)
    nonRotatingPatches ();

It should run fine if you do and won't if you don't.

Solidno

2016-12-08 19:40

reporter   ~0007436

There is no nonRotatingPatches patches, there is just fluid getting in at inlet, and getting out at outlet (i am talking about repaired case i send here Report_bug-MRF.tar.gz ). If You delete MRFProperties or put there:

    cellZone cyl;
    active no;

the velocity in y-axis will be -30 as it should be.

Another thing, if You run ./AllrunT and go to 10/U it is

    inlet
    {
        type fixedValue;
        value uniform (0 -0 0);
    }
    cylinder_surface
    {
        type fixedValue;
        value uniform (0 -0 0);
    }
}
but it should write (0 -3 0) as it is given in 0/U

henry

2016-12-08 19:48

manager   ~0007437

You will need to put ALL of the boundary patches in the 'nonRotatingPatches' list.

MattijsJ

2016-12-09 09:58

reporter  

MRFZone.C (14,695 bytes)

MattijsJ

2016-12-09 09:59

reporter   ~0007443

Related: some functions inside MRFZone do not check for active. I assume this is not a feature. Attached with added checking.

MRFZone-2.C (14,695 bytes)

MattijsJ

2016-12-09 10:00

reporter  

MRFZoneTemplates.C (5,620 bytes)

MattijsJ

2016-12-09 10:00

reporter   ~0007444

and templates.

MRFZoneTemplates-2.C (5,620 bytes)

Solidno

2016-12-09 13:20

reporter   ~0007445

None of the boundaries is wall, pardon me for the confusing initial setup. In the new setup, when none of the patches is wall, I was expecting simpleFoam solver with MRF object, when omega=0, to perform consistently with simpleFoam solver without MRF object.

For instance, in the attached case it is set
axis (0 1 0)
for MRFzone, and patch "inlet" has normal vector in y-direction. Now if I specify Uy component to be -30 at the inlet (fixedValue) boundary I would not expect that Uy component changes during simulation, regardless if inlet patch is in nonRotatingPatches list or not. Actually, I would expect that only Ux and Uz can change as prescribed rotation makes only Ux and Uz components non-zero.

In the example I gave, I set omega=0 and was expecting result for
nonRotatingPatches (outlet inlet cylinder_surface);
or
nonRotatingPatches ();
to be "same" compared to solution without the MRF object. As you mentioned, Uy component stays at -30 as expected for nonRotatingPatches (outlet inlet cylinder_surface), but for nonRotatingPatches () Uy component at the inlet behaves apparently unpredictably.

But if this is expected behavior I rest my case.

henry

2016-12-09 13:47

manager   ~0007446

You will need to put ALL of the boundary patches in the 'nonRotatingPatches' list.

henry

2016-12-09 16:44

manager   ~0007448

Patch request resolved in OpenFOAM-dev by commit dc1c6d76005954f230bca829f51eb790d558eeed

Issue History

Date Modified Username Field Change
2016-12-08 14:33 Solidno New Issue
2016-12-08 14:33 Solidno File Added: Report_bug-MRF.tgz
2016-12-08 14:33 Solidno Tag Attached: fixed value boundary condition for MRF solver
2016-12-08 15:21 henry Note Added: 0007431
2016-12-08 17:55 Solidno File Added: Report_bug-MRF.tar.gz
2016-12-08 17:55 Solidno Note Added: 0007432
2016-12-08 18:06 henry Note Added: 0007433
2016-12-08 18:30 Solidno Note Added: 0007434
2016-12-08 18:52 henry Note Added: 0007435
2016-12-08 19:40 Solidno Note Added: 0007436
2016-12-08 19:48 henry Note Added: 0007437
2016-12-09 09:58 MattijsJ File Added: MRFZone.C
2016-12-09 09:59 MattijsJ File Added: MRFZone-2.C
2016-12-09 09:59 MattijsJ Note Added: 0007443
2016-12-09 10:00 MattijsJ File Added: MRFZoneTemplates.C
2016-12-09 10:00 MattijsJ File Added: MRFZoneTemplates-2.C
2016-12-09 10:00 MattijsJ Note Added: 0007444
2016-12-09 13:20 Solidno Note Added: 0007445
2016-12-09 13:47 henry Note Added: 0007446
2016-12-09 16:44 henry Assigned To => henry
2016-12-09 16:44 henry Status new => resolved
2016-12-09 16:44 henry Resolution open => fixed
2016-12-09 16:44 henry Fixed in Version => dev
2016-12-09 16:44 henry Note Added: 0007448
2018-07-10 11:18 administrator Tag Detached: fixed value boundary condition for MRF solver