Hi Jelle and Thomas,
thanks for pointing me to the OCEworkflow document.
My SMESH / GEOM modifications are following along the line of what Fotis
Soutis did (Corba stuff removed), with working NETGEN and Tetgen mesher
Plugins.
I am going to contact Fotis Soutis about my modifications to see if he is
interested in them. I think it would be really great if there would be a
PythonOCC
release based on oce 0.10 and SMESH/GEOM V6.5.0 with Netgen and Tetgen
integration sometimes in the foreseeable future.
Thomas , I cloned into your "tp/oce-0.10-support" branch on github and tried my
software on oce 0.10 wrapped using your interface files (with my SMESH/GEOM
extensions) and it works like a charm ! Gosh, I should have checked the git
repositories before diving into modifying the PythonOCC-0.5 SWIG interfaces.
Well, at least
I learned a lot during that week ;-).
I have a few questions about the SWIG interface files:
- How much time and effort do you think would it take for also updating
the win32 swig interface files ?
- I think the gccxml issue I am having on my Mac really is related to
my gccxml version being 5 years old.
So I don't think a patch about that is necessary. What do you think ?
- I was wondering about the renames in TopoDS_renames.i:
%rename(vertex) TopoDS::Vertex;
%rename(edge) TopoDS::Edge;
...
In the version I used before, I could do TopoDS().Vertex(),
TopoDS().Edge(), etc. What is the rationale behind these changes ?
best,
Mark
Am 17.08.2012 um 12:12 schrieb jelle feringa:
> hi Mark,
>
> thanks for your comments and hints.
>
> Its exciting to have you onboard =)
>
> 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.
>
> That figures.
> So your API resembles SMESH, with the Corba crap yanked out of it?
>
> IMHO GEOM and SMESH are a huge plus for PythonOCC.
>
> hear hear, and considerable easier to work with than delving into Salome, so
> yes, its a forté, also taking into account the "options" are fairly limited
> if your keen on working in OS
>
> 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)
>
> Hmmm... that version is ~ 5 years old...
>
> 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 ?
>
> Nope. Its best to have a branch dedicated for your work.
> Once all is nice & peachy, it can be branched back into the master.
> Perhaps its best to read up on the OCE workflow, which reflects some solid
> ideas on developing with git as your cvs
>
> Those modifications I should send to Fotis Soutis (sfo...@gmail.com) for
> merging them into the sourceforge code trees, right ?
>
> [ CC'd to Fotios ]
> Fotios maintains GEOM and SMESH as a separate project.
> It would be interesting to diff both trees, from there it would be more
> practical to see what is the overlap between the projects.
>
> And after that is done PythonOCC would incorporate them at a later time for a
> new PythonOCC release?
>
> Yep, when your branch works well and doesn't clash with master and it tested,
> than its time to merge things back into the master, and time to release.
>
> 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.
>
> Clever! I'm working on a PythonOCC based gui too, which is based on enthought
> traits, which allows for very rapid development of GUI's.
> Curious to hear your take on PyOCC gui development.
> But that's another thread ;D
>
> Cheers!
>
> -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
