2d NS terms

[Robert Cimrman]

Hi,

I have removed the "3d only" restriction from the Navier Stokes and related
terms. There is also a new example: examples/navier_stokes/navier_stokes2d.py.

r.

[Ankit Mahato]

awesome :)

[Robert Cimrman]

Now it remains to implement a robust flow solver. Even this small example
shows, that the solution is not obtained easily - try decreasing the viscosity,
and/or increase the Dirichlet velocity - the solver would not converge.

Cheers,
r.
PS: As mentioned in Terri Oda's e-mail, you should blog about your work so far
ASAP!

[Ankit Mahato]

R,

I was getting an error while running the example.
./simple.py examples/navier_stokes/navier_stokes2d.py
sfepy: left over: ['data_dir', 'verbose', '_filename', '__builtins__', '__package__', '__doc__', '__name__', '__file__']
sfepy: reading mesh (/home/ankit/sfepy/meshes/2d/rectangle_fine_quad.mesh)...
sfepy: ...done in 0.02 s
sfepy: creating regions...
sfepy:     Right
sfepy:     Bottom
sfepy:     Top
sfepy:     Surface
sfepy:     Omega
sfepy:     Walls
sfepy:     Driven
sfepy: ...done in 0.03 s
sfepy: equation "balance":
sfepy: + dw_div_grad.5.Omega(fluid.viscosity, v, u)
       + dw_convect.5.Omega(v, u)
       - dw_stokes.5.Omega(v, p) = 0
sfepy: equation "incompressibility":
sfepy: dw_stokes.5.Omega(u, q) = 0
sfepy: setting up dof connectivities...
sfepy: ...done in 0.00 s
sfepy: using solvers:
                ts: no ts
               nls: newton
                ls: ls
sfepy: updating variables...
sfepy: ...done
sfepy: matrix shape: (44557, 44557)
sfepy: assembling matrix graph...
sfepy: ...done in 0.13 s
sfepy: matrix structural nonzeros: 1728264 (8.71e-04% fill)
sfepy: updating materials...
sfepy:     fluid
sfepy: ...done in 0.01 s
sfepy: nls: iter: 0, residual: 2.023986e-02 (rel: 1.000000e+00)
convect_build_vtg(): ERR_Switch
mem_free_mem(): error exit!
mem_free_mem(): error exit!
mem_free_mem(): error exit!
mem_free_mem(): error exit!
mem_free_mem(): error exit!
mem_free_mem(): error exit!
mem_free_mem(): error exit!
mem_free_mem(): error exit!
Traceback (most recent call last):
  File "./simple.py", line 146, in <module>
    main()
  File "./simple.py", line 143, in main
    app()
  File "/home/ankit/sfepy/sfepy/applications/application.py", line 29, in call_basic
    return self.call(**kwargs)
  File "/home/ankit/sfepy/sfepy/applications/pde_solver_app.py", line 213, in call
    nls_status=nls_status)
  File "/home/ankit/sfepy/sfepy/solvers/ts_solvers.py", line 29, in __call__
    state = problem.solve(state0=state0, nls_status=nls_status)
  File "/home/ankit/sfepy/sfepy/fem/problemDef.py", line 933, in solve
    vec = solvers.nls(vec0)
  File "/home/ankit/sfepy/sfepy/solvers/nls.py", line 345, in __call__
    mtx_a = fun_grad(vec_x)
  File "/home/ankit/sfepy/sfepy/fem/evaluate.py", line 66, in eval_tangent_matrix
    mtx = pb.equations.eval_tangent_matrices(vec, mtx)
  File "/home/ankit/sfepy/sfepy/fem/equations.py", line 640, in eval_tangent_matrices
    self.evaluate(mode='weak', dw_mode='matrix', asm_obj=tangent_matrix)
  File "/home/ankit/sfepy/sfepy/fem/equations.py", line 526, in evaluate
    asm_obj=asm_obj)
  File "/home/ankit/sfepy/sfepy/fem/equations.py", line 766, in evaluate
    ret_status=True)
  File "/home/ankit/sfepy/sfepy/terms/terms.py", line 1473, in evaluate
    diff_var, **kwargs)
  File "/home/ankit/sfepy/sfepy/terms/terms.py", line 1311, in eval_real
    status = self.call_function(out, fargs)
  File "/home/ankit/sfepy/sfepy/terms/terms.py", line 1296, in call_function
    raise ValueError('term evaluation failed! (%s)' % self.name)
