Hi Jelle, thanks for your quick reply. At our institute (Zuse Institute Berlin, www.zib.de) we have developed a FEM solver specialized for nano-optics, which is being commercialized by the startup-company JCMWave (www.jcmwave.com). In my research I am simulating functional nano-structures (e.g. solar cells) with complicated geometries - therefore I need a CAD application that can generate high quality volume grids, which I develop using PythonOCC with GEOM and SMESH.
For creating stand-alone versions of SMESH 6.5.0 and GEOM 6.5.0 I take the SMESH and GEOM Salome sources, the netgen sources from the Salome Install Wizard (apparently this is the only netgen source tree version that is compatible with the Salome patch file required for the smesh netgen plugin) and some of Salomes Kernel source files. For all the modifications I had to apply I tried to follow as closely as possible the modifications done for the SMESH and GEOM modules on sourceforge (http://sourceforge.net/projects/salomesmesh/, http://sourceforge.net/projects/salomegeometry/). Well, at least I tried ;-). I can re-run my application, which uses SMESH (and GEOM) through PythonOCC extensively after applying my modifications, so I think these versions are more or less compatible. You're right, of course the new VTK and boost thread dependencies are in SMESH, not in PythonOCC itself. Maybe it would be better to remove the SMESH VTK dependency ? And the boost thread dependency ? On the other hand, running mesh generations in a thread within SMESH is on my personal wish-list (like they do in the latest Salome version to provide a GUI "cancel" button ) and VTK export / import would also be kind of nice. I used the SWIG_generator.py with gccxml to regenerate SWIG interface files (with hand-modifications afterwards). While doing that I noticed that all OCC classes derived from Standard_Transient and Standard_Persistent no longer provide the HashCode functions and therefore I had to remove all %extend <some_class> { Standard_Integer __hash__() { return $self->HashCode(__PYTHONOCC_MAXINT__); } }; statements in the SWIG files. Initially I re-introduced the HashCode functions in oce, which was really a bad idea: I experienced lots of random crashes. Are those Hashcode functions required on the python side or is python happy on those classes with the default __hash__() function ? Also I had to modify SWIG_generator.py to avoid the generation of artificial copy constructors by adding if ("%s("%class_parent_name in to_write) and (mem_fun.is_artificial): return False in write_functions(). Not sure if that is correct. Maybe that is due to an issue with the specific gccxml version I use ? If you like you can also directly contact me on my email address. Thanks, Mark Am 15.08.2012 um 10:54 schrieb jelle feringa: > Dear Mark, > > I am developing a CAD & Meshing application for finite element simulations > (computational nano-optics) using PythonOCC. > > Interesting! > I take it that your developing a custom solver? > Cool to see PythonOCC in such a sophisticated project, exciting. > > I very much enjoy the rapid software development PythonOCC offers - it's fun > and robust at the same time. > > Good to hear so. > > For the software I develop I decided to update my local PythonOCC > installation to the latest version of the underlying libraries > using the sources from Salome version 6.5.0: > - OCCT 6.5.3 (I use oce version 0.10) > - SMESH version 6.5.0 > - GEOM version 6.5.0 > - Netgen version 4.9.13 (fully functional netgen plugin with python > wrapper) > - Tetgen version 1.4.3 (homebrewn tetgen plugin with python wrappers) > > For this purpose I wrote python scripts that basically take the Salome > sources found in the install wizard and the PythonOCC V0.5 sources > and convert them to an updated PythonOCC Version applying necessary patches > (e.g. for netgen). Subsequently I hand-modified SMESH, > GEOM sources (to create stand-alone versions of them) and SWIG interface > files (where necessary, well, most of them, actually). > > This is _very_ cool news. > Just to see if I follow you correctly: there has been an effort to integrate > GEOM and SMESH in PythonOCC, where we've been adapting an effort by Fotios. > So, I'm curious to know whether by GEOM / SMESH you refer to the Salome > version or what has been integrated in PythonOCC yet. > If I follow along, you've been working on adapting code from Salome? > I'm curious if you've seen this example, coupling Code-Aster [1]? > > [1] https://github.com/tpaviot/pythonocc/tree/master/src/examples/Level2/FEM > > I would like to contribute my modifications to give something back to this > great open-source library, but I am unsure as to how this could be done. > > Ideally, by creating a new branch from github [2] > > [2] https://github.com/tpaviot/pythonocc > > To this end the updated PythonOCC is running fine on my computer, I can run > almost all of my test-cases and use netgen and tetgen through PythonOCC. > I am still having some small issues with SMESH though (should be resolved > within the next days). > > Wonderful. Do I understand that your SMESH version follows the Salome API? > > There are some things I would like to discuss (e.g. HashCode functions being > absent in OCCT Standard_Transient and Standard_Persistent classes, > new dependencies of SMESH to boost threads and VTK). > > That's what this list is here for. > > 1) HashCode functions being absent in OCCT Standard_Transient and > Standard_Persistent classes > I'm on the latest version of PythonOCC: > > In [1]: from OCC.Standard import * > In [2]: print Standard_Transient.HashCode > <unbound method Standard_Transient.Standard_Transient_HashCode> > > 2) there's a boost version in our tree: > https://github.com/tpaviot/pythonocc/tree/master/src/contrib > > 3) VTK is a powerful module. The current SMESH / GEOM module are built > optionally, where SMESH is creating more of an issue compiling / linking but > does not introduce new dependencies, other than boost. > Since we consider SMESH an add-on, we can be a little more relaxed about > this, than when it comes to "core" PythonOCC. > ( Boost is not a PythonOCC dependency ) > > Also as I am developing on Mac OS X I did not update the SWIG interface files > for win32, so I > would need some help for this from people developing on Windows. > > I hope Thomas Paviot can steer you in the right direction here. > > Thanks Mark, looking fwd looking into your contributions! > > Best, > > -jelle > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
