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
