CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)
-   -   [pythonFlu] Can someone tell me more about vulashaka (https://www.cfd-online.com/Forums/openfoam-community-contributions/74841-can-someone-tell-me-more-about-vulashaka.html)

elvis April 9, 2010 16:25

Can someone tell me more about vulashaka
 
Hi all,

Has someone more Information about vulashaka?

All I know so far is that
* it is hosted on SF http://sourceforge.net/projects/vulashaka/
* the "Pebble Bed Modular Reactor" people are behind it, namely in person of Alexey PETROV
Hrv mentioned that he did some stuff for the South African Reactor guys,

so vulashaka seems to be a working enviroment for them.

* it deals with Salome http://www.salome-platform.org as well

* it makes use of pyfoam and extents pyfoam with IFoam

well i do not have very much information so far.

thx for more insight

elvis

cliffoi April 12, 2010 13:45

Vulashaka
 
Hi Elvis,
I was one of the original developers on the swig wrapping portion of this project at PBMR. In a nutshell the basic concept is to work towards a full CAE framework for the reactor analysis work done at PBMR. As part of this the team are working towards fully integrating OpenFOAM within the salome platform, so that multi-physics models can be developed, meshed, initialized, solved in a coupled fashion and post-processed seamlessly from within the same environment.
One of the most enticing features will be the ability to control OpenFOAM and other simulations on-the-fly, i.e. calculation schemes can be set up to run different solvers, exchange data and monitor results. This is provided mostly through the OpenFOAM python wrappings which have been developed. These wrappings can run independently of Salome so will be of interest to anyone looking to interact with OpenFOAM in a completely new way. At this point entire solvers can be developed and run in python. Most of the OpenFOAM objects can be created from memory and accessed so this is also good for embedding OpenFOAM in any pre- or post-processing package that supports python.
The documentation is still a little scarce but if you are familiar with python and OpenFOAM then you should be fine. The wrappings replicate the existing OpenFOAM object hierarchy so the OpenFOAM doxygen documentation can be your guide. The remainder of the project's various downloads have readme files included which will hopefully sort out many of the issues.
I am no longer actively developing for this project so if you have any specific questions or bug reports I'd suggest you contact Alexey Petrov from PBMR through the project's support link.

cliffoi April 12, 2010 13:52

An extra comment
 
I forgot to mention, the pyFoam download in the context of vulashaka does not refer to Bernhard Gschaider's pyFoam contribution which you'll find on the wiki (http://openfoamwiki.net/index.php/Contrib_PyFoam). This development work is independent from Bernhard's. I have suggested to the developers that this portion be renamed so hopefully this confusion will be sorted out for future releases.

elvis April 14, 2010 05:22

Thank you Ivor,

your answer was very exciting.
I have not done much with all the tools you use in vulashaka, a little bit with salome
a little bit python to work with VTK.

seems one has to digg deeper into this interesting stuff.

thx

elvis

phsieh2005 July 7, 2010 14:23

Hi, Ivor,

I am wondering if you know of any forum or sites that provide more details about the project. I did not find any user forum on the sourceforge.net. Is there any tutorials/documents that showed how to install it, how to use it?

Thanks!

Pei-Ying

francois September 24, 2010 07:29

Some fresh news on this project ? :D

alexey2petrov January 17, 2011 09:24

Quote:

Originally Posted by elvis (Post 253994)
Has someone more Information about vulashaka?

Hi Elvis,

I am one of the principal VulaSHAKA developers.
VulaSHAKA, for now, is not under active development (there is even possibility that it would be ceased).
Some of its sub-projects, like pyFoam, have better chance to survive, but, once again, all depends on the community - whether it will be required and founded accordingly or die.

Some details about pyFoam:
  • Can be treated as a full-featured alternative to the C++ OpenFOAM interface (way of development). For example, supports the following features :
    • inheritance from base C++ classes,
    • the same math like notation,
    • templates
  • Actually, needs only core OpenFOAM libraries (libOpenFOAM.so & finiteVolume.so), all other staff could be defined purely in Python
  • The same pyFoam definition could wrap different versions of OpenFOAM (as Extended as OpenCFD once)
  • No loss of performance

Note : Currently wraps only 40% of OpenFOAM C++ API

Of course, the main benefits not in the point that pyFoam can do what other do, but in the things that nobody could achieve, for example :
  • Using OpenFOAM functionality in interactive way (like MatLab, for example)
  • Integrating / embedding OpenFOAM functionality within other frameworks (like SALOME, SciPy e.t.c)
  • Improving the way of distribution of OpenFOAM functionality (Python defined solvers are much easier to install and deal with)
  • Simplification of the OpenFOAM solvers development, debugging and usage

Best regards,
Alexey

elvis January 17, 2011 15:24

Hi Alexey,

thank you for your answer. Your outlook about "pyFoam" is very exciting.
What amount of money do you think is nescessary as founding?
Unfortunatly my Department does not make use of OpenFoam, but I am willing to take some of my own money.

greets

elvis

francois April 2, 2011 12:12

I saw some new activities on the sourceforge repository
Any new development ?

alexey2petrov April 4, 2011 08:51

Python OpenFOAM binding development continuation
 
Quote:

Originally Posted by elvis (Post 290830)
Hi Alexey,

thank you for your answer. Your outlook about "pyFoam" is very exciting.
What amount of money do you think is nescessary as founding?

Hi Elvis,

Sorry for the long silence. I spent some time on considering pros and cons on the possible future of Python OpenFOAM binding development. In the hope that community will support this development, we (I and Andrey Simurzin) come up with a new project - pythonFlu (the original pyFoam name was changed to follow OpenFOAM trademark guidelines). This new release of Python OpenFOAM binding contains following major improvements :
  • Porting on the latest 1.7.1 and 1.6-ext OpenFOAM versions;
  • Preparation of native Linux binary packages (available for Ubuntu and OpneSUSE, i386 and amd64 architectures);
  • A project documentation site was started.

To finalize this development the following tasks need to be done :
compressible
  • rhoPorousMRFPimpleFoam - 1.25 man*days
  • sonicDyMFoam - 1.25 man*days
incompressible
  • porousSimpleFoam - 1.25 man*days
heatTransfer
  • chtMultiRegionSimpleFoam - 4.5 man*days
  • buoyantBoussinesqPimpleFoam - 0.75 man*days
  • buoyantPimpleFoam - 0.75 man*days
multiPhase
  • bubbleFoam - 1.5 man*days
  • interMixingFoam - 3.0 man*days
  • cavitatingFoam - 1.5 man*days
  • interPhaseChangeFoam - 4.5 man*days
  • twoPhaseEulerFoam - 6.0 man*days
  • compressibleInterFoam - 1.5 man*days
  • multiphaseInterFoam - 4.5 man*days
  • settlingFoam - 1.5 man*days
stressAnalysis
  • solidDisplacementFoam - 3.0 man*days
  • solidEquilibriumDisplacementFoam - 3.0 man*days
lagrangian
  • coalChemistryFoam - 3.0 man*days
  • porousExplicitSourceReactingParcelFoam - 3.0 man*days
  • reactingParcelFoam - 1.5 man*days
financial
  • financialFoam - 0.75 man*days
electromagnetics
  • electrostaticFoam - 0.75 man*days
  • mhdFoam - 0.75 man*days
dns
  • dnsFoam - 1.5 man*days
discreteMethods
  • dsmcFoam - 3.0 man*days
  • mdEquilibrationFoam - 3.0 man*days
  • mdFoam - 3.0 man*days
combustion
  • dieselFoam - 3.0 man*days
  • engineFoam - 3.0 man*days
  • fireFoam - 6.0 man*days
  • reactingFoam - 3.0 man*days
  • XiFoam - 3.0 man*days
Summary : number of solvers to be wrapped - 30, corresponding working time to be spent ~ 77 days.

Note : we do wrapping not just "in general" (function by function, class by class), but in terms of "existing solvers" (if solver uses some functionality it should be wrapped to be able to reproduce the same solver definition in Python as in C++). This tactics allows us to assure that every function we has wrapped were wrapped correctly and gives the same results as corresponding C++ functionality.

The latest advancement was done at our good will and free time.
If OpenFOAM community is still interested in this development you could support it by donations.

Best regards,
Alexey

cliffoi April 4, 2011 10:19

Hi Alexey,
I hope you are well and I'm glad you've decided to keep up the development. I was just wondering, can we submit bugs reports, feature requests, etc. on the pythonFlu project page?

Thanks in advance
Ivor

alexey2petrov April 4, 2011 12:59

Python OpenFOAM binding development continuation
 
Quote:

Originally Posted by cliffoi (Post 302142)
Hi Alexey,
I hope you are well and I'm glad you've decided to keep up the development. I was just wondering, can we submit bugs reports, feature requests, etc. on the pythonFlu project page?

Hi Ivor,

Yes you are completely right - bugs and feature requests are the things that indicate that the project is alive.
So, I will definitely do all my best to track and implement all reported issues.
Therefore you are more than welcome!

Best regards,
Alexey

francois April 5, 2011 03:58

That's an awesome news ! Congratulations ...

It's a BIG BIG step for OpenFOAM code development and deployment : one of the missing feature of all other CFD codes :D

I'm sure the OpenFOAM community will make it's best to support your project either by donations or by contributions ;)

Did you spread the excellent news to Salome's community ?
Perhaps a merge between Bernhard's pyFoam and pythonFlu could be possible
and be beneficial for both projects.

What a great news ...
Wish you the best.
Thank you !!!

Francois

alexey2petrov April 5, 2011 11:48

Quote:

Originally Posted by francois (Post 302240)
Did you spread the excellent news to Salome's community?

Unfortunately no. The SALOME OpenFOAM coupling that became possible thanks to pythonFlu technology is on the early stage. It is an example of "what we can do for now", not the precise description on "how it should be done". So, I hesitate to make a big noise about such case.

Also, I think SALOME OpenFOAM coupling really matters for OpenFOAM users, not SALOME ones. At the same time, if you have some ideas on how to interest SALOME guys in pythonFlu technology I would be glad to learn.

Quote:

Originally Posted by francois (Post 302240)
Perhaps a merge between Bernhard's pyFoam and pythonFlu could be possible and be beneficial for both projects.

Yes and this topic was already discussed with Bernhard. And we come to a conclusion that since pyFoam and pythonFlu suggest completely different approaches (one controls OpenFOAM solver execution from outside, another aims to define OpenFOAM solver from inside) and do not overlap their goals with each other, it will have a little meaning to combine these two developments.

Best regards,
Alexey

gschaider April 5, 2011 13:27

Quote:

Originally Posted by francois (Post 302240)
That's an awesome news ! Congratulations ...

It's a BIG BIG step for OpenFOAM code development and deployment : one of the missing feature of all other CFD codes :D

I'm sure the OpenFOAM community will make it's best to support your project either by donations or by contributions ;)

