Hi Thomas, hi Jelle, thanks for your comments and hints.
About the GEOM and SMESH modules: I started all over again creating stand-alone versions of SMESH and GEOM from the Salome V6.5.0 sources cause I judged that updating these projects file by file would have been too cumbersome. Well, probably that's not true for GEOM, but at least in SMESH a lot of the code base has changed between 5.1.x and 6.5.0. IMHO GEOM and SMESH are a huge plus for PythonOCC. In my Project I use non-manifold topology a lot using GEOMs most valuable GEOMAlgo_Splitter (for creating multi-material domains ) and use SMESH for advanced meshing techniques like creating periodic 3d volume grids or hybrid meshing with prisms and tetrahedra mixed. Thanks Thomas for pointing me to your commit about the HashCode function. According to the OCCT 6.5.3 release document that is exactly the way how this should be done. BTW: For my modifications I use oce 0.10. Opencascade is a pain to compile on Mac OS X, but with oce it's an absolute no-issue. It's really nice to see what the community has done here. My modification in swig_generator.py (function write_functions) on my computer was necessary because (apparently following the C++ standard) gccxml reports implicit copy constructors for the classes it parses (in cases where explicit copy ctors are absent). Compilation of the corresponding wrapper classes fails because of class members that can not be instantiated using copy construction. I found that there are versions of gccxml that do not report implicit copy constructors. With my version (V0.7 based on gcc V3.3.2) I had to filter them out using mem_fun.is_artificial (that's the way gccxml marks implicit functions). > * 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 ; I am not familiar with git, but wanted to learn using it sooner or later anyway, so now is the best time for that ;-). But I am not sure I understand you correctly. The branch you mention is already using oce 0.10 and has the SWIG files modified ? So there's not more to do for me other than contributing SMESH and GEOM modifications, right ? Those modifications I should send to Fotis Soutis (sfo...@gmail.com) for merging them into the sourceforge code trees, right ? And after that is done PythonOCC would incorporate them at a later time for a new PythonOCC release ? Best, Mark PS: In the GUI I developed using PythonOCC and PyQt I define boundary IDs on faces of the geometry and keep the surface grids after volume meshing such that I have the link OCC face --> surface triangles for setting boundary conditions. Periodic boundary conditions are more tricky because in that case I need to identify pairs of triangles for surface grids that must be identical. Am 16.08.2012 um 09:14 schrieb Thomas Paviot: > 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/, al/). 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/00141683e58a641ac1103e3d8df706b75a712332 > to 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
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
