On 07/04/2013 03:02 PM, Ankit Mahato wrote:
Hi R,
For our NavierStokes currently we use the Newton method with backtracking linesearch.
Yes, in sfepy we use that.
in OpenFoam and most of the CFD code the linearization approach is based on Patankar's SIMPLE algorithm.1 I talked to my professor who told me that SIMPLE is used in commercial softwares like FLUENT too.
Do you think you could then try implementing SIMPLE in the FE context?
I found few papers which tells us some other approaches. Do have a look at them and lend your views:

http://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CC0QFjAA&url=http%3A%2F%2Fwww.wiasberlin.de%2Fpeople%2Fjohn%2FPP99_13.ps&ei=mW3VUZqzOMmzrgeKuYD4DA&usg=AFQjCNEp9_rShrLSjkYdax6bOimSrkDKQ&sig2=8S654Vzz2vd4mFZOilZCw&bvm=bv.48705608,d.bmk
 http://numerik.iwr.uniheidelberg.de/OberwolfachSeminar/CFDCourse.pdf

http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
 http://www.reactioneng.com/downloads/nksolver_pernice.pdf
 http://aerocomlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
 https://cs.uwaterloo.ca/research/tr/1993/02/CS9302.pdf
 http://www.cs.sandia.gov/~rstumin/backtrack.pdf
 http://repository.cmu.edu/cgi/viewcontent.cgi?article=1032&context=math
 http://www8.cs.umu.se/kurser/5DA001/HT07/lectures/newtonhandouts.pdf