ValueError: term evaluation failed! (dw_convect)

Regards,
Ankit

PS: I was not aware that we have to blog weekly. I will blog for week 1 and 2 asap.

[Robert Cimrman]

Did you rebuild the sources?

> Regards,
> Ankit
>
> PS: I was not aware that we have to blog weekly. I will blog for week 1 and
> 2 asap.

It's either weekly or bi-weekly...

r.

[Robert Cimrman]

I have tried it now on a 32 bit box to be sure, and found no problems...

>> Regards,
>> Ankit
>>
>> PS: I was not aware that we have to blog weekly. I will blog for week 1 and
>> 2 asap.
>
> It's either weekly or bi-weekly...

But as it is week no. 3, it should be up ASAP :)

r.

[Ankit Mahato]

On Tuesday, 2 July 2013 13:58:20 UTC+5:30, Robert Cimrman wrote:

Now it remains to implement a robust flow solver. Even this small example
shows, that the solution is not obtained easily - try decreasing the viscosity,
and/or increase the Dirichlet velocity - the solver would not converge.

Yes R,

The solution is not obtained easily.
I am looking into it.

PS: Here are blog posts for week 1 & 2
Kindly tell me if this will do before I send it to terri oda:

http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc.html
http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc_2.html

[Ankit Mahato]

On Tuesday, 2 July 2013 19:06:16 UTC+5:30, Ankit Mahato wrote:

On Tuesday, 2 July 2013 13:58:20 UTC+5:30, Robert Cimrman wrote:

Now it remains to implement a robust flow solver. Even this small example
shows, that the solution is not obtained easily - try decreasing the viscosity,
and/or increase the Dirichlet velocity - the solver would not converge.

Yes R,

The solution is not obtained easily.
I am looking into it.

PS: Here are blog posts for week 1 & 2
Kindly tell me if this will do before I send it to terri oda:

http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc.html
http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc_2.html

Hi R,

Just wanted your views.
Does the problem of Navier-Strokes solver lies with the implementation or the algorithm which is used.
 

[Robert Cimrman]

On 07/02/2013 03:36 PM, Ankit Mahato wrote:
>
>
> On Tuesday, 2 July 2013 13:58:20 UTC+5:30, Robert Cimrman wrote:
>>
>> Now it remains to implement a robust flow solver. Even this small example
>> shows, that the solution is not obtained easily - try decreasing the
>> viscosity,
>> and/or increase the Dirichlet velocity - the solver would not converge.
>>
>>
> Yes R,
>
> The solution is not obtained easily.
> I am looking into it.
>
> PS: Here are blog posts for week 1 & 2
> Kindly tell me if this will do before I send it to terri oda:
>
> http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc.html
> http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc_2.html

It seems ok, just correct the following typo: Navier-Strokes -> Navier-Stokes :)

It would be interesting to see the Peclet number graphs. Also, did you try some
other, more interesting, geometries?

r.

[Robert Cimrman]

On 07/02/2013 03:46 PM, Ankit Mahato wrote:
>
>
> On Tuesday, 2 July 2013 19:06:16 UTC+5:30, Ankit Mahato wrote:
>>
>>
>>
>> On Tuesday, 2 July 2013 13:58:20 UTC+5:30, Robert Cimrman wrote:
>>>
>>> Now it remains to implement a robust flow solver. Even this small example
>>> shows, that the solution is not obtained easily - try decreasing the
>>> viscosity,
>>> and/or increase the Dirichlet velocity - the solver would not converge.
>>>
>>>
>> Yes R,
>>
>> The solution is not obtained easily.
>> I am looking into it.
>>
>> PS: Here are blog posts for week 1 & 2
>> Kindly tell me if this will do before I send it to terri oda:
>>
>>
>> http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc.html
>>
>> http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc_2.html
>>
>>
> Hi R,
>
> Just wanted your views.
> Does the problem of Navier-Strokes solver lies with the implementation or
> the algorithm which is used.

