2012/8/17 Mark Blome <bl...@zib.de> > > Hi Thomas, hi Jelle, >
Hi Mark, > > 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. > Thank you for this feedback. A few months ago, I was about to drop SMESH support, since I do no use it and it's a tough work to get it wrapped in pythonocc. > > 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). > So this patch can come has a gccxml fix. It can be commited in a branch created from the master branch, since it does not depend on the oce version. > * 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 ;-). > The move from svn to git requires some efforts, but it's worth trying, you'll get definitely convinced. > 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 ? > Yes, for Linux/OSX only, not Windows. > So there's not more to do for me other than contributing SMESH and GEOM > modifications, right ? > This branch does not include support for SMESH and GEOM yet. 'not more to do than' is a time consuming task: patch GEOM, patch SMESH, generate SWIG files, compile, run and fix GEOM unittests, run and fix SMESH examples. In my experience, it can be one week of full time job just to achieve this task. That's why, unfortunately, and did not do it so far. So your contribution is *very* welcome. 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 ? > According to the first paragraph of your email, you successfully created standalone versions of GEOM and SMESH. I do think that it's better to contribute this work up to Fotis than creating another project or hosting your C++ modifications into the pythonocc repository. Fotis has a long experience with SMESH/GEOM, we should not reinvent the wheel. It would IMO be the best possible solution. The workflow you described is correct. But the "later" can be quite fast since we can request a new release of standalones GEOM and SMESH libs when we're ready. > > 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. > In an older post, we already discussed licensing issues between PyQt (GPLed) and pythonOCC (LGPLed). A possible solution is to move to pyside (LGPLed) for the pythonocc/Qt support. Did you experiment pyside ? on OSX? Regards, Thomas > > > 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/<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 > > > > _______________________________________________ > 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
