[elvis]

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]

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]

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]

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]

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]

Some fresh news on this project ?

[alexey2petrov]

Originally Posted by elvis

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]

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]

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

[alexey2petrov]

Originally Posted by elvis

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]

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]

Originally Posted by cliffoi

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]

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

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]

Originally Posted by francois

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.

Originally Posted by francois

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]

Originally Posted by francois

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

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]

Originally Posted by alexey2petrov

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]

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

Cheers
Francois

[skyopener]

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

[santiagomarquezd]

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]

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