|Anonymous | Login | Signup for a new account||2015-11-28 09:25 UTC|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001335||OpenFOAM||[All Projects] Bug||public||2014-06-30 12:52||2015-10-24 20:19|
|Platform||linux mint 15 PC||OS||Other||OS Version||(please specify)|
|Target Version||Fixed in Version|
|Summary||0001335: cyclicACMI BC fail to keep constant T for buoyantBoussinesqFoam solver|
|Description||I tried to use the new cyclicACMI BC for creating a AMI between to compartment using the buoyantBoussinesqFoam solver. |
To test this, I have modified the oscillatingInletACMI2D tutorial so it can be run with buoyantBoussinesqFoam.
Although the solver indeed runs, there seem to be an error at the blockage cell which should keep a zero gradient for the T field. The case was set up to to be fully adiobatic with a constant temperature inlet and zeroGradient fluxes everywhere, still the cell at the AMI boundary which has a partial cyclicAMCI connection and is partially block seem to be incorrect as the temperature is about 200 C below the inlet temperature. This incorrect cell in its turn affects the whole temperature field downstream. The two images included in the system directory give an impression of th global temperature field and the local temperature field near the mesh cell near the corner.
|Steps To Reproduce||The modified oscillatingInletACMI2D tutorial case is included to this post, which can be run with Allrun which makes the mesh and should laucnh buoyantBoussinqPimpleFoam. The png image of the resulting temperature field after 5 s is given in the sytem directory.|
|Additional Information||Several ddt and div schemes were tried in order to fix the problem with the temperature, but none of them can fix the problem. Also some variations with the AMI_blockage boundary were tried (zeroGradient, fixedValue), but all yield the low temperature near the corner cell.|
|Attached Files|| oscillatingInletACMI2D-buoyantBoussinesqFoam.tgz [^] (60,493 bytes) 2014-06-30 12:52|
blockagePatch.png [^] (30,637 bytes) 2015-02-06 14:26
diff.ACMI.faceAreaUpdate [^] (1,222 bytes) 2015-03-02 10:18
diff.ACMI.interpolationTolerance [^] (1,637 bytes) 2015-03-02 10:18
Additionally to buoyantBoussinesqPimple solver, as eelcovv issued at first, compressible solver also has a similar result. At the corner of two coupled interfaces, every field goes wrong.
Since T,p & rho etc are coupled, rhoPimpleDyMFoam (or rhoPimpleFoam) always solves in a wrong way!
As I experimented, the issue might be the AMI-interpolation especially at the corner of non-conformal mesh.
I made the conformal mesh by modifying the orignal blockMeshDict in oscillatingInletACM2D tutorial. In this mesh system, rhoPimpleFoam gives a reasonable simulation!!!
I really need someone help.
Thanks in advance.
edited on: 2015-02-06 14:27
I have a similar problem in an interDyMFoam run. The alpha.water field develops low values next to the blockage patch, even if zeroGradient is used as BC.
I've uploaded a screenshot of the field.
Could you try applying the attached diffs and see if that helps with the problem?
The face area update fix corrects a problem on some moving meshes where the face areas stored by the ACMI case aren't updated at each time step. It doesn't often come up, as most cases involve just rigid body motion, so face areas don't change. If you have a mesh which distorts, though, this might help with the non-conservation issues on the ACMI patch.
The interpolation tolerance fix removes the tolerance from the ACMI interpolation. This makes the interpolation weights add exactly to one. Usually this doesn't matter, as the tolerance is small. If there are fields with large values and small gradients, however, it can cause significant error. It might help with the temperature variations, particularly if pressure work terms are being applied. The tolerance is still applied to the face areas, for stability. I don't know yet whether removing it from the interpolation will have a destabilising effect.
I also have found the same problem with my simulations using ACMI. ACMI works fine with pimpleDyMFoam, but the corner cells at the non-conformal mesh interface give anomalous results with a compressible solver (both sonicDyMFoam and rhoPimpleDyMFoam).
I have also tried using the diff files provided and recompiling, which in my case does not appear to make any difference. Have they worked for anyone else?
Thanks in advance
|No, the proposed fix didn't make any difference in my test case either|
|I've fudged a crude work-around for this issue for my case by re-working the mesh so that the corners at the non-conformal mesh interface are as far away as possible from the region of the mesh I am interested in. The limitation is that the mesh has to then be pretty massive so that the pressure anomalies don't reach the region of interest in the model run-time.|
|I have applied the changes Will provided but it is not clear if it resolves this report from eelcovv. For those who reported similar problems please open your own reports and provide test-cases.|
|2014-06-30 12:52||eelcovv||New Issue|
|2014-06-30 12:52||eelcovv||File Added: oscillatingInletACMI2D-buoyantBoussinesqFoam.tgz|
|2014-12-29 18:43||wyldckat||Tag Attached: ACMI|
|2015-01-21 05:31||scurry||Note Added: 0003573|
|2015-02-06 14:25||esteldunedain||Note Added: 0003711|
|2015-02-06 14:26||esteldunedain||File Added: blockagePatch.png|
|2015-02-06 14:27||esteldunedain||Note Edited: 0003711||View Revisions|
|2015-02-26 18:20||esteldunedain||Note Added: 0003920|
|2015-03-02 10:18||will||File Added: diff.ACMI.faceAreaUpdate|
|2015-03-02 10:18||will||File Added: diff.ACMI.interpolationTolerance|
|2015-03-02 10:27||will||Note Added: 0003938|
|2015-04-24 12:33||jim.teb||Note Added: 0004651|
|2015-04-24 12:38||esteldunedain||Note Added: 0004652|
|2015-04-24 18:52||jim.teb||Note Added: 0004654|
|2015-10-24 20:18||henry||Note Added: 0005485|
|2015-10-24 20:18||henry||Status||new => closed|
|2015-10-24 20:19||henry||Assigned To||=> henry|
|2015-10-24 20:19||henry||Resolution||open => fixed|