Post by Mark Blomethanks 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
pythonocc.
Post by Mark BlomeThanks 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.
you'll get definitely convinced.
Yes, for Linux/OSX only, not Windows.
This branch does not include support for SMESH and GEOM yet. 'not more to
files, compile, run and fix GEOM unittests, run and fix SMESH examples. In
task. That's why, unfortunately, and did not do it so far. So your
contribution is *very* welcome.
standalone versions of GEOM and SMESH. I do think that it's better to
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
we're ready.
(GPLed) and pythonOCC (LGPLed). A possible solution is to move to pyside
(LGPLed) for the pythonocc/Qt support. Did you experiment pyside ? on OSX?
Post by Mark BlomeHi Mark,
Thank you for your post. It's not that usual that people here contribute
to the low level SWIG layer.
Post by Mark Blomethanks 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.
Post by Mark BlomeFor 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?
Post by Mark BlomeI 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.
Post by Mark BlomeI 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
Post by Mark BlomeStandard_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.
Post by Mark BlomeAlso I had to modify SWIG_generator.py to avoid the generation of
artificial copy constructors by adding
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?
Post by Mark BlomeIf 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
* 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
include your changes.
Much looking forward to discussing these issues with you,
Best Regards,
Thomas
Post by Mark BlomeDear Mark,
I am developing a CAD & Meshing application for finite element
Post by Mark Blomesimulations (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.
Post by Mark BlomeI very much enjoy the rapid software development PythonOCC offers - it's
fun and robust at the same time.
Good to hear so.
Post by Mark BlomeFor the software I develop I decided to update my local PythonOCC
installation to the latest version of the underlying libraries
- 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
Post by Mark BlomeI 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
Post by Mark BlomeTo 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?
Post by Mark BlomeThere 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
In [1]: from OCC.Standard import *
In [2]: print Standard_Transient.HashCode
<unbound method Standard_Transient.Standard_Transient_HashCode>
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 )
Post by Mark BlomeAlso 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
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
https://mail.gna.org/listinfo/pythonocc-users