[1]: http://www.cfdonline.com/Forums/openfoamsolving/60167hownonlineardiscre...
Nice list. I will try to look at it, but doubt that I will be of much help in deciding what path to pursue. We need something that could be implemented in a reasonable time. IMHO that rules out the multigridbased solvers, unless a prepared solution like pyamg could be used directly.
PS: For the python 3 fix which I had forgotten earlier :( . While going through the codes I came across that we use output() in base.py to print. You have already called if sys.version[0] < '3': basestr = basestring else: basestr = str So basically we know the python version and call the print function according to the python version. If I am correct it is quite easy to fix then, am I?
In the sfepy codebase, there should be no print statements  output() should be used everywhere (if it is not, it's a bug), so yes, updating that for python 3 should be pretty easy.
r.
On Thursday, 4 July 2013 19:02:50 UTC+5:30, Robert Cimrman wrote: >
On 07/04/2013 03:02 PM, Ankit Mahato wrote:
Hi R,
For our NavierStokes currently we use the Newton method with backtracking linesearch.
Yes, in sfepy we use that.
in OpenFoam and most of the CFD code the linearization approach is based on Patankar's SIMPLE algorithm.[1][2] I talked to my professor who told me that SIMPLE is used in commercial softwares like FLUENT too.
Do you think you could then try implementing SIMPLE in the FE context?
I will search more in this context and let you know in a few hours.
I found few papers which tells us some other approaches. Do have a look at them and lend your views:

http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
 http://www.reactioneng.com/downloads/nksolver_pernice.pdf

http://aerocomlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
 https://cs.uwaterloo.ca/research/tr/1993/02/CS9302.pdf
 http://www.cs.sandia.gov/~rstumin/backtrack.pdf

http://www8.cs.umu.se/kurser/5DA001/HT07/lectures/newtonhandouts.pdf
[1]:
http://www.cfdonline.com/Forums/openfoamsolving/60167hownonlineardiscre... [2]: http://web.cecs.pdx.edu/~gerry/class/ME448/notes/pdf/SIMPLEslides.pdf
Nice list. I will try to look at it, but doubt that I will be of much help in deciding what path to pursue. We need something that could be implemented in a reasonable time. IMHO that rules out the multigridbased solvers, unless a prepared solution like pyamg could be used directly.
Okie.
>
PS: For the python 3 fix which I had forgotten earlier :( . While going through the codes I came across that we use output() in base.py to print. You have already called if sys.version[0] < '3': basestr = basestring else: basestr = str So basically we know the python version and call the print function according to the python version. If I am correct it is quite easy to fix then, am I?
In the sfepy codebase, there should be no print statements  output() should be used everywhere (if it is not, it's a bug), so yes, updating that for python 3 should be pretty easy.
Cool :)
>
r.
Hi R,
I did some more digging from the implementation point of view and came across some interesting things:
This tutorial demonstrates the solution of Incompressible NavierStokes
Equations using Fenics. it uses Chlorin's method[1] to solve the problem.
This project was very awesome.
http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers...
Then a stackoverflow question where someone says that fenics wasn't fast. http://stackoverflow.com/questions/4768045/fluidflowheattransferandpyth...
Other Implementations:
Here is a list of Open Source CFD codes. Maybe we can fork a repo and use it or learn from it: http://www.cfdonline.com/Wiki/Codes
According to people iNavier and dolphyn are promising: http://www.cfdonline.com/Forums/main/13529colvercodecc.html
Someone was using PyAMG to develop JacobianFree NewtonKrylov code to solve the Navier Stokes equations : https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This is everything I could harness till now. I hope something useful comes out of these. Also I am currently narrowing down and rigorously searching a way to implementing SIMPLE in the FE context.
[1] http://en.wikipedia.org/wiki/Projection_method_%28fluid_dynamics%29
On Thursday, 4 July 2013 19:29:04 UTC+5:30, Ankit Mahato wrote: > > >
On Thursday, 4 July 2013 19:02:50 UTC+5:30, Robert Cimrman wrote: >
On 07/04/2013 03:02 PM, Ankit Mahato wrote:
Hi R,
For our NavierStokes currently we use the Newton method with backtracking linesearch.
Yes, in sfepy we use that.
in OpenFoam and most of the CFD code the linearization approach is based on Patankar's SIMPLE algorithm.[1][2] I talked to my professor who told me that SIMPLE is used in commercial softwares like FLUENT too.
Do you think you could then try implementing SIMPLE in the FE context?
I will search more in this context and let you know in a few hours.
I found few papers which tells us some other approaches. Do have a look at them and lend your views:

http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
 http://www.reactioneng.com/downloads/nksolver_pernice.pdf

http://aerocomlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
 https://cs.uwaterloo.ca/research/tr/1993/02/CS9302.pdf
 http://www.cs.sandia.gov/~rstumin/backtrack.pdf

http://www8.cs.umu.se/kurser/5DA001/HT07/lectures/newtonhandouts.pdf
[1]:
http://www.cfdonline.com/Forums/openfoamsolving/60167hownonlineardiscre... [2]: http://web.cecs.pdx.edu/~gerry/class/ME448/notes/pdf/SIMPLEslides.pdf
Nice list. I will try to look at it, but doubt that I will be of much help in deciding what path to pursue. We need something that could be implemented in a reasonable time. IMHO that rules out the multigridbased solvers, unless a prepared solution like pyamg could be used directly.
Okie.
>
PS: For the python 3 fix which I had forgotten earlier :( . While going through the codes I came across that we use output() in base.py to print. You have already called if sys.version[0] < '3': basestr = basestring else: basestr = str So basically we know the python version and call the print function according to the python version. If I am correct it is quite easy to fix then, am I?
In the sfepy codebase, there should be no print statements  output() should be used everywhere (if it is not, it's a bug), so yes, updating that for python 3 should be pretty easy.
Cool :)
>
r.
On Thu, 4 Jul 2013, Ankit Mahato wrote:
Hi R,
I did some more digging from the implementation point of view and came across some interesting things:
This tutorial demonstrates the solution of Incompressible NavierStokes Equations using Fenics. it uses Chlorin's method[1] to solve the problem. This project was very awesome.Ã¯Â¿Â½ http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers... s/python/documentation.html
That looks feasible as well, although it is for timedependent problems. A stationary solution (if existing) could be obtained by stepping in time til nothing changes.
(Sidenote: fenics is a cool project with many interesting ideas  good place for insiration.)
Then a stackoverflow question where someone says that fenics wasn't fast. http://stackoverflow.com/questions/4768045/fluidflowheattransferandpyth...
As fenics is C++, I would say that it will always be faster than sfepy :) I think that the "slow" in that context meant that the nonlinearity solution converges slowly.
Other Implementations:
There is a thesis to download  might be interesting.
I think it would be easier to follow a paper/thesis, as details in code often differ. But you can try, yes. Note that sfepy is BSDlicensed, so we cannot use snippets/functions from GPLlicensed codes.
According to people iNavier and dolphyn are promising: http://www.cfdonline.com/Forums/main/13529colvercodecc.html
Someone was using PyAMG to develop JacobianFree NewtonKrylov code to solve the Navier Stokes equations : https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the person on how far that project got?
This is everything I could harness till now. I hope something useful comes out of these. Also I am currently narrowing down and rigorously searching a way to implementing SIMPLE in the FE context.
Ok, thanks!
r.
On Friday, 5 July 2013 15:39:07 UTC+5:30, Robert Cimrman wrote: >
On Thu, 4 Jul 2013, Ankit Mahato wrote:
Hi R,
I did some more digging from the implementation point of view and came across some interesting things:
This tutorial demonstrates the solution of Incompressible NavierStokes Equations using Fenics. it uses Chlorin's method[1] to solve the problem. This project was very awesome.ï¿½
http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers... s/python/documentation.html
That looks feasible as well, although it is for timedependent problems. A stationary solution (if existing) could be obtained by stepping in time til nothing changes.
(Sidenote: fenics is a cool project with many interesting ideas  good place for insiration.)
Are you suggesting to use the dolfin module or to use Chlorin's method?
>
Then a stackoverflow question where someone says that fenics wasn't fast.
http://stackoverflow.com/questions/4768045/fluidflowheattransferandpyth...
As fenics is C++, I would say that it will always be faster than sfepy :) I think that the "slow" in that context meant that the nonlinearity solution converges slowly.
Okie :)
Other Implementations:
There is a thesis to download  might be interesting.
Yes, but it is using Difference method.
>
I think it would be easier to follow a paper/thesis, as details in code often differ. But you can try, yes. Note that sfepy is BSDlicensed, so we cannot use snippets/functions from GPLlicensed codes.
So we can use any code with BSD license. right?
>
According to people iNavier and dolphyn are promising: http://www.cfdonline.com/Forums/main/13529colvercodecc.html
Someone was using PyAMG to develop JacobianFree NewtonKrylov code to solve the Navier Stokes equations : https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the person on how far that project got?
i had already dropped a mail on her emailid. Waiting for her reply.
This is everything I could harness till now. I hope something useful comes out of these. Also I am currently narrowing down and rigorously searching a way to implementing SIMPLE in the FE context.
Ok, thanks!
r.
So, it looks there are lot of things I need to look in depth now.
On Fri, 5 Jul 2013, Ankit Mahato wrote:
On Friday, 5 July 2013 15:39:07 UTC+5:30, Robert Cimrman wrote: On Thu, 4 Jul 2013, Ankit Mahato wrote:
> Hi R,
>
> I did some more digging from the implementation point of
view and came
> across some interesting things:
>
> This tutorial demonstrates the solution of Incompressible
NavierStokes
> Equations using Fenics. it uses Chlorin's method[1] to
solve the problem.
> This project was very awesome.Ã¯Â¿Â½
>http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/navierstoke
> s/python/documentation.html
That looks feasible as well, although it is for
timedependent problems. A
stationary solution (if existing) could be obtained by
stepping in time
til nothing changes.
(Sidenote: fenics is a cool project with many interesting
ideas  good
place for insiration.)
Are you suggesting to use the dolfin module or to use Chlorin's method?Ã¯Â¿Â½
The method. Dolfin itself is bigger than sfepy :) Ã¯Â¿Â½
> Other Implementations:
> Ã¯Â¿Â½* Ã¯Â¿Â½Parallel Spectral Numerical Methods/The Two and
ThreeDimensional
> Ã¯Â¿Â½ Ã¯Â¿Â½ NavierStokes
Equationshttp://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two_and_T
h
> Ã¯Â¿Â½ Ã¯Â¿Â½ reeDimensional_NavierStokes_Equations
> Ã¯Â¿Â½* Ã¯Â¿Â½2D NavierStokes solver implemented as a Python package
with Python
> Ã¯Â¿Â½ Ã¯Â¿Â½ modules and C++ extension modules. It uses the finite
difference
> Ã¯Â¿Â½ Ã¯Â¿Â½ method on a uniform, rectangular grid. It handles
single and
> Ã¯Â¿Â½ Ã¯Â¿Â½ twophase incompressible, Newtonian, laminar flow with
obstacles.
> Ã¯Â¿Â½ Ã¯Â¿Â½ https://code.google.com/p/kmkns/
There is a thesis to download  might be interesting.
Yes, but it is using Difference method.
Ok, then it is not directly applicable.
In general, SfePy can assemble the matrices A, B forming a saddle point system with block structure [[A, B], [B^T, 0]]  methods for solving that, making use of A, B, might be usable no matter the method A, B were created (FEM, FVM, FDM).
>
I think it would be easier to follow a
paper/thesis, as
details in code
often differ. But you can try, yes. Note that sfepy is
BSDlicensed, so we
cannot use snippets/functions from GPLlicensed codes.
So we can use any code with BSD license. right?
Yes. Ã¯Â¿Â½
> Someone was using PyAMG to develop
JacobianFree
NewtonKrylov code to
> solve the Navier Stokes equations :
>
https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the
person on how
far that project got?
i had already dropped a mail on her emailid. Waiting for her reply.
Good! Ã¯Â¿Â½
So, it looks there are lot of things I need to look in depth now.
Yes, it is not easy to choose. For the beginning, I would rule out codes that are not FEMbased. As for algorithms, I would look at operator splitting and other iterative techniques.
Thanks for looking into this, it will be very useful.
r.
Some more info: Applying a Newton or Picard iteration produces a system of linear equations which is nonsymmetric in the presence of advection and indefinite in the presence of incompressibility. Such systems, particularly in 3D, are frequently too large for direct solvers, so iterative methods are used, either stationary methods such as successive overrelaxation or Krylov subspace methods. Krylov methods such as GMRES, typically used with preconditioning, operate by minimizing the residual over successive subspaces generated by the preconditioned operator. Multigrid has the advantage of asymptotically optimal performance on many problems. Traditional solvers and preconditioners are effective at reducing highfrequency components of the residual, but lowfrequency components typically require many iterations to reduce. By operating on multiple scales, multigrid reduces all components of the residual by similar factors, leading to a meshindependent number of iterations. For indefinite systems, preconditioners such as incomplete LU factorization, additive Schwarz, and multigrid perform poorly or fail entirely, so the problem structure must be used for effective preconditioning.[1] Methods commonly used in CFD are the SIMPLE and Uzawa algorithms which exhibit meshdependent convergence rates, but recent advances based on block LU factorization combined with multigrid for the resulting definite systems have led to preconditioners that deliver meshindependent convergence rates.[2]
[1] http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid... [2] http://www.sciencedirect.com/science/article/pii/S0021999107004330
On Friday, 5 July 2013 17:23:57 UTC+5:30, Robert Cimrman wrote: >
On Fri, 5 Jul 2013, Ankit Mahato wrote:
On Friday, 5 July 2013 15:39:07 UTC+5:30, Robert Cimrman wrote: On Thu, 4 Jul 2013, Ankit Mahato wrote:
> Hi R,
>
> I did some more digging from the implementation point of
view and came
> across some interesting things:
>
> This tutorial demonstrates the solution of Incompressible
NavierStokes
> Equations using Fenics. it uses Chlorin's method[1] to
solve the problem.
> This project was very awesome.ï¿½
>
http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers...
> s/python/documentation.html
That looks feasible as well, although it is for
timedependent problems. A
stationary solution (if existing) could be obtained by
stepping in time
til nothing changes.
(Sidenote: fenics is a cool project with many interesting
ideas  good
place for insiration.)
Are you suggesting to use the dolfin module or to use Chlorin's method?ï¿½
The method. Dolfin itself is bigger than sfepy :) ï¿½
> Other Implementations:
> ï¿½* ï¿½Parallel Spectral Numerical Methods/The Two and
ThreeDimensional
> ï¿½ ï¿½ NavierStokes Equations
http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two_an... h
> ï¿½ ï¿½ reeDimensional_NavierStokes_Equations
> ï¿½* ï¿½2D NavierStokes solver implemented as a Python package
with Python
> ï¿½ ï¿½ modules and C++ extension modules. It uses the finite
difference
> ï¿½ ï¿½ method on a uniform, rectangular grid. It handles
single and
> ï¿½ ï¿½ twophase incompressible, Newtonian, laminar flow with
obstacles.
> ï¿½ ï¿½ https://code.google.com/p/kmkns/
There is a thesis to download  might be interesting.
Yes, but it is using Difference method.
Ok, then it is not directly applicable.
In general, SfePy can assemble the matrices A, B forming a saddle point system with block structure [[A, B], [B^T, 0]]  methods for solving that, making use of A, B, might be usable no matter the method A, B were created (FEM, FVM, FDM).
I think it would be easier to follow a
paper/thesis, as
details in code
often differ. But you can try, yes. Note that sfepy is
BSDlicensed, so we
cannot use snippets/functions from GPLlicensed codes.
So we can use any code with BSD license. right?
Yes. ï¿½
> Someone was using PyAMG to
develop JacobianFree
NewtonKrylov code to
> solve the Navier Stokes equations :
>
https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the
person on how
far that project got?
i had already dropped a mail on her emailid. Waiting for her reply.
Good! ï¿½
So, it looks there are lot of things I need to look in depth now.
Yes, it is not easy to choose. For the beginning, I would rule out codes that are not FEMbased. As for algorithms, I would look at operator splitting and other iterative techniques.
Thanks for looking into this, it will be very useful.
r.
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
One under BSD but it asn't that good  Clawpack dolfyn  Apache Featflow2  Not listed
These had NS tuorials: HiFlow  LGPL v3 http://www.numhpc.org/HiFlow3_Typo/fileadmin/tutorials/tut_Navier_Stokes_201... Nectar++  Spectral/HP Emement method  http://www.nektar.info  MIT License http://www.nektar.info/wiki/3.3/UserGuide/Tutorial/IncNavierStokesSolver CFD2D  MIT
The ones with MIT license are really good. Especially Nector++ which uses Spectral/HP method.
News pertaining to algorithms:
There are two potential sources of numerical instability in the Galerkin finite element solution of steady NavierStokes problems. The first is due to the treatment of the convective term and manifests itself in high Reynolds number flows when unresolved internal or boundary layers are present in the solution. The second source of potential instability, is an inappropriate combination of interpolation functions for velocity and pressure. Stabilized finite element formulation is used. We have an example of it. Is it not robust R.?
PS. Professors in my department do not use FEM for fluid, but today I came to know about a professor of Aerospace who uses FEM for CFD. I have mailed him for an appointment.
On Monday, 8 July 2013 19:15:53 UTC+5:30, Ankit Mahato wrote: >
Some more info: Applying a Newton or Picard iteration produces a system of linear equations which is nonsymmetric in the presence of advection and indefinite in the presence of incompressibility. Such systems, particularly in 3D, are frequently too large for direct solvers, so iterative methods are used, either stationary methods such as successive overrelaxation or Krylov subspace methods. Krylov methods such as GMRES, typically used with preconditioning, operate by minimizing the residual over successive subspaces generated by the preconditioned operator. Multigrid has the advantage of asymptotically optimal performance on many problems. Traditional solvers and preconditioners are effective at reducing highfrequency components of the residual, but lowfrequency components typically require many iterations to reduce. By operating on multiple scales, multigrid reduces all components of the residual by similar factors, leading to a meshindependent number of iterations. For indefinite systems, preconditioners such as incomplete LU factorization, additive Schwarz, and multigrid perform poorly or fail entirely, so the problem structure must be used for effective preconditioning.[1] Methods commonly used in CFD are the SIMPLE and Uzawa algorithms which exhibit meshdependent convergence rates, but recent advances based on block LU factorization combined with multigrid for the resulting definite systems have led to preconditioners that deliver meshindependent convergence rates.[2]
[1] http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid... [2] http://www.sciencedirect.com/science/article/pii/S0021999107004330
On Friday, 5 July 2013 17:23:57 UTC+5:30, Robert Cimrman wrote: >
On Fri, 5 Jul 2013, Ankit Mahato wrote:
On Friday, 5 July 2013 15:39:07 UTC+5:30, Robert Cimrman wrote: On Thu, 4 Jul 2013, Ankit Mahato wrote:
> Hi R,
>
> I did some more digging from the implementation point of
view and came
> across some interesting things:
>
> This tutorial demonstrates the solution of Incompressible
NavierStokes
> Equations using Fenics. it uses Chlorin's method[1] to
solve the problem.
> This project was very awesome.ï¿½
>
http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers...
> s/python/documentation.html
That looks feasible as well, although it is for
timedependent problems. A
stationary solution (if existing) could be obtained by
stepping in time
til nothing changes.
(Sidenote: fenics is a cool project with many interesting
ideas  good
place for insiration.)
Are you suggesting to use the dolfin module or to use Chlorin's method?ï¿½
The method. Dolfin itself is bigger than sfepy :) ï¿½
> Other Implementations:
> ï¿½* ï¿½Parallel Spectral Numerical Methods/The Two and
ThreeDimensional
> ï¿½ ï¿½ NavierStokes Equations
http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two_an... h
> ï¿½ ï¿½ reeDimensional_NavierStokes_Equations
> ï¿½* ï¿½2D NavierStokes solver implemented as a Python package
with Python
> ï¿½ ï¿½ modules and C++ extension modules. It uses the finite
difference
> ï¿½ ï¿½ method on a uniform, rectangular grid. It handles
single and
> ï¿½ ï¿½ twophase incompressible, Newtonian, laminar flow with
obstacles.
> ï¿½ ï¿½ https://code.google.com/p/kmkns/
There is a thesis to download  might be interesting.
Yes, but it is using Difference method.
Ok, then it is not directly applicable.
In general, SfePy can assemble the matrices A, B forming a saddle point system with block structure [[A, B], [B^T, 0]]  methods for solving that, making use of A, B, might be usable no matter the method A, B were created (FEM, FVM, FDM).
I think it would be easier to follow a
paper/thesis, as
details in code
often differ. But you can try, yes. Note that sfepy is
BSDlicensed, so we
cannot use snippets/functions from GPLlicensed codes.
So we can use any code with BSD license. right?
Yes. ï¿½
> Someone was using PyAMG to
develop JacobianFree
NewtonKrylov code to
> solve the Navier Stokes equations :
>
https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the
person on how
far that project got?
i had already dropped a mail on her emailid. Waiting for her reply.
Good! ï¿½
So, it looks there are lot of things I need to look in depth now.
Yes, it is not easy to choose. For the beginning, I would rule out codes that are not FEMbased. As for algorithms, I would look at operator splitting and other iterative techniques.
Thanks for looking into this, it will be very useful.
r.
On 07/09/2013 06:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
One under BSD but it asn't that good  Clawpack dolfyn  Apache Featflow2  Not listed
These had NS tuorials: HiFlow  LGPL v3 http://www.numhpc.org/HiFlow3_Typo/fileadmin/tutorials/tut_Navier_Stokes_201... Nectar++  Spectral/HP Emement method  http://www.nektar.info  MIT License http://www.nektar.info/wiki/3.3/UserGuide/Tutorial/IncNavierStokesSolver CFD2D  MIT
The ones with MIT license are really good. Especially Nector++ which uses Spectral/HP method.
Wow, thanks for digging into it! I do not think even the licensefriendly ones could be used with sfepy easily (everybody has different data structures etc.), but we could try to implement some of their FEspecific algorithms, if those are documented.
News pertaining to algorithms:
Ok. Is it due to the fact that face fluxes need to be computed?
Ok.
Very basic intro: https://en.wikipedia.org/wiki/Preconditioner#Preconditioning_for_linear_syst...
The idea of preconditioning is simple, but it is often hard to find a good preconditioner for a specific problem (class). I know what works for Laplacian (e.g. algebraic multigrid), but I have not much knowledge about NavierStokes.
There are two potential sources of numerical instability in the Galerkin finite element solution of steady NavierStokes problems. The first is due to the treatment of the convective term and manifests itself in high Reynolds number flows when unresolved internal or boundary layers are present in the solution. The second source of potential instability, is an inappropriate combination of interpolation functions for velocity and pressure. Stabilized finite element formulation is used. We have an example of it. Is it not robust R.?
The second issue is solved by proper polynomial approximation orders of fields, this is ok. The first one is the main PITA.
PS. Professors in my department do not use FEM for fluid, but today I came to know about a professor of Aerospace who uses FEM for CFD. I have mailed him for an appointment.
Ok, let me know how it went!
r. PS: I still did not get to the articles, stay tuned...
>
On Monday, 8 July 2013 19:15:53 UTC+5:30, Ankit Mahato wrote: >
Some more info: Applying a Newton or Picard iteration produces a system of linear equations which is nonsymmetric in the presence of advection and indefinite in the presence of incompressibility. Such systems, particularly in 3D, are frequently too large for direct solvers, so iterative methods are used, either stationary methods such as successive overrelaxation or Krylov subspace methods. Krylov methods such as GMRES, typically used with preconditioning, operate by minimizing the residual over successive subspaces generated by the preconditioned operator. Multigrid has the advantage of asymptotically optimal performance on many problems. Traditional solvers and preconditioners are effective at reducing highfrequency components of the residual, but lowfrequency components typically require many iterations to reduce. By operating on multiple scales, multigrid reduces all components of the residual by similar factors, leading to a meshindependent number of iterations. For indefinite systems, preconditioners such as incomplete LU factorization, additive Schwarz, and multigrid perform poorly or fail entirely, so the problem structure must be used for effective preconditioning.[1] Methods commonly used in CFD are the SIMPLE and Uzawa algorithms which exhibit meshdependent convergence rates, but recent advances based on block LU factorization combined with multigrid for the resulting definite systems have led to preconditioners that deliver meshindependent convergence rates.[2]
[1] http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid... [2] http://www.sciencedirect.com/science/article/pii/S0021999107004330
On Friday, 5 July 2013 17:23:57 UTC+5:30, Robert Cimrman wrote: >
On Fri, 5 Jul 2013, Ankit Mahato wrote:
> >
On Friday, 5 July 2013 15:39:07 UTC+5:30, Robert Cimrman wrote: On Thu, 4 Jul 2013, Ankit Mahato wrote:
> Hi R,
>
> I did some more digging from the implementation point of
view and came
> across some interesting things:
>
> This tutorial demonstrates the solution of Incompressible
NavierStokes
> Equations using Fenics. it uses Chlorin's method[1] to
solve the problem.
> This project was very awesome.ï¿½
>
http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers...
> s/python/documentation.html
That looks feasible as well, although it is for
timedependent problems. A
stationary solution (if existing) could be obtained by
stepping in time
til nothing changes.
(Sidenote: fenics is a cool project with many interesting
ideas  good
place for insiration.)
Are you suggesting to use the dolfin module or to use Chlorin's method?ï¿½
The method. Dolfin itself is bigger than sfepy :) ï¿½
> Other Implementations:
> ï¿½* ï¿½Parallel Spectral Numerical Methods/The Two and
ThreeDimensional
> ï¿½ ï¿½ NavierStokes Equations
http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two_an... h
> ï¿½ ï¿½ reeDimensional_NavierStokes_Equations
> ï¿½* ï¿½2D NavierStokes solver implemented as a Python package
with Python
> ï¿½ ï¿½ modules and C++ extension modules. It uses the finite
difference
> ï¿½ ï¿½ method on a uniform, rectangular grid. It handles
single and
> ï¿½ ï¿½ twophase incompressible, Newtonian, laminar flow with
obstacles.
> ï¿½ ï¿½ https://code.google.com/p/kmkns/
There is a thesis to download  might be interesting.
Yes, but it is using Difference method.
Ok, then it is not directly applicable.
In general, SfePy can assemble the matrices A, B forming a saddle point system with block structure [[A, B], [B^T, 0]]  methods for solving that, making use of A, B, might be usable no matter the method A, B were created (FEM, FVM, FDM).
>
I think it would be easier to follow
a paper/thesis, as
details in code
often differ. But you can try, yes. Note that sfepy is
BSDlicensed, so we
cannot use snippets/functions from GPLlicensed codes.
So we can use any code with BSD license. right?
Yes. ï¿½
> Someone was using PyAMG to
develop JacobianFree
NewtonKrylov code to
> solve the Navier Stokes equations :
>
https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the
person on how
far that project got?
i had already dropped a mail on her emailid. Waiting for her reply.
Good! ï¿½
So, it looks there are lot of things I need to look in depth now.
Yes, it is not easy to choose. For the beginning, I would rule out codes that are not FEMbased. As for algorithms, I would look at operator splitting and other iterative techniques.
Thanks for looking into this, it will be very useful.
r.
On Tuesday, 9 July 2013 22:11:09 UTC+5:30, Robert Cimrman wrote: >
On 07/09/2013 06:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
One under BSD but it asn't that good  Clawpack dolfyn  Apache Featflow2  Not listed
These had NS tuorials: HiFlow  LGPL v3
http://www.numhpc.org/HiFlow3_Typo/fileadmin/tutorials/tut_Navier_Stokes_201... Nectar++  Spectral/HP Emement method  http://www.nektar.info  MIT License http://www.nektar.info/wiki/3.3/UserGuide/Tutorial/IncNavierStokesSolver CFD2D  MIT
The ones with MIT license are really good. Especially Nector++ which uses Spectral/HP method.
Wow, thanks for digging into it! I do not think even the licensefriendly ones could be used with sfepy easily (everybody has different data structures etc.), but we could try to implement some of their FEspecific algorithms, if those are documented.
yes everybody has a different data structure but we can write a parser to convert from one input form to another. It can be done.
>
News pertaining to algorithms:
Ok. Is it due to the fact that face fluxes need to be computed?
This conclusion was initially made based on the fact that FEM people do not use it.
But looking deeper: A staggered gird is used (there is a detailed reason)
Here is the algorithm: SIMPLE algorithm involves something called as pressure correction term ( p' ). p = p + p' where p is the guessed pressure such that the resulting starred velocity field will progressively get closer to satisfying the continuity equation.
The corressponding velocity corrections u' , v' is introduced in similar manner u = u + u' v = v + v'
A = delta t/ rho t is time u' = A (\partial p') / (\partial x) v' = A (\partial p') / (\partial y) \laplace p' = 1/A x (\del \cdot \vector{v*}) where v is velocity
1) Guess pressur p 2) Solve momentum eq to find u v 3) find p' using \vector{v} 4) Now correct pressure and velocity. 5) Now iterate.
Yes face fluxes are computed to find the pressure correction term p' in FVM.
>
Ok.
Very basic intro:
https://en.wikipedia.org/wiki/Preconditioner#Preconditioning_for_linear_syst...
The idea of preconditioning is simple, but it is often hard to find a good preconditioner for a specific problem (class). I know what works for Laplacian (e.g. algebraic multigrid), but I have not much knowledge about NavierStokes.
Thankx.
There are two potential sources of numerical instability in the Galerkin finite element solution of steady NavierStokes problems. The first is due to the treatment of the convective term and manifests itself in high Reynolds number flows when unresolved internal or boundary layers are present in the solution. The second source of potential instability, is an inappropriate combination of interpolation functions for velocity and pressure. Stabilized finite element formulation is used. We have an example of it. Is it not robust R.?
The second issue is solved by proper polynomial approximation orders of fields, this is ok. The first one is the main PITA.
Okie
>
PS. Professors in my department do not use FEM for fluid, but today I came to know about a professor of Aerospace who uses FEM for CFD. I have mailed him for an appointment.
Ok, let me know how it went!
Yes definitely.
>
r. PS: I still did not get to the articles, stay tuned...
On Monday, 8 July 2013 19:15:53 UTC+5:30, Ankit Mahato wrote:
Some more info: Applying a Newton or Picard iteration produces a system of linear equations which is nonsymmetric in the presence of advection and indefinite in the presence of incompressibility. Such systems, particularly in 3D, are frequently too large for direct solvers, so iterative methods are used, either stationary methods such as successive overrelaxation or Krylov subspace methods. Krylov methods such as GMRES, typically used with preconditioning, operate by minimizing the residual over successive subspaces generated by the preconditioned operator. Multigrid has the advantage of asymptotically optimal performance on many problems. Traditional solvers and preconditioners are effective at reducing highfrequency components of the residual, but lowfrequency components typically require many iterations to reduce. By operating on multiple scales, multigrid reduces all components of the residual by similar factors, leading to a meshindependent number of iterations. For indefinite systems, preconditioners such as incomplete LU factorization, additive Schwarz, and multigrid perform poorly or fail entirely, so the problem structure must be used for effective preconditioning.[1] Methods commonly used in CFD are the SIMPLE and Uzawa algorithms which exhibit meshdependent convergence rates, but recent advances based on block LU factorization combined with multigrid for the resulting definite systems have led to preconditioners that deliver meshindependent convergence rates.[2]
[1]
http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid... [2] http://www.sciencedirect.com/science/article/pii/S0021999107004330
On Friday, 5 July 2013 17:23:57 UTC+5:30, Robert Cimrman wrote:
On Fri, 5 Jul 2013, Ankit Mahato wrote:
On Friday, 5 July 2013 15:39:07 UTC+5:30, Robert Cimrman wrote: On Thu, 4 Jul 2013, Ankit Mahato wrote:
> Hi R,
>
> I did some more digging from the implementation point of
view and came
> across some interesting things:
>
> This tutorial demonstrates the solution of Incompressible
NavierStokes
> Equations using Fenics. it uses Chlorin's method[1] to
solve the problem.
> This project was very awesome.ï¿½
>
http://fenicsproject.org/documentation/dolfin/1.2.0/python/demo/pde/naviers...
> s/python/documentation.html
That looks feasible as well, although it is for
timedependent problems. A
stationary solution (if existing) could be obtained by
stepping in time
til nothing changes.
(Sidenote: fenics is a cool project with many interesting
ideas  good
place for insiration.)
Are you suggesting to use the dolfin module or to use Chlorin's method?ï¿½
The method. Dolfin itself is bigger than sfepy :) ï¿½
> Other Implementations:
> ï¿½* ï¿½Parallel Spectral Numerical Methods/The Two and
ThreeDimensional
> ï¿½ ï¿½ NavierStokes Equations
http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two_an...
h
> ï¿½ ï¿½ reeDimensional_NavierStokes_Equations
> ï¿½* ï¿½2D NavierStokes solver implemented as a Python
package with Python
> ï¿½ ï¿½ modules and C++ extension modules. It uses the
finite difference
> ï¿½ ï¿½ method on a uniform, rectangular grid. It handles
single and
> ï¿½ ï¿½ twophase incompressible, Newtonian, laminar flow
with obstacles.
> ï¿½ ï¿½ https://code.google.com/p/kmkns/
There is a thesis to download  might be interesting.
Yes, but it is using Difference method.
Ok, then it is not directly applicable.
In general, SfePy can assemble the matrices A, B forming a saddle point system with block structure [[A, B], [B^T, 0]]  methods for solving that, making use of A, B, might be usable no matter the method A, B were created (FEM, FVM, FDM).
I think it would be easier to follow
a paper/thesis, as
details in code
often differ. But you can try, yes. Note that sfepy is
BSDlicensed, so we
cannot use snippets/functions from GPLlicensed codes.
So we can use any code with BSD license. right?
Yes. ï¿½
> Someone was using PyAMG to
develop JacobianFree
NewtonKrylov code to
> solve the Navier Stokes equations :
>
https://groups.google.com/forum/#!topic/pyamguser/HXrXTyvXPpw
This could be really interesting  maybe you could ask the
person on how
far that project got?
i had already dropped a mail on her emailid. Waiting for her reply.
Good! ï¿½
So, it looks there are lot of things I need to look in depth now.
Yes, it is not easy to choose. For the beginning, I would rule out codes that are not FEMbased. As for algorithms, I would look at operator splitting and other iterative techniques.
Thanks for looking into this, it will be very useful.
r.
On 07/09/2013 07:35 PM, Ankit Mahato wrote: > >
On Tuesday, 9 July 2013 22:11:09 UTC+5:30, Robert Cimrman wrote: >
On 07/09/2013 06:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
One under BSD but it asn't that good  Clawpack dolfyn  Apache Featflow2  Not listed
These had NS tuorials: HiFlow  LGPL v3
http://www.numhpc.org/HiFlow3_Typo/fileadmin/tutorials/tut_Navier_Stokes_201... Nectar++  Spectral/HP Emement method  http://www.nektar.info  MIT License http://www.nektar.info/wiki/3.3/UserGuide/Tutorial/IncNavierStokesSolver CFD2D  MIT
The ones with MIT license are really good. Especially Nector++ which uses Spectral/HP method.
Wow, thanks for digging into it! I do not think even the licensefriendly ones could be used with sfepy easily (everybody has different data structures etc.), but we could try to implement some of their FEspecific algorithms, if those are documented.
yes everybody has a different data structure but we can write a parser to convert from one input form to another. It can be done.
Yes, I was too quick in the reply. Actually, there is no problem in using GPLed solvers (for example umfpack is GPLed) as long as there are Python wrappers. Then all that is necessary is to add the solver into the framework in sfepy/solvers/. The easiest would be to use solvers that could accept the individual operator matrices as assembled by sfepy.
>
News pertaining to algorithms:
Ok. Is it due to the fact that face fluxes need to be computed?
This conclusion was initially made based on the fact that FEM people do not use it.
But looking deeper: A staggered gird is used (there is a detailed reason)
Here is the algorithm: SIMPLE algorithm involves something called as pressure correction term ( p' ). p = p + p' where p is the guessed pressure such that the resulting starred velocity field will progressively get closer to satisfying the continuity equation.
The corressponding velocity corrections u' , v' is introduced in similar manner u = u + u' v = v + v'
A = delta t/ rho t is time u' = A (\partial p') / (\partial x) v' = A (\partial p') / (\partial y) \laplace p' = 1/A x (\del \cdot \vector{v*}) where v is velocity
1) Guess pressur p 2) Solve momentum eq to find u v 3) find p' using \vector{v} 4) Now correct pressure and velocity. 5) Now iterate.
Yes face fluxes are computed to find the pressure correction term p' in FVM.
So the staggered grid seems to be the main problem. Ok.
r.
On Wednesday, 10 July 2013 13:36:12 UTC+5:30, Robert Cimrman wrote: >
On 07/09/2013 07:35 PM, Ankit Mahato wrote:
On Tuesday, 9 July 2013 22:11:09 UTC+5:30, Robert Cimrman wrote:
On 07/09/2013 06:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
One under BSD but it asn't that good  Clawpack dolfyn  Apache Featflow2  Not listed
These had NS tuorials: HiFlow  LGPL v3
http://www.numhpc.org/HiFlow3_Typo/fileadmin/tutorials/tut_Navier_Stokes_201...
Nectar++  Spectral/HP Emement method  http://www.nektar.info  MIT License
http://www.nektar.info/wiki/3.3/UserGuide/Tutorial/IncNavierStokesSolver CFD2D  MIT
The ones with MIT license are really good. Especially Nector++ which uses Spectral/HP method.
Wow, thanks for digging into it! I do not think even the licensefriendly ones could be used with sfepy easily (everybody has different data structures etc.), but we could try to implement some of their FEspecific algorithms, if those are documented.
yes everybody has a different data structure but we can write a parser to convert from one input form to another. It can be done.
Yes, I was too quick in the reply. Actually, there is no problem in using GPLed solvers (for example umfpack is GPLed) as long as there are Python wrappers. Then all that is necessary is to add the solver into the framework in sfepy/solvers/. The easiest would be to use solvers that could accept the individual operator matrices as assembled by sfepy.
cool :) okie.
>
News pertaining to algorithms:
Ok. Is it due to the fact that face fluxes need to be computed?
This conclusion was initially made based on the fact that FEM people do not use it.
But looking deeper: A staggered gird is used (there is a detailed reason)
Here is the algorithm: SIMPLE algorithm involves something called as pressure correction term ( p' ). p = p + p' where p is the guessed pressure such that the resulting starred velocity field will progressively get closer to satisfying the continuity equation.
The corressponding velocity corrections u' , v' is introduced in similar manner u = u + u' v = v + v'
A = delta t/ rho t is time u' = A (\partial p') / (\partial x) v' = A (\partial p') / (\partial y) \laplace p' = 1/A x (\del \cdot \vector{v*}) where v is velocity
1) Guess pressur p 2) Solve momentum eq to find u v 3) find p' using \vector{v} 4) Now correct pressure and velocity. 5) Now iterate.
Yes face fluxes are computed to find the pressure correction term p' in FVM.
So the staggered grid seems to be the main problem. Ok.
r.
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends up adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
On 07/10/2013 01:53 AM, osman buyukisik wrote:
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends up adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
Thanks for the links! fenics is always a good source for inspiration.
BTW. Ankit, what Reynolds numbers are typical for the flows you would like to simulate?
r.
On Wednesday, 10 July 2013 18:06:26 UTC+5:30, Robert Cimrman wrote: >
On 07/10/2013 01:53 AM, osman buyukisik wrote:
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends up adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
Thanks for the links! fenics is always a good source for inspiration.
BTW. Ankit, what Reynolds numbers are typical for the flows you would like to simulate?
Haven't calculated yet for the final problem. but would go with low reynolds number for pipe flow and the phase change part itself has low reynolds number in the cavity.
>
r.
On 07/10/2013 09:16 PM, Ankit Mahato wrote: > >
On Wednesday, 10 July 2013 18:06:26 UTC+5:30, Robert Cimrman wrote: >
On 07/10/2013 01:53 AM, osman buyukisik wrote:
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends up adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
Thanks for the links! fenics is always a good source for inspiration.
BTW. Ankit, what Reynolds numbers are typical for the flows you would like to simulate?
Haven't calculated yet for the final problem. but would go with low reynolds number for pipe flow and the phase change part itself has low reynolds number in the cavity.
Good. That means less worries about the convective stabilisation.
r.
Hi R,
I had a talk with a professor who suggested me the following:
Spectral/hp element method will require a strong mathematical knowledge to proceed. Chlorin Projection method is widely prevalent but it requires a separate formulation of matrices and not our current formulation. GMRES with ILU(0) preconditioning may still not work for convection dominated problem(our main PITA) and he told me that there are schemes to handle convection dominated problems where some some terms are added which die with successive iteration and I should look for these schemes on the internet.
Regards.
On Thursday, 11 July 2013 19:27:23 UTC+5:30, Robert Cimrman wrote: >
On 07/10/2013 09:16 PM, Ankit Mahato wrote:
On Wednesday, 10 July 2013 18:06:26 UTC+5:30, Robert Cimrman wrote:
On 07/10/2013 01:53 AM, osman buyukisik wrote:
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends up adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
Thanks for the links! fenics is always a good source for inspiration.
BTW. Ankit, what Reynolds numbers are typical for the flows you would like to simulate?
Haven't calculated yet for the final problem. but would go with low reynolds number for pipe flow and the phase change part itself has low reynolds number in the cavity.
Good. That means less worries about the convective stabilisation.
r.
On 07/26/2013 01:08 PM, Ankit Mahato wrote:
Hi R,
I had a talk with a professor who suggested me the following:
Spectral/hp element method will require a strong mathematical knowledge to proceed. Chlorin Projection method is widely prevalent but it requires a separate formulation of matrices and not our current formulation.
What do you mean by separate formulation of matrices? Having the individual matrix blocks? That is certainly possible. You would have to write a special solver making use of that, yes.
GMRES with ILU(0) preconditioning may still not work for convection dominated problem(our main PITA) and he told me that there are schemes to handle convection dominated problems where some some terms are added which die with successive iteration and I should look for these schemes on the internet.
We do have stabilization terms, see [1]. The problem is they depend on some parameters and I never worked enough with those terms to learn how to use them properly. It is easy to overstabilize. And you still have to solve the linear system. As you said that the Reynolds numbers would not be high in your problems, I would try GMRES with ILU(0) anyway.
r.
[1] http://docs.sfepy.org/docdevel/examples/navier_stokes/stabilized_navier_sto...
Regards.
On Thursday, 11 July 2013 19:27:23 UTC+5:30, Robert Cimrman wrote: >
On 07/10/2013 09:16 PM, Ankit Mahato wrote: > >
On Wednesday, 10 July 2013 18:06:26 UTC+5:30, Robert Cimrman wrote: >
On 07/10/2013 01:53 AM, osman buyukisik wrote:
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
I went through the codes I mentioned above: The following solvers were good but were licensed under GPL DUNS 2d/3d navier Stokes  GNU GPL license 2.0 Channelflow  GNU GPL2 OpenFlower  GPLv2 PETScFEM  GPLv2 Tochnog  GPL
Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends up
adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
Thanks for the links! fenics is always a good source for inspiration.
BTW. Ankit, what Reynolds numbers are typical for the flows you would like to simulate?
Haven't calculated yet for the final problem. but would go with low reynolds number for pipe flow and the phase change part itself has low reynolds number in the cavity.
Good. That means less worries about the convective stabilisation.
r.
On Friday, 26 July 2013 16:58:26 UTC+5:30, Robert Cimrman wrote: >
On 07/26/2013 01:08 PM, Ankit Mahato wrote:
Hi R,
I had a talk with a professor who suggested me the following:
Spectral/hp element method will require a strong mathematical knowledge to proceed. Chlorin Projection method is widely prevalent but it requires a separate formulation of matrices and not our current formulation.
What do you mean by separate formulation of matrices? Having the individual matrix blocks? That is certainly possible. You would have to write a special solver making use of that, yes.
Yes. we have to develop a special solver.
>
GMRES with ILU(0) preconditioning may still not work for convection dominated problem(our main PITA) and he told me that there are schemes to handle convection dominated problems where some some terms are added which die with successive iteration and I should look for these schemes on the internet.
We do have stabilization terms, see [1]. The problem is they depend on some parameters and I never worked enough with those terms to learn how to use them properly. It is easy to overstabilize. And you still have to solve the linear system. As you said that the Reynolds numbers would not be high in your problems, I would try GMRES with ILU(0) anyway.
GMRES with ILU(0) it is then.
>
r.
[1]
http://docs.sfepy.org/docdevel/examples/navier_stokes/stabilized_navier_sto...
Regards.
On Thursday, 11 July 2013 19:27:23 UTC+5:30, Robert Cimrman wrote:
On 07/10/2013 09:16 PM, Ankit Mahato wrote:
On Wednesday, 10 July 2013 18:06:26 UTC+5:30, Robert Cimrman wrote:
On 07/10/2013 01:53 AM, osman buyukisik wrote:
On 07/09/2013 12:29 PM, Ankit Mahato wrote:
> I went through the codes I mentioned above: > The following solvers were good but were licensed under GPL > DUNS 2d/3d navier Stokes  GNU GPL license 2.0 > Channelflow  GNU GPL2 > OpenFlower  GPLv2 > PETScFEM  GPLv2 > Tochnog  GPL > Ankit, I think Fenics project's application cbcpdesys might be the best choice as it is in python and solvers are mainly called from python. Has a few turbulence models already coded. Might be a good idea to look how they did it (it is FE based). None of the codes you listed is python based. Another FE based solver that may be scripted with python is Fluidity from http://amcg.ese.ic.ac.uk/index.php?title=Fluidity again just to investigate how they do it.
You might want to think about using petsc solver suite (from Argonne National Labs) to be called from python as in fenics/dolfin. It has quite a few choices for solving nolinear systems. Its license seems very liberal (like bsd).
You'll need to solve not NS but Reynolds averaged NS. This ends
up adding additional equations related to turbulence. Just NS by itself will diverge as the Reynolds number goes above a certain value. All of this already done in cbcpdesys. It is GNU LGPL so should be ok to use with bsd. But you won't be copying verbatim anyways.
just a few thoughts. I use fluent at work and many open cfd codes at home. Regards, Osman
Thanks for the links! fenics is always a good source for inspiration.
BTW. Ankit, what Reynolds numbers are typical for the flows you would like to simulate?
Haven't calculated yet for the final problem. but would go with low reynolds number for pipe flow and the phase change part itself has low reynolds number in the cavity.
Good. That means less worries about the convective stabilisation.
r.