View Issue Details

IDProjectCategoryView StatusLast Update
0002190OpenFOAMBugpublic2022-05-19 09:47
ReporterShorty Assigned Towill  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionsuspended 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Summary0002190: ACMI - Distinguish between blocked and coupled faces could be improved for complex cases
DescriptionDear all,

I am trying to use the ACMI BC in many applications, to poof that OF can handle all these problems. The latest release 4.x made good improvements in the ACMI BC. I also know that the ACMI is for sliding (translation and rotation) but I think it would be also nice to have a bigger range of applications. In the attachment you will find two cases with a run script and a video that describe everything.

The choice which faces are blocked and/or coupled are not working as I would expect in the test cases. In the four sided ACMI square, we only should have one coupled side. In fact we have three. Maybe the algorithm can be modified in a way to get it work.

Other application could be: https://www.youtube.com/watch?v=XC-_F42CZjg

That was my first try to couple two more complex moving regions with ACMI.

Kind regards,
Tobias Holzmann
TagsNo tags attached.

Activities

Shorty

2016-08-12 16:29

reporter   ~0006667

The file is a bit too big, hence I uploaded it on my server (it will stay there).
The cases can be downloaded here: http://holzmann-cfd.de/forumCases/bugReportACMI.tar.gz

MattijsJ

2016-09-22 11:16

reporter   ~0006888

So you want to 'disconnect' the two sides if they are not connected?

- should this be automatically e.g. you give a max distance?
- or any other criterium?
- or explicitly prescribed via some other method?

Shorty

2016-09-22 13:02

reporter   ~0006894

"So you want to 'disconnect' the two sides if they are not connected?"

This should done exactly by ACMI, or not? Because if I am using it for sliding or rotating cellZones, the disconnected faces are not of patch cyclic, they get the blocked patch type.

Therefore I would prefer to set some max distance to check if they are connected or not. Maybe there is a better workaround but for the first instance it would be great. This should also work for the case I demonstrated in the movie (here you see - check the gradient - that almost a lot of faces are connected even if they are far away.



If it not clear, I will make some draft.
Tobi

MattijsJ

2016-09-22 14:49

reporter   ~0006901

The ACMI/AMI will check by projecting the master onto the slave (or the other way around - I always forget) and calculating area overlap. In both AMI and ACMI you can also have separated sides, so with a whole mesh between the two halves (see e.g. the pipeCyclic tutorial). Your situation is a special one - the projection should only happen up to a maximum distance. The problem with these kinds of geometric checks is that it very easily go wrong on a more complicated mesh.

Shorty

2016-09-22 14:59

reporter   ~0006903

Okay, would it be possible to set some distance between the faces after the projecting procedure will not be done anymore and the faces are marked as blocked?

MattijsJ

2016-09-23 11:23

reporter   ~0006912

You can have a look at faceAreaWeightAMI<SourcePatch, TargetPatch>::interArea (src/meshTools/lnInclude/faceAreaWeightAMI.C) where it calculates an overlap area for two faces. You probably want to modify that to return 0 if the centres of these two faces are too far apart.

MattijsJ

2016-09-23 11:51

reporter   ~0006913

You also mentioned:

In the four sided ACMI square, we only should have one
coupled side. In fact we have three.

Could you clarify? ACMI (like cyclicAMI, cyclic) requires pairs of patches with an optional transformation inbetween.

Shorty

2016-09-27 14:12

reporter   ~0006927

Hi,

In the four sided ACMI case there should only be one patch coupled, or lets say - I just wanted to have the patch coupled which is really connected (like having a defined distance between the two face centers). I will check the source code that you mentioned if I find time.

will

2022-05-19 09:47

manager   ~0012597

This appears to be a request for a proximity-based criteria in addition to (or instead of?) overlap-based criteria for judging the extent of a partially-overlapping coupling. It is not clear what the purpose of this change is or how it would be accomplished.

To do this we would need a purpose (what are we trying to simulate that we can't already), an idea of who is interested, funding for the initial development, and a plan for continuing support for the functionality's maintenance. Closing pending all this.

Issue History

Date Modified Username Field Change
2016-08-12 16:23 Shorty New Issue
2016-08-12 16:29 Shorty Note Added: 0006667
2016-09-22 11:16 MattijsJ Note Added: 0006888
2016-09-22 13:02 Shorty Note Added: 0006894
2016-09-22 14:49 MattijsJ Note Added: 0006901
2016-09-22 14:59 Shorty Note Added: 0006903
2016-09-23 11:23 MattijsJ Note Added: 0006912
2016-09-23 11:51 MattijsJ Note Added: 0006913
2016-09-27 14:12 Shorty Note Added: 0006927
2022-05-19 09:47 will Assigned To => will
2022-05-19 09:47 will Status new => closed
2022-05-19 09:47 will Resolution open => suspended
2022-05-19 09:47 will Note Added: 0012597