View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0002057 | OpenFOAM | [All Projects] Bug | public | 2016-04-20 16:14 | 2018-01-16 22:03 | ||||||||
Reporter | LIGA | ||||||||||||
Assigned To | henry | ||||||||||||
Priority | normal | Severity | feature | Reproducibility | always | ||||||||
Status | feedback | Resolution | reopened | ||||||||||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 | ||||||||
Product Version | dev | ||||||||||||
Target Version | Fixed in Version | dev | |||||||||||
Summary | 0002057: ACMI incompatible with velocityComponentLaplacian | ||||||||||||
Description | A sliding interface between two domains is defined using ACMI. As long as the shape of the two domains remain constant but move with a relative velocity to each other, the ACMI works fine - as seen in the oscillating inlet tutorial. However, when the relative velocity is not obtained from the movement of the entire domain, but by surface mesh changes at the interface, the ACMI doesn't work as expected. Such a situation comes up, when the interface surface mesh is moved/changed as a result of velocityComponentLaplacian-solver. One would expect, that the surface mesh slides along the interface as calculated by the solver. Instead, it sticks at the position where the ACMI is defined. Please feel free to have a look at the attached mp4 file for better understanding. | ||||||||||||
Additional Information | If needed, it is possible to provide the whole case with the current settings. | ||||||||||||
Tags | ACMI | ||||||||||||
Attached Files |
|
![]() |
|||||||||||
|
![]() |
|
henry (manager) 2016-05-03 17:40 Last edited: 2016-05-04 09:52 |
It would indeed be useful if you could provide a test-case which demonstrates the issue. |
LIGA (reporter) 2016-05-04 09:37 |
Sample case is uploaded. Simply move points file to polyMesh. Thanks |
MattijsJ (reporter) 2016-05-19 17:44 |
I've uploaded a patch (on today's dev) which fixes a non-conservation issue with ACMI. On the oscillatingACMI tutorial I can e.g. get outflow of 0.0399359 (with inflow 0.04) by just lowering the solver tolerance. Could you try this on your mesh motion case? Changes: - the only effect of the partial overlap is on the face areas - all other properties (value, snGrad, etc) of the ACMI part are just like AMI so behave as if fully covered; there is no more interpolation of the value between ACMI part and non-overlap part |
MattijsJ (reporter) 2016-05-19 18:02 |
Ran #2057 with this and I get uniform temperature in whole domain (not sure if this was the purpose of that case) |
LIGA (reporter) 2016-05-24 16:24 |
@MattijsJ: thank you for your effort. In my case I am struggling at combining ACMI with mesh deformation. |
MattijsJ (reporter) 2016-05-24 16:45 |
So what happens with the patch? What motion solver are you using? Does this use a finite-volume motion solver (e.g. displacementLaplacian)? If so you get additionally the whole issue of interpolating cell values to points. |
LIGA (reporter) 2016-05-24 16:49 |
I am using velocityComponentLaplacian for the motion. Are you able to downlaod any of my attached files? |
MattijsJ (reporter) 2016-05-24 18:36 |
The problem is indeed in the selected motion solver (velocityComponentLaplacian). It uses volPointInterpolation to go from a cell-based velocity to the point motion. The interpolation will most likely do slightly different things depending on the coupling state and this will amplify any errors. Since your motion is quite simple you could try one of the point based ones, e.g.src/fvMotionSolver/fvMotionSolvers/displacement/interpolation/displacementInterpolationMotionSolver.H It requires faceZones for all the patches in the z direction and tables for the motion of these faceZones. It will then interpolate the motion according to the distance to these faceZones. You'll have to experiment a bit with the setup; it is not used in any tutorial. |
henry (manager) 2016-05-30 08:31 |
Resolved by commit 691e7186b4287cc38b259cae6edcdc53f63807be |
LIGA (reporter) 2016-05-30 17:19 Last edited: 2018-01-12 14:28 |
I Downloaded and compiled the newest dev-version (after corresponding commit) in order to try the solution to the current ACMI Problem. Unfortunately I get the following error both by the solver AND paraview. Paraview: --> FOAM FATAL IO ERROR: Expected a ')' while reading binaryBlock, found on line 20 an error file: /home/liggieri/work/Hilti/.../versionTests/ofDev/ACMI-exhaust/constant/polyMesh/faces at line 20. From function Foam::Istream& Foam::Istream::readEnd(const char*) in file db/IOstreams/IOstreams/Istream.C at line 109. FOAM exiting ---------------------------------------------------------------------------- pimpleDymFoam: Create time Create mesh for time = 0 Selecting dynamicFvMesh dynamicMotionSolverFvMesh --> FOAM FATAL IO ERROR: Expected a ')' while reading binaryBlock, found on line 20 an error file: /home/liggieri/work/Hilti/.../versionTests/ofDev/ACMI-exhaust/constant/polyMesh/faces at line 20. From function Foam::Istream& Foam::Istream::readEnd(const char*) in file db/IOstreams/IOstreams/Istream.C at line 109. FOAM exiting Is this issue a cause of the "wrongly" specified motion solver as posted by MattijsJ? Should this be fixed as long as displacementInterpolationMotionSolver is specified in the case? Note: the installation is fine, since other cases without ACMI patches run and are viewed correctly. |
MattijsJ (reporter) 2016-05-31 11:13 |
Does the oscillatingInletACMI2D work for you now? |
LIGA (reporter) 2016-05-31 12:39 |
yes it does. I am testing the dev-version with the case attached in the curent issue (ACMI-exhaust_OF.tar.gz + points) which I can load and run with OF231,OF30 and OFv3.0+. |
MattijsJ (reporter) 2016-05-31 16:27 |
- downloaded your case and points - moved points to constant/polyMesh - ran pimpleDyMFoam for a few iterations with current dev and see no problems. I've uploaded the log file. |
LIGA (reporter) 2016-06-01 08:51 Last edited: 2016-06-01 09:11 |
Thanks for the feedback. Dev-version is running properly now. But the issue explained here is still there. I'm afraid we are mixing up issues here. The core problem from a user point of view here is that the ACMI can't be used as a sliding interface when mesh deformation is applied at the same time. As far as I understand, the resolved part of the ACMI reported now is related to conservation problems due to partially overlapping faces. Although this is a clear advancement, unfortunately, it doesn't seem to solve the problem reported here - namely the use of ACMI as sliding interface in combination with velocityComponentLaplacian. The proposed workaround by using displacementInterpolationMotionSolver.H might work for motions which can be prescribed in advance and which are NOT a consequence of any calculation result during the simulation. E.g. in the current case (the model attached here is basically a moving piston - for simplification purposes it currently moves with constant velocity), in the final model the mesh would move as a function of the pressure on a patch. However, the table only contains prescribed values which cannot change during the case is running. So I think, if this OF version is supposed to be able to model scavenging ports in combination with combustion, which is a very common concept in two-stroke engines, there is no way around fixing this as explained here - namely by using ACMI with velocityComponentLaplacian. |
MattijsJ (reporter) 2016-06-03 10:19 |
The problem in your setup comes from the interpolation of the mesh velocity field (pointMotionUx (or pointMotionUy or ..z) onto the cell based field (for boundary conditions of solving) and back onto the points. See what happens if you provide a 0/cellMotionUx as well as a 0/pointMotionUx and make sure to set the patch types as the ACMI in this volScalarField to e.g. zeroGradient, e.g. instead of type cyclicACMI; do type zeroGradient; patchType cyclicACMI; (the patchType is needed to 'tell' the code that you are overriding a constraint patch) |
rcl (reporter) 2016-06-04 19:14 |
I have prepared a simple modification of the oscillatingInletACMI, with deforming mesh, and with the suggestion in the last note by MattijsjJ. It is not working. I agree that the problem seems to be the velocity laplacian solver.And, also, I agree with LIGA that the interpolationDisplacement solver is not the solution, since the motion is not prescribed. |
rcl (reporter) 2016-06-09 08:41 |
I tried to apply the patch and I get these errors: patching file src/OpenFOAM/meshes/polyMesh/polyMesh.C Hunk #1 succeeded at 1053 (offset 56 lines). patching file src/finiteVolume/fields/fvPatchFields/constraint/cyclicACMI/cyclicACMIFvPatchField.C Hunk #1 FAILED at 137. Hunk #2 succeeded at 215 (offset 15 lines). Hunk #3 succeeded at 247 (offset 15 lines). Hunk #4 FAILED at 270. 2 out of 4 hunks FAILED -- saving rejects to file src/finiteVolume/fields/fvPatchFields/constraint/cyclicACMI/cyclicACMIFvPatchField.C.rej patching file src/finiteVolume/fields/fvPatchFields/constraint/cyclicACMI/cyclicACMIFvPatchField.H Reversed (or previously applied) patch detected! Assume -R? [n] y Hunk #1 succeeded at 275 with fuzz 2 (offset 57 lines). patching file src/finiteVolume/fvMesh/fvPatches/constraint/cyclicACMI/cyclicACMIFvPatch.C Hunk #2 FAILED at 86. Hunk #3 FAILED at 139. 2 out of 3 hunks FAILED -- saving rejects to file src/finiteVolume/fvMesh/fvPatches/constraint/cyclicACMI/cyclicACMIFvPatch.C.rej patching file src/finiteVolume/fvMesh/fvPatches/constraint/cyclicACMI/cyclicACMIFvPatch.H Hunk #1 FAILED at 174. Hunk #2 FAILED at 186. 2 out of 2 hunks FAILED -- saving rejects to file src/finiteVolume/fvMesh/fvPatches/constraint/cyclicACMI/cyclicACMIFvPatch.H.rej patching file src/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.H patching file src/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolationI.H patching file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C Hunk #1 FAILED at 38. Hunk #2 FAILED at 51. Hunk #3 succeeded at 163 (offset -7 lines). Hunk #4 succeeded at 177 with fuzz 2 (offset -7 lines). Hunk #5 succeeded at 191 (offset -10 lines). Hunk #6 succeeded at 255 (offset -10 lines). Hunk #7 succeeded at 278 (offset -10 lines). Hunk #8 succeeded at 316 (offset -2 lines). Hunk #9 succeeded at 341 (offset -2 lines). Hunk #10 succeeded at 380 (offset 6 lines). 2 out of 10 hunks FAILED -- saving rejects to file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C.rej patching file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.H Hunk #5 FAILED at 263. 1 out of 6 hunks FAILED -- saving rejects to file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.H.rej patching file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatchI.H patching file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatchTemplates.C Reversed (or previously applied) patch detected! Assume -R? [n] y Patch attempted to create file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatchTemplates.C, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatchTemplates.C.rej I tried with versions 2.3.1, 2.4.0 and 3.0.1. For now, I can apply the patch by hand, since it is not big, but I wonder if this patch should be applied on another source tree other than which I have installed. |
MattijsJ (reporter) 2016-06-10 09:20 |
The patch is specific to dev (of a few weeks ago). It is already merged into dev so if you download that version you get the latest. If you want to patch a previous version you'll probably have to do it 'by hand' e.g. a 3-way diff (e.g. kdiff3) and see what the textual changes are and apply these to your version. |
rcl (reporter) 2016-06-10 10:08 |
Yes, I was presuming so. I have already applied the patch by hand, but I have still not tested it. In reference to the problem of the mesh deformation in the ACMI, I am not an expert and I don't know how to do that, but I suspect that the problem is in volPointInterpolation::interpolate. The interpolation is made with all the cells owning the point. If there could be a way to say to the function to make the interpolation only with a part of the cells (for instance with a cell zone) I think it could work. |
jskortel (reporter) 2016-08-17 19:00 |
I just pulled the latest updates for the dev version of OpenFOAM, compiled it and ran the ACMI-exhaust_OF example case by LIGA. It looks like ACMI still does not work with deforming mesh. The internal mesh near the ACMI interface becomes distorted and finally the solver crashes. Decreasing the timestep does not affect the solution. |
MattijsJ (reporter) 2016-09-16 14:20 |
The problem is probably related to volPointInterpolation. In this interpolation the big problem with ACMI is that the points are also on 'normal' patches so it is not clear which contribution to take. A workaround is to look at the values on the 'normal' patches only. This at least produces a linear-consistent field. If you replace src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPointPatchField/cyclicACMIPointPatchField.C with attached you can experiment with this. |
jskortel (reporter) 2016-09-25 19:24 |
I replaced the cyclicACMIPointPatchField.C and recompiled OpenFOAM. The version with the body of the member function commented out (the one provided by MattijsJ) produced the same result as the unmodified version(?). It looks like the pointMotion and cellMotion field are leaking from the deforming part of the mesh through the ACMI interface to the nondeforming part (see the animations of the ACMI-exhaust_OF and another example cases). Playing with the InfoInFunction requires more work. Any ideas what to try next? |
Shorty (reporter) 2018-01-16 22:03 |
Hi all, I just want to jump in here. The problem seems to be the same one as I reported once: https://bugs.openfoam.org/view.php?id=2155 As far as the ACMI is coupled, one gets the point and cell fields (which are related to the motion) coupled with the static one and thus, we get errors. Such in my 2-Stroke-Engine-Case I uploaded a few month ago (I check if I have it somewhere else, to enable the download again). @MattijsJ, during that time, you also told me to overwrite the patch entries of the pointMotion or cellMotion field to zeroGradient. However, the interpolation was still applied. I hope I got the point of the problem here (ACMI.mp4 + the comments here). However, I did not have time to investigate into that, and will not have time the next weeks. I just wanted to give the link to the last discussion. Tobi |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2016-04-20 16:14 | LIGA | New Issue | |
2016-04-20 16:14 | LIGA | File Added: ACMI.mp4 | |
2016-04-20 16:39 | henry | Priority | urgent => normal |
2016-04-21 22:27 | wyldckat | Tag Attached: ACMI | |
2016-05-03 17:39 | henry | Product Version | 3.0.0 => dev |
2016-05-03 17:40 | henry | Note Added: 0006224 | |
2016-05-04 09:35 | LIGA | File Added: ACMI-exhaust_OF.tar.gz | |
2016-05-04 09:35 | LIGA | File Added: points | |
2016-05-04 09:37 | LIGA | Note Added: 0006227 | |
2016-05-04 09:52 | henry | Note Edited: 0006224 | View Revisions |
2016-05-04 11:03 | henry | Relationship added | has duplicate 0002082 |
2016-05-19 17:39 | MattijsJ | File Added: ACMI_conservative.patch | |
2016-05-19 17:44 | MattijsJ | Note Added: 0006294 | |
2016-05-19 18:02 | MattijsJ | Note Added: 0006295 | |
2016-05-24 16:24 | LIGA | Note Added: 0006312 | |
2016-05-24 16:45 | MattijsJ | Note Added: 0006313 | |
2016-05-24 16:49 | LIGA | Note Added: 0006314 | |
2016-05-24 18:36 | MattijsJ | Note Added: 0006315 | |
2016-05-30 08:31 | henry | Note Added: 0006332 | |
2016-05-30 08:31 | henry | Status | new => resolved |
2016-05-30 08:31 | henry | Fixed in Version | => dev |
2016-05-30 08:31 | henry | Resolution | open => fixed |
2016-05-30 08:31 | henry | Assigned To | => henry |
2016-05-30 17:19 | LIGA | Note Added: 0006338 | |
2016-05-30 17:19 | LIGA | Status | resolved => feedback |
2016-05-30 17:19 | LIGA | Resolution | fixed => reopened |
2016-05-31 11:13 | MattijsJ | Note Added: 0006340 | |
2016-05-31 12:39 | LIGA | Note Added: 0006341 | |
2016-05-31 12:39 | LIGA | Status | feedback => assigned |
2016-05-31 16:27 | MattijsJ | Note Added: 0006347 | |
2016-05-31 17:20 | henry | Status | assigned => resolved |
2016-05-31 17:20 | henry | Resolution | reopened => fixed |
2016-06-01 08:51 | LIGA | Note Added: 0006351 | |
2016-06-01 08:51 | LIGA | Status | resolved => feedback |
2016-06-01 08:51 | LIGA | Resolution | fixed => reopened |
2016-06-01 09:10 | LIGA | Note Edited: 0006351 | View Revisions |
2016-06-01 09:11 | LIGA | Note Edited: 0006351 | View Revisions |
2016-06-02 10:36 | henry | Relationship added | has duplicate 0002109 |
2016-06-03 10:19 | MattijsJ | Note Added: 0006362 | |
2016-06-04 19:14 | rcl | Note Added: 0006371 | |
2016-06-04 19:15 | rcl | File Added: deformingInletACMI2DTesting.tar.gz | |
2016-06-09 08:41 | rcl | Note Added: 0006417 | |
2016-06-10 09:20 | MattijsJ | Note Added: 0006419 | |
2016-06-10 10:08 | rcl | Note Added: 0006420 | |
2016-08-17 19:00 | jskortel | Note Added: 0006698 | |
2016-09-16 14:20 | MattijsJ | File Added: cyclicACMIPointPatchField.C | |
2016-09-16 14:20 | MattijsJ | Note Added: 0006871 | |
2016-09-25 19:24 | jskortel | File Added: example_videos.tar.gz | |
2016-09-25 19:24 | jskortel | Note Added: 0006923 | |
2018-01-12 14:28 | will | Note Edited: 0006338 | View Revisions |
2018-01-12 14:30 | will | Note Revision Dropped: 6338: 0001051 | |
2018-01-16 22:03 | Shorty | Note Added: 0009206 |