View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002458OpenFOAMBugpublic2017-02-10 15:262017-03-17 17:47
Reporterilyapopov Assigned Towill  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Versiondev 
Summary0002458: localInteraction is applied to processor patches when using regex
DescriptionWhen using regular expression to match all patches to specify interaction type in LPT simulation, this interaction type is applied to processor patches as well. This leads to particles stick to processor boundaries and not propagate further. (I am dealing with a simulation with large number of arbitrarily names patches so it is inconvenient to list them and there is no regexp to match just them).

Example config:

    localInteractionCoeffs
    {
        patches
        (
            ".*"
            {
                         type stick;
            }
        );
    }
TagsNo tags attached.

Activities

henry

2017-02-10 15:38

manager   ~0007739

Please test in OpenFOAM-4.x or better still OpenFOAM-dev and let us know if this problem still exists.

ilyapopov

2017-02-11 00:31

reporter   ~0007745

I have just checked with latest OpenFOAM-dev from git, and the issue is there. Minimal reproduction case is attached. Just run 'sh run_parallel.sh' and view the cloud in paraview.

I guess there should be a check for coupled patches somewhere here
https://github.com/OpenFOAM/OpenFOAM-dev/blob/master/src/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/patchInteractionDataList.C#L53-L66
minimal1.tgz (2,844 bytes)

will

2017-03-17 12:22

manager   ~0007938

Coupled patches should probably be ignored by the patchInteractionModel, agreed, but what about symmetries, wedges, empty patches, ... We would need to replicate the big if statement in trackToFace to cover all the options.

I think a better solution would be to add a "none" option to the local-interaction model. This would pass the boundary handling back to trackToFace. In the case of coupled patches, this would then do the right thing and act as if the local-interaction model was not active. It also leaves the more ambiguous cases open for specification by the user. It is, admittedly, more verbose in the settings file. Your localInteractionCoeffs would look like this:

    localInteractionCoeffs
    {
        patches
        (
            "procBoundary[0-9]+to[0-9]+"
            {
                         type none;
            }
            ".*"
            {
                         type stick;
            }
        );
    }

If nobody objects, I'll make this change later this afternoon.

will

2017-03-17 14:21

manager   ~0007939

Hmmm, my solution doesn't make the situation any better if one picks a rebound model, though. Per-patch specification isn't included in the rebound model, so the particles will still behave incorrectly on a processor patch...

Fundamentally, an if statement which checks patch types is the only mechanism we have. The wall model uses this effectively, but it only has one type to check. This probably needs a fundamental rethink.

For now, I've included the "none" type in the local interaction model, which will get you out of problems if constraint patches are being handled incorrectly. I've also deactivated patchInteraction models on all coupled patches, as originally requested. The original case will run correctly without modification. This doesn't fix the problem that non-coupled patch types (symmetry, wedge, ...) might not behave as intended with non-local models such as rebound.

I'll commit once tested.

will

2017-03-17 17:45

manager   ~0007941

Last edited: 2017-03-17 17:47

 Resolved by commit f540d6363b9db02f1d2bddd79ad88b05a8609e89

Issue History

Date Modified Username Field Change
2017-02-10 15:26 ilyapopov New Issue
2017-02-10 15:38 henry Note Added: 0007739
2017-02-11 00:31 ilyapopov File Added: minimal1.tgz
2017-02-11 00:31 ilyapopov Note Added: 0007745
2017-03-17 12:22 will Note Added: 0007938
2017-03-17 14:21 will Note Added: 0007939
2017-03-17 17:45 will Assigned To => will
2017-03-17 17:45 will Status new => resolved
2017-03-17 17:45 will Resolution open => fixed
2017-03-17 17:45 will Note Added: 0007941
2017-03-17 17:47 will Note Edited: 0007941
2017-03-17 17:47 will Fixed in Version => dev