|
|
ls_gs_bugreport.png (157,461 bytes) |
|
|
Have you tried OpenFOAM-1.7.x ? Any work we do on this will be in 1.7.x so we will need the details of behavior of this version rather than any previous releases. |
|
|
I have not. I'll test 1.7.x and report back. |
|
|
Results with 1.7.x look the same as the images posted for 1.6.x. |
|
|
Could you send a small test code and case for us to investigate this issue? |
|
|
Apologies for the delayed response, I was expecting to automatically get a notification if there are new notes. I will put together a test case for you this weekend. Do you have an ftp I can upload the files to (you can email login information to A.Kidess at tudelft.nl)? Even compressed the case weighs about 130 MB. |
|
|
It would be useful if you could create a small case from what you have which reproduces the problem and post it here. If the mesh is generated automatically with a tool we supply then the pack need not include the mesh only the means to generate it. |
|
|
The mesh was generated by a third party using gridPro. I'm not sure if I can get a smaller mesh , but I'll see what I can do. |
|
|
|
|
|
|
|
|
Sorry I couldn't get the case and solver smaller than 3.5 MB, so I had to split the archive in two. Steps to reproduce the error: Extract the archives by using "7za x LSbugrep.7z.001". Compile the solver (which I stripped down to the necessary), then run the solver "sp3d" in the case directory. It will run one time step and write out a solution file. Now, in the postprocessor, set a threshold of alpha = 0.4 and display I0 / QT on the resulting domain. The field I0 will have the expected smooth distribution, while the field QT which is I0 * mag(grad(alpha1)) is not when using leastSquares to approximate gradients. Using Gauss linear the result is as expected. |
|
|
Your case is extreme both in terms of the cell aspect ratios and the gradients being evaluated. It looks like with least-squares the round-off errors accumulate to such an extent that the gradient has a large error. This is partly due to the area weighting currently used but also the round-off errors accumulated in the tensor inversion. There are various choices for the weighting in the least-squares; the current version being carefully constructed to work well for a range of 1D, 2D and 3D meshes but it may not be ideal for your case. A simpler approach is still used in the experimental extendedLeastSquares scheme, try default extendedLeastSquares 0; which behave much better for your case than leastSquares but not possibly not as well as Gauss linear. It may be for your mesh that the Gauss linear scheme is the best or for greater accuracy you could use a higher order interpolation scheme in conjunction with the Gauss gradient scheme. |
|
|
The uploaded mesh was coarsened automatically and the aspect ratios became much more extreme than on the original grid (1850 vs. 470 max). As you expected extendedLeastSquares behaves MUCH better (both on the coarsend and the original grid), though not quite as good as Gauss linear. If we can conclude that the erroneous result is due to limitations of the least squares method on this grid and not a programming bug then I'm happy with the solutions you proposed and we can close this report. |
|
|
Yes, this is not a programming bug but a limitation of the current leastSquares implementation which accumulates round-off error on extreme meshes. The Gauss gradient method is more robust and can be made more accurate on distorted and irregular meshes by choosing a higher-order interpolation scheme. |
- Anonymous
