Dear Pierre,

First, rigid body simulation and assembly sequencing are, according to me,
really different topics in term of objectives and expected outputs (the
slideshow attached is quite old, one of my colleague presented a more recent
paper related to this topic at the MOSIM'08 conference)

The second point is that the objective of the pythonOCC project is not to
cover the huge scope of engineering and implement the best ideas from best
papers published in best journals/conference. It's something that can not be
achieved by a few people. We just aim at providing a platform enabling such
an implementation in the easiest possible way.

The development strategy can be sum up in a few words: let's take the best
existing free and open source libraries in engineering field, and let's find
a way to integrate them in a new consistent environment. Current pythonOCC
release (0.4) is built upon OpenCASCADE, SMESH, GEOM. Then next one will add
Traits support, OpenDE (rigid body simulation), maybe fem solvers etc. Each
of those libraries are developed by many skilled engineers. The added value
of the pythonOCC project is then the *integration* of these libraries. Free
and open source development model, as well as the use of standards, make
such an integration be achieved by a few motivated people (actually, it's
not demonstrated yet, but I want to prove that it's possible).

The added value being *integration*, it's out of scope of the project to
develop/implement low-level features such as 'automatic assembly sequencing
from semantics extraction'.

Best Regards,

Thomas

2010/2/24 Pierre JUILLARD <pierre.juill...@gmail.com>

>
> Dear Thomas,
>
> Following you mail concerning rigid body simulation, I wanted to mention a
> work illustrated on the OpenCascade website concerning modelling of assembly
> and that may be related to rigid body simulation most notably in the
> "detection of contacts" topics.
>
> Here is the link of the documents:
> http://projects.opencascade.org/projects/doc/TheseNRejneri-FR.ppt
> (you can also find the thesis on the web)
> (link of this project:
> http://projects.opencascade.org/projects/assembly.html
> link of the project library page which gathers other interesting links:
> http://projects.opencascade.org/projects/)
>
> I wanted to know if such features are available in pythonOCC?
> Usually, such a management of parts is complex, but is very interesting to
> identify assembly problems.
>
> I thank you in advance for your comments.
> Best regards,
>
> Pierre
>
>
>
>
>
> 2010/2/21 Thomas Paviot <tpav...@gmail.com>
>
>> Dear all,
>>
>> A few years ago, I developed a software aimed at providing rigid body
>> simulation features to Catia V5 or SolidWorks. This project, known as
>> "Decade dynamics", is not active anymore although many users are frequently
>> asking for new features or bugfixes (for your information, a website
>> dedicated to the project is available at  http://www.decade-dynamics.org,
>> there also is a PDF document here:
>> http://download.gna.org/decade/decade_A4_recto_basse_def.pdf and
>> http://download.gna.org/decade/decade_A4_verso_basse_def.pdf - All this
>> material is in french, sorry).
>>
>> The limitations I faced when working on that project are the root of my
>> motivation to start the pythonOCC project:
>> - the small 'free' API provided with Catia or SolidWorks (a VB API) is not
>> sufficient to access all internal classes/method,
>> - the complete API (known as CAA for Catia) is very expensive,
>> - there are licensing issues if you ever want to redistribute such a
>> program. I chose to distribute Decade under the GPL license, and never had
>> any problem with software vendors: I never made money with it, there's no
>> real business opportunity, so lawyers dont' care about my work.
>>
>> However, I'm still interested in rigid body simulation, since it's much
>> important when working in the robotics/mechatronics field and, more
>> generally speaking, in engineering. I committed to the pythonOCC subversion
>> the first draft of a DYN package dedicated to rigid body simulation (you can
>> have a look at this video to see the first results:
>> http://www.youtube.com/watch?v=IW5VYbCGFYc).
>>
>> This DYN package is at the same level as PAF(Parametric Application
>> Framework). The set of sub-packages PAF/DYN/MSH/FEM are what we called the
>> 'Level2 API': it's an intermediate layer between the OCC kernel (LeveL1) and
>> the applications that can be built on top of them. The goal is also to make
>> them interoperable, I mean being able to exchange data in a consistent way:
>> I imagine a 3D complex model, made with PAF, simulated with DYN to get
>> forces in joints, checked with a FEM analysis, then optimized  according to
>> these results (the design/simulation loop), and finally exported to a STEP
>> file for manufacturing. All of these sub-packages would rely on
>> a semantically explicit knowledge (KBE). Well, this is not a roadmap, rather
>> a long term objective...
>>
>> Please let me know if you have any comment or suggestion,
>>
>> Best Regards,
>>
>> Thomas
>>
>> _______________________________________________
>> 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

Reply via email to