[akidess]

For completeness, ESi also have their own bugtracker:
http://www.openfoam.com/code/bug-reporting.php

Originally Posted by guin

Hi Alexandros,
Thanks again for your insightful analysis.

To be honest, I do not have the time either. But there may be anyone partially idle in the community, who can get this development done. I'd suggest to start by sharing your code, even if it is currently in FORTRAN form. This can be done either right here or by means of any of the main fork projects:

https://bugs.openfoam.org/view.php?id=2596 -> Your bug report at the OpenFOAM Foundation. Probably they will not be able to accomplish this action without the corresponding funding, because it is mostly just a 3-guys team at CFD-Direct + a few individual volunteers. Anyway, this can be used as support for future actions e.g. reopening the report or creating a new one.

http://openfoam.com/contact/ -> ESI-OpenCFD team is responsible for the OpenFOAM-plus versions. They have more resources (bigger dedicated team) and they seem to have more active interaction with the user community when it comes to integrate new models into their OpenFOAM releases.

https://sourceforge.net/p/foam-extend/_members/ -> You can contact any of the few current developers of the FOAM-Extend project. It is a fully community-driven project and it would seem a right place to share any new model. But the development is quite slow compared to the other two, which comes from the fact that everyone here contributes in their free time.

Just a question: If I understood correctly, your proposal was only developed in 2D. Do you know how to proceed in order to extend it to 3D?



Indeed we do appreciate your effort.

[arjun]

Originally Posted by alexandross

The Gauss linear scheme is clearly favoured in the users guide,

https://cfd.direct/openfoam/user-guide/fvschemes/

where it says right at the top of section 4.4.2 that

"The default discretisation scheme that is primarily used for gradient terms is:
default Gauss linear;
"
whereas the leastSquares scheme is described as "rarely used". The Gauss gradient is pre-selected in most of the example files distributed with OpenFOAM on which the users base their test cases.

.

I think Henry's comments are applicable only to openFOAM and they do not represent the general thinking.

For example StarCCM+ has their default scheme set to Least Square gradients and they also encourage people to use for the reasons (more accuracy) you mentioned.

My own code favours least square method.

Starccm is known to be more stable (even with least square method) compared to openFOAM with Gauss scheme. (I think the same about FVUS with LSQR being more stable than openfoam with green gauss).

Last Guass method and its improvements are very important because not only the gradients but the whole finite volume method is dependent on Gauss integration.

[akidess]

Ansys (probably the largest user base by a margin) also favours Gauss scheme for general meshes.

Originally Posted by arjun

I think Henry's comments are applicable only to openFOAM and they do not represent the general thinking.

For example StarCCM+ has their default scheme set to Least Square gradients and they also encourage people to use for the reasons (more accuracy) you mentioned.

[alexandross]

Originally Posted by akidess

Ansys (probably the largest user base by a margin) also favours Gauss scheme for general meshes.

Are you sure? Although the cell-based Gauss gradient option appears first in the drop-down menu, the default scheme is the least-squares, according to the Fluent theory guide:

https://www.sharcnet.ca/Software/Ans...rivatives.html

I don't know if the Gauss gradient was originally the default but they switched to the least-squares at some point in time.

[akidess]

I looked it up in the Ansys AIM help, which I thought was based on Fluent and thus used the same settings (apparently I was wrong). The "Automatic" setting uses Green-Gauss node based when the mesh contains tets or wedges.

[alexandross]

Originally Posted by guin

Hi Alexandros,
I'd suggest to start by sharing your code, even if it is currently in FORTRAN form. This can be done either right here or by means of any of the main fork projects

OK, I'll upload here the subroutine for the iterative Gauss method, and a subroutine for the original Gauss method for comparison. You should read the original one first (calc_grad_GSl.f) because I have some comments explaining various fortran variables. I use some user defined objects such as vectors, faces and cells, and also some overloaded operators (e.g. * denotes also the scalar product of two vectors), but they should be fairly straightforward to understand. If you need additional clarifications please ask me.