Mostly the algorithm, but it might be also the formulation. I am far from CFD,
but people there seem to be preferring a dimensionless form of the
incompressible NS equations. It also depends on the discretization/FE spaces
used. It's really a broad subject, and there is still no a silver bullet
solver. Maybe ask your thesis advisor/colleagues doing CFD? Searching the net
is really of no help here, as it returns so many things... Expert advice is
needed :)

r.

[Ankit Mahato]

On Tuesday, 2 July 2013 19:16:37 UTC+5:30, Robert Cimrman wrote:

On 07/02/2013 03:36 PM, Ankit Mahato wrote:
>
>
> On Tuesday, 2 July 2013 13:58:20 UTC+5:30, Robert Cimrman wrote:
>>
>> Now it remains to implement a robust flow solver. Even this small example
>> shows, that the solution is not obtained easily - try decreasing the
>> viscosity,
>> and/or increase the Dirichlet velocity - the solver would not converge.
>>
>>
> Yes R,
>
> The solution is not obtained easily.
> I am looking into it.
>
> PS: Here are blog posts for week 1 & 2
> Kindly tell me if this will do before I send it to terri oda:
>
> http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc.html
> http://ankitmahato.blogspot.in/2013/07/python-software-foundation-sfepy-gsoc_2.html

It seems ok, just correct the following typo: Navier-Strokes -> Navier-Stokes :)

Done.
 

It would be interesting to see the Peclet number graphs. Also, did you try some
other, more interesting, geometries?

