pythonFlu - Python wrapping for OpenFOAM C++ API
 

The next stable release - 8.1-Elvis - is available for downloading.

pythonFlu, briefly, could be described through the following features.

• Can be treated as a full-featured alternative to the C++ OpenFOAM way of development. Supports:
  • 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 pythonFlu definition could wrap different versions of OpenFOAM (as Extended ,as OpenCFD one)
• No performance loss

Actually, the most greatest power of pythonFlu lays not in the things that it can substitute usual OpenFOAM C++ API.
pythonFlu enables completely new prospectives in the way CFD calculations could be interacted with.

To read more follow the link

Alexey,

What about the other projects directly related to pythonFlu ?
Is IFoam (now hypridFlu) always is development ?

Cheers
François

hybridFlu in pythonFlu
 

Hi François,
Yes, we are going to recover the most attractive part of VulaSHAKA project in frame of pythonFlu. Next pythonFlu release will be especially dedicated to this point.
hybridFlu (SALOME to OpenFOAM binding) will be included into pythonFlu distribution and users will be able to lay their hands on this staff.
Nothing new will be actually added to already known functionality, except one important point -

on hybridFlu example the ability to wrap whatever third party functionality will be demonstrated
(in contents of hybridFlu it will be foam2vtk and unv2foam libraries)

What is going to happen next with hybridFlu? Depends on users interest to this functionality; whether they will work with it, trying to adjust to some real-world case, letting us to know in what direction it need to be advanced. Might be someone have some particular ideas on this point (except building another StarCD clone)?

You see, we are not allowed to spend our time on developing the stuff that will do the same as existing grown-up and polished software. You will be first disappointed by its quality and the number of features available.

By the way, I have in mind to start a new project which will allow automatically generate GUI by corresponding solver description. So, once a solver will describe its features in some special Python terms (the core idea for this project) it could provide a generic GUI definition to interact with its users. Just imagine, OpenFOAM solvers, each of them, running under their own specific GUI, where input values would be checked according to predefined range, user could choose only from compatible physical models and integration schemes e.t.c. By defining corresponding solver description - solver developer will help its users to figure out on how it works, how it should be properly initialized, guide them to the better practice and so on. What is your opinion?

This could be integrated further in hybridFlu, where corresponding generic GUI could be embedded into SALOME desktop.

Have I answered on your question?

Best regards,
Alexey

Greetings Alexey,

:eek: I'm almost speechless... but one word does come out: Awesome! Simply Awesome!

By the way, in case you're not familiar yet with pythonOCC:

• The site: http://www.pythonocc.org/
• An example (in Japanese): http://www.geocities.co.jp/SiliconVa...pythonOCC.html

pythonOCC could afterwords help complement the generic GUI system into creating something more independent from SALOME; it could mainly become one of the best ways for using optimization tools along these existing tools and OpenFOAM!

Keep up the very good work!!!

With my best regards,
Bruno

Alexey more than you can ever imagine ! :)
As wyldckat I'm almost speechless ...

You are building an awesome bridge between end-users and developers with those excellent ideas !

How the community can help you at present time ?
Best regards and congrats for this amazing work (lucky us :D) !

Dear Bruno and Francois,

Thank you for your interest in the work we are planning to do.
Ye, Bruno, I got your idea about coupling with pythonOCC, will consider in our design.
The idea about generic GUI is a tricky one. And one could say, that everything that is generic is useless by definition (and will be right from many points). So, the proper way for development of a generic is to discover rules that are common, not define them to make life simpler. Therefore, this project will require a lot of comments and insights from OpenFOAM experienced users, to realize what can be generalized, what will be the right way to do it and what had better left up to solver developers.

It would be wonderful if more people will be involved in preliminary discussion of the generic GUI project specification. I am planning to publish this document in one month on this forum. Any remarks and suggestions will be appreciated. The more real-world cases will be discussed and shadow-points discovered the brighter will be the future of this idea.

Cheers,
Alexey

Dear Foamers,

The next stable release - 8.2-hybrid - is available for downloading. It represents the following achievements:

• Name this release after the reinvoked SALOME to OpenFOAM binding - hybridFlu
• Specific hybridFlu related functionality comes in sources only and was tested with SALOME r5.1.3 and OpenFOAM r1.7.1
• Advancing pythonFlu make system in the way that any other third-party functionality can use and extend the referenced pythonFlu wrapping definition
• As an example how to achive this look in the implementation of hybridFlu related packages (foam2vtk and unv2foam)

We are planning to dedicate the next release to the porting on the latest OpenFOAM 2.0.0 version.
Everybody is welcome to share his thoughts on the contest and planning of pythonFlu development in the future.

Best regards,
Alexey & Andrey

