2017-08-21 07:28 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002458OpenFOAM[All Projects] Bugpublic2017-03-17 17:47
Reporterilyapopov 
Assigned Towill 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.0.x 
Target VersionFixed 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.
Attached Files

-Relationships
+Relationships

-Notes

~0007739

henry (manager)

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

~0007745

ilyapopov (reporter)

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

~0007938

will (manager)

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.

~0007939

will (manager)

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.

~0007941

will (manager)

Last edited: 2017-03-17 17:47

View 2 revisions

Resolved by commit f540d6363b9db02f1d2bddd79ad88b05a8609e89

+Notes

-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 View Revisions
2017-03-17 17:47 will Fixed in Version => dev
+Issue History