Actually I varied the convective velocity and c to observe the variation as I had the graph in my book alongside. It was in accordance but I did not plot it [ grave mistake :( ] and moved ahead at looking into the 3d navier stokes code.

[Robert Cimrman]

Maybe you could start using the ipython notebooks for that kind of
plots/exploration? It might be handy both for your thesis, and the blog.

r.

[Ankit Mahato]

Yes R dimensionless form of the equations are preferred. I have implemented Patankar's SIMPLE algorithm previously (http://en.wikipedia.org/wiki/SIMPLE_algorithm) [also SIMPLER and SIMPLEC] when I did CFD course but using Finite Difference Method. I will look into it if I find FEM approach.
Also I wanted to ask you if we need to stick to FEM for CFD because people use Finite Volume Method [FVM] for CFD.

 

[Ankit Mahato]

Okie R. Will do so form now onwards.
 

[Robert Cimrman]

Yes, we need it in a FEM context, sfepy cannot do FVM. But (big)IMHO those two
approaches have things in common, and once you have the matrices and
algorithm... It should even be possible to compute fluxes and similar
quantities, if needed, though I never tried that and think there is no time to
implement FVM in sfepy within your project.

r.

[Ankit Mahato]

Hi R,

For our Navier-Stokes currently we use the Newton method with backtracking line-search. 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.

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.wias-berlin.de%2Fpeople%2Fjohn%2FPP99_13.ps&ei=mW3VUZqzOMmzrgeKuYD4DA&usg=AFQjCNEp9_rShrLSjkYdax6bOimSrkD-KQ&sig2=8S654V-zz2vd4mFZOilZCw&bvm=bv.48705608,d.bmk
• http://numerik.iwr.uni-heidelberg.de/Oberwolfach-Seminar/CFD-Course.pdf
• http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
• http://www.reaction-eng.com/downloads/nksolver_pernice.pdf
• http://aero-comlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
• https://cs.uwaterloo.ca/research/tr/1993/02/CS-93-02.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/newton-handouts.pdf

[1]: http://www.cfd-online.com/Forums/openfoam-solving/60167-how-nonlinear-discretised-equations-linearised-openfoam.html
[2]: http://web.cecs.pdx.edu/~gerry/class/ME448/notes/pdf/SIMPLEslides.pdf

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?

[Robert Cimrman]

On 07/04/2013 03:02 PM, Ankit Mahato wrote:
> Hi R,
>
> For our Navier-Stokes currently we use the Newton method with backtracking
> line-search.

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 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.wias-berlin.de%2Fpeople%2Fjohn%2FPP99_13.ps&ei=mW3VUZqzOMmzrgeKuYD4DA&usg=AFQjCNEp9_rShrLSjkYdax6bOimSrkD-KQ&sig2=8S654V-zz2vd4mFZOilZCw&bvm=bv.48705608,d.bmk
> - http://numerik.iwr.uni-heidelberg.de/Oberwolfach-Seminar/CFD-Course.pdf
> -
> http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
> - http://www.reaction-eng.com/downloads/nksolver_pernice.pdf
> - http://aero-comlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
> - https://cs.uwaterloo.ca/research/tr/1993/02/CS-93-02.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/newton-handouts.pdf

>
>
> [1]:
> http://www.cfd-online.com/Forums/openfoam-solving/60167-how-nonlinear-discretised-equations-linearised-openfoam.html
> [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 multigrid-based
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.

[Ankit Mahato]

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 Navier-Stokes currently we use the Newton method with backtracking
> line-search.

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://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.wias-berlin.de%2Fpeople%2Fjohn%2FPP99_13.ps&ei=mW3VUZqzOMmzrgeKuYD4DA&usg=AFQjCNEp9_rShrLSjkYdax6bOimSrkD-KQ&sig2=8S654V-zz2vd4mFZOilZCw&bvm=bv.48705608,d.bmk
>     - http://numerik.iwr.uni-heidelberg.de/Oberwolfach-Seminar/CFD-Course.pdf
>     -
>     http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
>     - http://www.reaction-eng.com/downloads/nksolver_pernice.pdf
>     - http://aero-comlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
>     - https://cs.uwaterloo.ca/research/tr/1993/02/CS-93-02.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/newton-handouts.pdf
>
>
> [1]:
> http://www.cfd-online.com/Forums/openfoam-solving/60167-how-nonlinear-discretised-equations-linearised-openfoam.html
> [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 multigrid-based
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.

[Ankit Mahato]

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-stokes/python/documentation.html

Then a stackoverflow question where someone says that fenics wasn't fast.
http://stackoverflow.com/questions/4768045/fluid-flow-heat-transfer-and-python

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_Three-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/
• Finite Volume Based - http://www.ctcms.nist.gov/fipy/
  

Here is a list of Open Source CFD codes. Maybe we can fork a repo and use it or learn from it:
http://www.cfd-online.com/Wiki/Codes

According to people iNavier and dolphyn are promising:
http://www.cfd-online.com/Forums/main/13529-colver-code-c-c.html

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 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

[Robert Cimrman]

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.)

> Then a stackoverflow question where someone says that fenics wasn't fast.
> http://stackoverflow.com/questions/4768045/fluid-flow-heat-transfer-and-python

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:
> * Parallel Spectral Numerical Methods/The Two- and Three-Dimensional

> Navier-Stokes Equations -http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two-_and_Th
> 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.

> * Finite Volume Based - http://www.ctcms.nist.gov/fipy/

> Here is a list of Open Source CFD codes. Maybe we can fork a repo and use
> it or learn from it:
> http://www.cfd-online.com/Wiki/Codes

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.

> According to people iNavier and dolphyn are promising:
> http://www.cfd-online.com/Forums/main/13529-colver-code-c-c.html
>
> 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?

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

[Ankit Mahato]

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? 
 

> Then a stackoverflow question where someone says that fenics wasn't fast.
> http://stackoverflow.com/questions/4768045/fluid-flow-heat-transfer-and-python

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:
>  *  Parallel Spectral Numerical Methods/The Two- and Three-Dimensional
>     Navier-Stokes Equations -http://en.wikibooks.org/wiki/Parallel_Spectral_Numerical_Methods/The_Two-_and_Th
>     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.
 

>  *  Finite Volume Based - http://www.ctcms.nist.gov/fipy/
> Here is a list of Open Source CFD codes. Maybe we can fork a repo and use
> it or learn from it:
> http://www.cfd-online.com/Wiki/Codes

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?
 

> According to people iNavier and dolphyn are promising:
> http://www.cfd-online.com/Forums/main/13529-colver-code-c-c.html
>
> 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.
 

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

[Robert Cimrman]

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.

[Ankit Mahato]

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!

  �

[Ankit Mahato]

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.

News pertaining to algorithms:
- SIMPLE cannot be used under FE context.
- 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.
- 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.
 
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.?

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.

[Robert Cimrman]

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.

> 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?

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

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

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

[Ankit Mahato]

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.
 

[osman buyukisik]

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
> PETSc-FEM - 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

[Robert Cimrman]

Yes, I was too quick in the reply. Actually, there is no problem in using
GPL-ed solvers (for example umfpack is GPL-ed) 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.

So the staggered grid seems to be the main problem. Ok.

r.

[Robert Cimrman]

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.

[Robert Cimrman]

On 07/04/2013 03:02 PM, Ankit Mahato wrote:

> 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.wias-berlin.de%2Fpeople%2Fjohn%2FPP99_13.ps&ei=mW3VUZqzOMmzrgeKuYD4DA&usg=AFQjCNEp9_rShrLSjkYdax6bOimSrkD-KQ&sig2=8S654V-zz2vd4mFZOilZCw&bvm=bv.48705608,d.bmk
> - http://numerik.iwr.uni-heidelberg.de/Oberwolfach-Seminar/CFD-Course.pdf
> -
> http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
> - http://www.reaction-eng.com/downloads/nksolver_pernice.pdf
> - http://aero-comlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
> - https://cs.uwaterloo.ca/research/tr/1993/02/CS-93-02.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/newton-handouts.pdf

From those links, I think only the first two links are interesting for us
(other texts describe FV, or are 2D only etc.). In CFD-Course.pdf, check
especially section 5, where some approaches to solving the (non)linear system
are given (e.g. a Schur complement approach). Unfortunately (from the
complexity/time constraint point of view), most people seem to agree that
multigrid is the way to go.

To proceed with the gsoc, maybe it would be good if you, in parallel to this,
tried to create an example with all the equations coupled, to have something to
play with. It could be small and use non-realistic viscosity to make the
solution easier. Use a 2D mesh, as that could be made reasonably fine.

Then you could develop/try some iterative schemes to solve the system. (e.g.
solve flow i -> solve energy i -> solve flow i+1 ...).

What do you think?
r.

[Ankit Mahato]

cool :) okie.
 

[Ankit Mahato]

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.

[Ankit Mahato]

On Wednesday, 10 July 2013 22:19:47 UTC+5:30, Robert Cimrman wrote:

On 07/04/2013 03:02 PM, Ankit Mahato wrote:
> 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.wias-berlin.de%2Fpeople%2Fjohn%2FPP99_13.ps&ei=mW3VUZqzOMmzrgeKuYD4DA&usg=AFQjCNEp9_rShrLSjkYdax6bOimSrkD-KQ&sig2=8S654V-zz2vd4mFZOilZCw&bvm=bv.48705608,d.bmk
>     - http://numerik.iwr.uni-heidelberg.de/Oberwolfach-Seminar/CFD-Course.pdf
>     -
>     http://dspace.uta.edu/bitstream/handle/10106/5144/JIAJAN_uta_2502M_10764.pdf
>     - http://www.reaction-eng.com/downloads/nksolver_pernice.pdf
>     - http://aero-comlab.stanford.edu/Papers/birkenjamesonproceedings09.pdf
>     - https://cs.uwaterloo.ca/research/tr/1993/02/CS-93-02.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/newton-handouts.pdf


 From those links, I think only the first two links are interesting for us
(other texts describe FV, or are 2D only etc.). In CFD-Course.pdf, check
especially section 5, where some approaches to solving the (non)linear system
are given (e.g. a Schur complement approach). Unfortunately (from the
complexity/time constraint point of view), most people seem to agree that
multigrid is the way to go.

okey
 

To proceed with the gsoc, maybe it would be good if you, in parallel to this,
tried to create an example with all the equations coupled, to have something to
play with. It could be small and use non-realistic viscosity to make the
solution easier. Use a 2D mesh, as that could be made reasonably fine.

okey
 

Then you could develop/try some iterative schemes to solve the system. (e.g.
solve flow i -> solve energy i -> solve flow i+1 ...).
 

What do you think?

Yes this is the iterative scheme i have to apply. But currently everything is steady state. The final problem has to be unsteady as then phase change effect will be seen evolving with time.
 

r.

PS: By the way I recieved a mail from the professor that he has caught viral fever due to changing weather so he would not be able to meet me this week. I also caught fever yesterday and i just got out of bed a few minutes back so couldn't reply to the thread earlier.

[Robert Cimrman]

Good. That means less worries about the convective stabilisation.

r.

[Ankit Mahato]

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.

[Robert Cimrman]

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 over-stabilize. 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/doc-devel/examples/navier_stokes/stabilized_navier_stokes.html

[Ankit Mahato]

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 over-stabilize. 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.