It is obvious that we will use existing meshers as
they are available. Most of them are written either in C++ or C and will be accessible either through JNI or CORBA as third parties components (like the OpenCascade Geometry kernel). As far as the surface mesher is concerned, we are willing to
push the JAVA technology as far as possible. Nevertheless we don't exclude the possibility to use a C/C++ component especially if JAVA turns out to limit the global performance of the tool.
Let's wait a bit & see.
What are your needs for such a C++ implementation ?
>What are your needs for such a C++ implementation ?
First, as I don't use Java, I don't really need a java implementation (sic).
If you pack it in C++ for using it with OpenCASCADE, it will be good if you provide quite the same implementation/interfaces like the existing meshers ( BRepMesh_IncrementalMesh) and generate a mesh structure like in the shapes (Handle_Poly_Triangulation )
I do understand your point. First let me say that if you want to stick to a C++ implementation you will certainly get much more from the SALOME project.
Then, if we moves at some point (for performance reason) to a C/C++ implementation we will try to conform to the existing API despite the fact that
we are not dealing in this project with meshes dedicated for visualization.
I have the same points than Stephane. But I think a C++ implenmentation will always be faster than a Java implementation - so why develop 2 times?
And SALOME? Could be nice for using it - but no one gives informations about release dates or anything else. So its just a "perhaps we can use it" - but without informations and when?
I do agree with you on the principle. Up to now a C++ implementation is faster than a Java one but
the difference is vanishing. On the other hand, there are other advantages to Java:
- many things are available out of the box (graphics, distributed computing, ...). If we want to provide quickly a complete framework it's good to exploit Java & all the projects coming with it,
- programming in Java lead (at least for me) to
much cleaner code than with C++. Although this may be controlled by guidelines, I think that for an open-source project it is good if you can control in some way the quality of the software. Reading regurlarly this forum, it seams it is
something important.
- at the end, I do not think that performance is the most important problem of a framework. Thanks to Microsoft then Intel/AMD, the performance of the processors is increasing regurlarly. So I think the Java choice is not so odd as it can look at a first glance.
As far as SALOME is concerned, it is not my duty to keep you informed but whispers told me that it
should come soon.
I do understand your position. But thats only one part of a nice framework. For example if you look at VTK or OCC, a C++ version gives you the possibility for using TCL or Python too!
And as far as I know there are toolkit like pvm, mpich or OmniORB helping you with distributed computing and so on...
Thu, 03/13/2003 - 16:16
Hi,
any thoughts about a C++ version of the mesher??
Regards,
Patrik
Thu, 03/13/2003 - 23:38
Hi,
It is obvious that we will use existing meshers as
they are available. Most of them are written either in C++ or C and will be accessible either through JNI or CORBA as third parties components (like the OpenCascade Geometry kernel). As far as the surface mesher is concerned, we are willing to
push the JAVA technology as far as possible. Nevertheless we don't exclude the possibility to use a C/C++ component especially if JAVA turns out to limit the global performance of the tool.
Let's wait a bit & see.
What are your needs for such a C++ implementation ?
Yours
Guillaume
Fri, 03/14/2003 - 00:56
Hi Guillaume,
>What are your needs for such a C++ implementation ?
First, as I don't use Java, I don't really need a java implementation (sic).
If you pack it in C++ for using it with OpenCASCADE, it will be good if you provide quite the same implementation/interfaces like the existing meshers ( BRepMesh_IncrementalMesh) and generate a mesh structure like in the shapes (Handle_Poly_Triangulation )
my 2 cents,
Fri, 03/14/2003 - 08:05
Hi Stephane,
I do understand your point. First let me say that if you want to stick to a C++ implementation you will certainly get much more from the SALOME project.
Then, if we moves at some point (for performance reason) to a C/C++ implementation we will try to conform to the existing API despite the fact that
we are not dealing in this project with meshes dedicated for visualization.
cu
Guillaume
Fri, 03/14/2003 - 09:10
Hi Guillaume,
I have the same points than Stephane. But I think a C++ implenmentation will always be faster than a Java implementation - so why develop 2 times?
And SALOME? Could be nice for using it - but no one gives informations about release dates or anything else. So its just a "perhaps we can use it" - but without informations and when?
Regards,
Patrik
Mon, 03/17/2003 - 14:08
Hi Patrik,
I do agree with you on the principle. Up to now a C++ implementation is faster than a Java one but
the difference is vanishing. On the other hand, there are other advantages to Java:
- many things are available out of the box (graphics, distributed computing, ...). If we want to provide quickly a complete framework it's good to exploit Java & all the projects coming with it,
- programming in Java lead (at least for me) to
much cleaner code than with C++. Although this may be controlled by guidelines, I think that for an open-source project it is good if you can control in some way the quality of the software. Reading regurlarly this forum, it seams it is
something important.
- at the end, I do not think that performance is the most important problem of a framework. Thanks to Microsoft then Intel/AMD, the performance of the processors is increasing regurlarly. So I think the Java choice is not so odd as it can look at a first glance.
As far as SALOME is concerned, it is not my duty to keep you informed but whispers told me that it
should come soon.
Regards
Guillaume
Regards,
Guillaume
Mon, 03/17/2003 - 14:36
Hi Guillaume,
I do understand your position. But thats only one part of a nice framework. For example if you look at VTK or OCC, a C++ version gives you the possibility for using TCL or Python too!
And as far as I know there are toolkit like pvm, mpich or OmniORB helping you with distributed computing and so on...
Best regards,
Patrik