Hi Alexey & Andrey,
I would like to try to use your tools, but I have an issue during the installation:

~$ sudo dpkg --force-depends --install /home/pierre/Téléchargements/pythonflu171_8.2-hybrid-1_maverick_amd64.deb
Sélection du paquet pythonflu171 précédemment désélectionné.
(Lecture de la base de données... 314892 fichiers et répertoires déjà installés.)
Préparation du remplacement de pythonflu171 8.2-hybrid-1 (en utilisant .../pythonflu171_8.2-hybrid-1_maverick_amd64.deb) ...
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named Foam
dpkg : avertissement : le sous-processus ancien script pre-removal a retourné une erreur de sortie d'état 1
dpkg - tentative d'exécution du script du nouveau paquet à la place ...
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named Foam
dpkg : erreur de traitement de /home/pierre/Téléchargements/pythonflu171_8.2-hybrid-1_maverick_amd64.deb (--install) :
le sous-processus nouveau script pre-removal a retourné une erreur de sortie d'état 1
running install
install_dir /usr/local/lib/python2.6/dist-packages/
Checking .pth file support in /usr/local/lib/python2.6/dist-packages/
/usr/bin/python -E -c pass
TEST PASSED: /usr/local/lib/python2.6/dist-packages/ appears to support .pth files
running bdist_egg
running egg_info
creating Foam.egg-info
writing Foam.egg-info/PKG-INFO
writing top-level names to Foam.egg-info/top_level.txt
writing dependency_links to Foam.egg-info/dependency_links.txt
writing manifest file 'Foam.egg-info/SOURCES.txt'
warning: manifest_maker: standard file '-c' not found
reading manifest file 'Foam.egg-info/SOURCES.txt'
writing manifest file 'Foam.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
.....

Unfortunately I have done a mistake before, trying to install the Natty version on my Maverick then try to uninstall ==> create an error (the same for instance). So I decide to try to reinstall the new one and get, again, the same error.
Do you have any ideas?

Thanks for advance,
Pierre.

Hi Pierre,
We am awfully sorry for the inconvenience. We have overseen this same problem twice -
Hope this will help,
Alexey

Hi Alexey,

Many thanks for your very quick answer, I have done it and it works well.

Pierre.

New release of pythonFlu r9.1-SWIG is available
 

Christmas is getting closer, and we are happy to put "one more thing" on our OpenFOAM table.

In compare with the latest official release (r8.2-hybrid) it brings the following new features and improvements:

pythonFlu r9.1-SWIG

• Name this release after porting on the new generation of SWIG wrapper - 2.X (tested with 2.0.3 - 2.0.6)

• Porting on the latest OpenCFD version of OpenFoam - 2.1.1
• The following new solvers were implemented in Python :
  • compressible
    • rhoPorousMRFLTSPimpleFlux
    • rhoPorousMRFSimpleFlux
    • rhoSimplecFlux
  • heatTransfer
    • buoyantBoussinesqPimpleFlux
    • chtMultiRegionSimpleFlux
  • incompressible
    • adjointShapeOptimizationFlux
    • SRFPimpleFlux
    • SRFSimpleFlux

pythonFlu r9.0-porting

• Name of the release after porting on the latest version of OpenFOAM
• Porting on the latest version of OpenFoam - 2.1.0, 2.0.1,2.0.0
• Porting on FreeFoam up to the 0.1.0rc5
• Porting on MacOS X (thanks to Bernhard Gschaider)
• Support for multi-fork and multi-version OpenFoam installations
• Moving installation procedure to launchpad.net (due to increased number of dependencies)
• Full grown support for writing interactive applications
  • A special managedFlu intermediate C++ layer was designed to provide precise memory management over OpenFoam objects)
• Advancement of the internal Python related module packaging
• Support writing pure Python custom functionObjects

For more details look at

• http://pythonflu.wikidot.com
• http://sourceforge.net/projects/pyth...files/9.1-SWIG

Have a marry Christmass!

Hello Alexey!

I guess christmas came early this year.

Just two questions:
- does this correspond to the latest commits on github (just asking as the last commits I see there are from the 20th of october)
- Nice way to get all the solvers in one go would be if there was a repository that incorporates all the available solvers in submodules (http://git-scm.com/book/en/Git-Tools-Submodules). That would allow people to get them all in one go and you can still have separate repos for all of them

Anyway: Merry Christmas

Hello Bernhard,
Yes, you are right. The basic stuff for the version was ready since 20th of october 2012.

Thanks for your idea. We will investigate this option.

Best regards,
Alexey

Hi Alexey,

thank you that you continue to work on pythonflu.
great job you did.

merry x-mas and a happy new year to all of you.

greets

elvis