The iterative Gauss method (calc_grad_iGSl.f) is based on a very simple idea (see eq. 22 of my arXiv paper): the iterative loop such as the "iterloop" loop in calc_grad_GSl is replaced by the outer iterations of the flow solver, which are performed anyway. For example, if the SIMPLE solver is used, the gradient is calculated once at the beginning of each SIMPLE outer iteration; with calc_grad_iGSl the gradient is computed in one pass (no iterations) using the gradient estimate of the previous SIMPLE iteration to account for skewness. At convergence the gradient at the new SIMPLE iteration should be the same as that of the previous SIMPLE iteration. Hence the array "grad", holding the new gradient estimate, has intent(inout) in calc_grad_iGSl (as opposed to intent(out) in calc_grad_GSl). This exploitation of the outer iteration involves a relatively small penalty, in that the outer iterations converge somewhat more slowly (see table 1 of the paper).

To be honest, I have used this new scheme only for the purposes of this paper, i.e. only for solving a Poisson equation, not a flow problem. I normally use the least-squares gradient.

Originally Posted by guin

Just a question: If I understood correctly, your proposal was only developed in 2D. Do you know how to proceed in order to extend it to 3D?

I've tested it only in 2D, but the subroutine should be exactly the same in 3D. The scheme you are referring to is probably the one depicted in figure 6, where indeed extension to 3D would be more involved.

[arjun]

Originally Posted by akidess

Ansys (probably the largest user base by a margin) also favours Gauss scheme for general meshes.

It is not that clear cut. Least square gradients come in Fluent very very late and they have possibly not bothered to change the default. It is probable that they did not need to change the default.

Do you know that their default convective scheme is first order upwind scheme, while Starccm always had Second order upwind scheme as default.

It does not mean that they Fluent favours first order upwind scheme over second order upwind. Their thinking is that they provide simplest default and user specelizes the solver later.

Fluent people have made presentations etc showing how least square is a better scheme. All this does not point that they favour green gauss. We can only say their stance is not known. (They don't make categorical statements like Green Gauss is more stable etc like Henry did).

Also the Starccm comment was to show that people are divided over it and there is no clear cut one side to chose green gauss. (their user base is not small).

[arjun]

Originally Posted by akidess

I looked it up in the Ansys AIM help, which I thought was based on Fluent and thus used the same settings (apparently I was wrong). The "Automatic" setting uses Green-Gauss node based when the mesh contains tets or wedges.

This is very interesting comment. Because Fluent says that node based green gauss of similar accuracy as least square gradients.

I think the possible reason is stability problems of LSQR method when skew and aspect is bad.

[alexandross]

Originally Posted by alexandross

OK, I'll upload here the subroutine for the iterative Gauss method

For some reason it seems that I did not upload correctly the subroutines. I apologise for that, and now I've edited my above post where you can find the attached files.

[alexandross]

Happy new year to everyone.

I would like to inform the readers of this thread that a revised version of our paper has now been published in:

Physics of Fluids 29, 127103 (2017)
http://dx.doi.org/10.1063/1.4997682

(the texts in arXiv and ResearchGate have also been updated).

[tdof]

Very interesting topic, thank you for bringing it to our attention. From now on, I'll only use least squares thanks to your work.

[HPE]

Dear alexandross,

Would you please tell us whether you can release the source code used for the publication, or not?

It would be very useful for the community I believe, and the OpenFOAM maintainers would love to test it.

[alexandross]

Originally Posted by HPE

Dear alexandross,

Would you please tell us whether you can release the source code used for the publication, or not?

It would be very useful for the community I believe, and the OpenFOAM maintainers would love to test it.

Dear HPE,


Thank you for your interest. I used my own custom Fortran code for most of the experiments in the publication (except for those with OpenFOAM, in which I only used the existing gradient schemes "Gauss linear" and "leastSquares", so there's nothing new there). I haven't made my own code publicly available because it's not very efficient and I would like to make some improvements first. Due to my use of custom data structures, it would not be easy to just extract the gradient routines from it and use them elsewhere. However, I did upload (in post #26 of this thread) my Green-Gauss subroutine and the corresponding iterative version that splits the iterations among the SIMPLE iterations (denoted \nabla^{d \infty} in the paper).


Nevertheless, your question gives me the opportunity to mention that very recently we have written another paper (it is currently under review, but is available in arXiv, see below) where we propose a new family of gradient methods that are akin to the least-squares methods but also bear some resemblance to the Green-Gauss gradient, but are always at least first-order accurate. The paper can be found at



https://arxiv.org/abs/1912.08064



or in my ResearchGate page.



The experiments there were performed again with my own Fortran code, but my co-authors from the company Engys work with OpenFOAM and hopefully soon the corresponding OpenFOAM routines will be made available (it is up to them though). I will post a message here when this happens, informing everyone about where they can get the routines from.


Best regards,
Alexandros