Did you spread the excellent news to Salome's community ?
Perhaps a merge between Bernhard's pyFoam and pythonFlu could be possible
and be beneficial for both projects.

It has been discussed. Main reason why nothing concrete has happened is that I didn't find time to seriously look into it (the other interpretation is that I'm just plain lazy). The reason why I'm not completely in favour of a merg is that one goal with PyFoam is to minimizhe the requirement for a compilation (to put it another way: no compilation should be required) to ease deployment.

But once I've got the new release of PyFoam out of the door I'll seriously look into it (one way that PyFoam could benefit from pythonFlu is to hand to it the parsing of large field-fields (currently something that PyFoam is not very quick with). Nice thing about Python is that this can be made optional "If pythonFlu is there we'll use it, otherwise we'll take the slow route")

Bernhard

gschaider April 5, 2011 13:36

Quote:

Originally Posted by alexey2petrov (Post 302327)
Yes and this topic was already discussed with Bernhard. And we come to a conclusion that since pyFoam and pythonFlu suggest completely different approaches (one controls OpenFOAM solver execution from outside, another aims to define OpenFOAM solver from inside) and do not overlap their goals with each other, it will have a little meaning to combine these two developments.

I didn't read Alexey's response when I started writing mine. He said it more to the point and I fully agree

Bernhard

francois April 5, 2011 17:22

Thanks Alexey and Bernhard for your kind answers and for providing us those excellent pieces of codes

Cheers
Francois

skyopener April 6, 2011 06:13

What a great work!:cool:
Hope everything goes well.....
S.L Yang

santiagomarquezd April 9, 2011 22:31

pythonFlu really rulez. I was using it yesterday with my advisor and extracting data from fields and operate with them via numPy was completely transparent. Here nisi prepared a series of gdb macros in order to debug FOAM easely, now much of this work can be done with pythoFlu, plus the potential of data manipulation inside of the running. I think I'll code some lines in order to export fvMatrix to numPy arrays and things like this.

Keep this party going.

alexey2petrov June 1, 2011 09:29

New Release
 
pythonFlu have grown a little bit. A new version is available for downloading.

We name this release - "Elvis", after the person who believed in this project and inspired us continue its development.

To make it clear that corresponding Python solvers are not part of the swigging definition, we separated them from pythonFlu kernel.
Hope, this will also simplify distribution of the solvers, since they can be designed and advanced independently as from each other, as from the kernel.

Other important details could be found here.

Cheers,
Alexey


All times are GMT -4. The time now is 04:14.