|
|
um? wired...who update this ... |
|
|
The current AMI implementation is not exactly conservative although for many/most cases the error is small. You may find the behavior is better in OpenFOAM-2.3.? but this is likely to be with respect to robusness rather than conservation. Please contact ESI/OpenCFD directly about this to find out if they are planning to fix this bug and let us know. |
|
|
Henry, I found the resolution of this bug, I think. cyclicAMIFvPatchField.C gets called twice in the matrix solver and therefore substracts twice the pressure field of the neighboring faces. I multiplied line 226 by 0.5. This takes care of the issue. Same propably for line 264. Regards, Daniel |
|
|
I added an Info statement to Foam::cyclicAMIFvPatchField<Type>::updateInterfaceMatrix and it gets called once for patches AMI1 and AMI2 for each iteration of the PCG solver. Could you please provide details of how you have shown that it gets called twice for each AMI patch of each iteration of the solver? |
|
|
Henry, We are experiencing problems with mass conservation during a simulation of a turbine in a channel flow (pimpleDyMFoam v2.3.x). This results in an unrealistically high generator torque. Has there been progress in solving this issue? Best regards, Roland |
|
|
How large is the mass conservation you are getting? The conservation errors caused by the AMIs are usually small and unlikely to cause significant torque errors. |
|
|
In this case 15%: http://www.openfoam.org/mantisbt/view.php?id=1421 |
|
|
It is unlikely that a 15% conservation error is caused by the AMI, is more likely to be a consequence of a problem with the boundary conditions. What conservation error you you get if you run with MRF? |
|
|
The 15% are not caused by the AMI. The MRF solution was ok if I remember correctly but there seems to be a problem with the new ddtCorr method in certain cases. I know that the setup of this test case is everything else than optimal but the imbalance was much smaller with version 2.2.x. |
|
|
If you run without ddtCorr what is the mass imbalance? Where does the mass imbalance occur? At the boundaries? At the AMI? This report relates to the behavior of AMI in OpenFOAM-2.2.0, are the problems you are reporting related to this post? If not it would be better if you open a separate report and provide more details about your case, the issue and what you have tried to resolve them. |
|
|
faceSource.png (11,099 bytes) |
|
|
Hi Henry, The file faceSource.png shows the result of the following function object, with the flux (sum of phi) on the vertical axis and time on the horizontal axis: ami_static_in { type faceSource; surfaceFormat vtk; source patch; sourceName ami_static_in; operation sum; fields (phi); } In green is shown the flux exiting the first stationary domain. This flux is 1.32 m/s, as per the inlet boundary condition. The black line is on top of the red line; they show the flux entering and exiting the rotating domain, respectively. The blue line shows the flux entering the second stationary domain. So, the order of the flow is: green -> black -> red -> blue, with green and blue stationary AMI interfaces and black and red rotating AMI interfaces. From this plot we see a flux imbalance over the interfaces between the (first) stationary to the rotating domain (from green to black) and again over the interfaces between the rotating and (second) stationary domain (from red to blue). This imbalance (of up to 5 percent per time step) causes a pressure rise in the first stationary domain which results in a pressure gradient between the front and a rear of our rotor. This is responsible for the level of torque that we are seeing. BTW, this is using 2.3.x. If you prefer I can open a separate report for this. |
|
|
Is the flux imbalance strongly affected by the ddtCorr term in the pressure equation? Could you try removing this term? |
|
|
faceSource-noddtCorr.png (5,352 bytes) |
|
|
faceSource-noddtCorr_crop.png (15,058 bytes) |
|
|
Hi Henry, In pEqn.H I commented out the ddtCorr term: surfaceScalarField phiHbyA ( "phiHbyA", (fvc::interpolate(HbyA) & mesh.Sf()) // + rAUf*fvc::ddtCorr(U, Uf) ); This has a large effect on the fluxes through the AMI patches; faceSource-noddtCorr.png shows the fluxes in the same range as yesterday's plot, while faceSource-noddtCorr_crop.png shows the fluxes in a tighter range. Unfortunately for us, this reduction in imbalance has next to no influence on the inflow pressure (and thus rotor torque), as we were expecting. |
|
|
I am confused, my understanding was that you attributed the error in the torque on the mass imbalance so why would you now not expect a reduction in the imbalance to improve the results? |
|
|
Yes, we attributed the error in the torque on the mass imbalance. But this error in torque is still present. (We expected this error to disappear together with the imbalance.) Apologies for the confusion. |
|
|
OK, I understand. I am working on the ddtCorr issue but it looks like the error you are seeing does not relate either to this bug or the slight conservation error AMI causes. It is more likely to be due to issues with the case setup BCs, or maybe the analysis of the results. Either way you will probably need to arrange for some support with this. |
|
|
I agree that our issue appears not to be related to ddtCorr. |
|
|
The part of this report relating to ddtCorr is resolved in OpenFOAM-2.3.x: commit 719bf1b4e7dc29f6e5a8c7b1d2be39fff4de1c5a However the small continuity error initially reported remains and will require significant effort to resolve. |
- Anonymous
