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
> PETSc-FEM - 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_2012_03.pdf
> 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 license-friendly ones
could be used with sfepy easily (everybody has different data structures etc.),
but we could try to implement some of their FE-specific 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:
> - SIMPLE cannot be used under FE context.

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.

> - I went through GEORGE EM KARNIADAKIS & SPENCER J. SHERWIN Spectral/hp
> Element Methods for CFD.
> It required strong mathematical background to understand which I do not
> possess.
> - Chorin-Temam projection method- Currently going through it.

Ok.

> - PyAMG - Jacobian-Free Newton-Krylov code to solve the Navier Stokes
> equations : Christine sent me no response in spite of a reminder.
> - Matrix preconditioning techniques for GMRES - I do not know about matrix
> preconditioning. I downloaded some papers in order to understand it.
> If you know about any good resource on preconditioning then kindly give me
> the link.

Very basic intro:
https://en.wikipedia.org/wiki/Preconditioner#Preconditioning_for_linear_systems

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 Navier-Stokes.

Thankx.

> There are two potential sources of numerical instability in the Galerkin
> finite element solution of steady Navier-Stokes 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
>> high-frequency components of the residual, but low-frequency 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 mesh-independent 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 mesh-dependent convergence rates, but recent
>> advances based on block LU factorization combined with multigrid for the
>> resulting definite systems have led to preconditioners that deliver
>> mesh-independent convergence rates.[2]
>>
>> [1]
>> http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=298722
>> [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
>>>> Navier-Stokes
>>>> > 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/navier-stoke
>>>>
>>>> > s/python/documentation.html
>>>>
>>>> That looks feasible as well, although it is for
>>>> time-dependent 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
>>>> Three-Dimensional
>>>> > ï¿½ ï¿½ Navier-Stokes Equations-
>>> http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two-_and_T
>>>> h
>>>> > ï¿½ ï¿½ ree-Dimensional_Navier-Stokes_Equations
>>>> > ï¿½* ï¿½2D Navier-Stokes 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
>>>> > ï¿½ ï¿½ two-phase 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
>>>> BSD-licensed, so we
>>>> cannot use snippets/functions from GPL-licensed codes.
>>>>
>>>>
>>>> So we can use any code with BSD license. right?
>>>
>>> Yes.
>>> ï¿½
>>>> > Someone was using PyAMG to develop Jacobian-Free
>>>> Newton-Krylov code to
>>>> > solve the Navier Stokes equations :
>>>> >
>>>> https://groups.google.com/forum/#!topic/pyamg-user/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 email-id. 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 FEM-based. As for algorithms, I would look at operator
>>> splitting and other iterative techniques.
>>>
>>> Thanks for looking into this, it will be very useful.
>>>
>>> r.
>>>
>>
>