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

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.

cool :) okie.
 

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

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

r.