View Issue Details

IDProjectCategoryView StatusLast Update
0003326OpenFOAMBugpublic2019-08-12 10:28
Reporterhandrake0724Assigned Tohenry 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Platformx86_64OSArchOS Version(please specify)
Product Version7 
Fixed in Version 
Summary0003326: incorrect moving mesh treatment in MULES::correct function
Descriptionin line 20-29 shown in correct function of CMULESTemplates.C

if (mesh.moving))
{
    psi.primitiveFieldRef() =
    (
        rho.field()*psi.primitiveField()*rDeltaT
      + Su.field()
      - psiIf
    )/(rho.field()*rDeltaT - Sp.field());
}

is exactly same as static mesh implementation.
It should be modified as follows:

if (mesh.moving))
{
    psi.primitiveFieldRef() =
    (
        rho.field()*psi.primitiveField()*rDeltaT*mesh.Vsc0()/mesh.Vsc()
      + Su.field()
      - psiIf
    )/(rho.field()*rDeltaT - Sp.field());
}

TagsNo tags attached.

Activities

henry

2019-08-11 14:56

manager   ~0010669

Do you have a test-case which demonstrates and verifies the need for this change?

handrake0724

2019-08-11 15:20

reporter   ~0010670

No, I don't have a test-case at the moment.
While I was studing CMULES code, I found that lines 55 - 60 are same as lines 64 - 69.
Since I found a similar code in MULESTemplate.C, I tried derivation of the code.
Is there something that I missed in the derivation?

henry

2019-08-11 16:08

manager   ~0010671

In order to require the volume ratio the case would have to be running with moving mesh, MULES correction AND sub-cycling. I was wondering if you have a case which would benefit from this combination; my view is that MULES correction is an alternative to sub-cycling and that using both together is unlikely to be beneficial and it might be better to restrict the MULES to run either with correction or sub-cycling.

henry

2019-08-11 16:13

manager   ~0010672

Looking at the code again I am not convinced that the sub-cycling volume ratio is required for the correction; this relates to a change between the previous and current correction states, not a difference in time. If you believe the change you propose is correct we need a test-case to demonstrate it.

handrake0724

2019-08-12 00:51

reporter   ~0010673

In that sense, I think your view looks right. I would like to close this issue. Thanks.

henry

2019-08-12 10:28

manager   ~0010674

Fundamental change to MULES proposed without supporting derivation or any case for validation.

Issue History

Date Modified Username Field Change
2019-08-11 14:30 handrake0724 New Issue
2019-08-11 14:56 henry Note Added: 0010669
2019-08-11 15:20 handrake0724 Note Added: 0010670
2019-08-11 16:08 henry Note Added: 0010671
2019-08-11 16:13 henry Note Added: 0010672
2019-08-12 00:51 handrake0724 Note Added: 0010673
2019-08-12 10:28 henry Assigned To => henry
2019-08-12 10:28 henry Status new => closed
2019-08-12 10:28 henry Resolution open => no change required
2019-08-12 10:28 henry Note Added: 0010674