2012/8/15 Mark Blome <bl...@zib.de> > > Hi Jelle, >
Hi Mark, Thank you for your post. It's not that usual that people here contribute to the low level SWIG layer. > 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. > Fotis' salomesmesh and salomegeometry projects are existing attempts to create standalone versions of SMESH and GEOM. > > 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 > ;-). > Why didn't you try to work from the svn trunks of these projects? > > 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. > > Dependencies can easily be managed from the cmake pythonocc builder system. The idea is to create optional features, for instance "if lib is installed" then "enable feature". But additional dependencies should not be included to the current source code, the objectif being, on the opposite, to reduce the number of required demendencies of Salome modules. > I used the SWIG_generator.py with gccxml to regenerate SWIG interface > files (with hand-modifications afterwards). > Waow, well done ;-) 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 ? > HashCode was a member function for all classes that inherit from Standard_Transient. However, since OCCT6.5.0 (or 6.5.1, I don't remember exactly), this was changes by the OCC team. I already fixed this issue, a month ago, in the tp/oce-0.10-support branch on github (see https://github.com/tpaviot/pythonocc/branches). The related commit is https://github.com/tpaviot/pythonocc/commit/00141683e58a641ac1103e3d8df706b75a712332to make use of the new HashCode function. Having a __hash__ method is a requirement, since it is used by python lists/dicts (for instance when looking for 'a_shape *in* a_list'). When modifying the SWIG files, you should each time restart the unittest suite to check that you did not introduce any regression. I think (but I'm not sure), that removing the __hash__ method introduces some regression. > 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 ? > I can't understand this part of your code. What problem do you try to solve? > > If you like you can also directly contact me on my email address. > Of course not. This interesting contribution (and the related discussion) has to remain public. I'm impressed by your deep understanding of the SWIG OCCT wrapper, and your work/skill can help improving pythonocc while I'm not having as much free time as I used to have in a recent past. Here is what I suggest in order to get efficient : * use OCE instead of the officiel OCCT. OCE is very easy to compile/install compared to OCCT. You can work with the OCE 0.10 release ; * I pushed a branch to the github repos that is sync with the oce master branch (see my comment above). Please push code/comments/issue to https://github.com/tpaviot/pythonocc. If you don't feel comfortable with git, post code to this ml in the meantime ; * you can send your improvements over salomesmesh/salomegeometry to Fotis Soutis (sfo...@gmail.com). It's the best way to have these projects include your changes. > > Thanks, > Mark > Much looking forward to discussing these issues with you, Best Regards, Thomas > > 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 > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
