Extra dependency on VTK in 6.3.0 SMDS

Extra dependency on VTK in 6.3.0 SMDS

In 6.3.0, SMDS (part of SMESH) comes with extra classes
(SMDS_UnstructuredGrid, SMDS_*Vtk*, etc), which introduce link dependence on Kitware's
VTK. The dependence seems to be excessive as it violates the MVC (Model-View-Controller)
concept and makes data structure (SMDS) depend on GUI (VTK). It is probably not
an issue for Salome GUI application itself but it is an issue for Salome-based
applications/components, which just reuse Salome data model. The more correct architectural
approach could probably be to have an extra shared library (.so or .dll)
extending SMDS by subclassing its classes and linked with VTK.

The work-around which I am going to apply is to introduce a
macro (e.g. SALOME_SMESH_NO_VTK) and modify the SMDS source code as follows:

#ifndef SALOME_SMESH_NO_VTK

//... use VTK-dependent stuff

#endif

And to define it in my own project only. Default compilation
Salome won’t be affected.

Re: Extra dependency on VTK in 6.3.0 SMDS

Well, that makes it even worse that I thought , if an entire data model is now based on VTK. I will probably have to revisit my plans to migrate to 6.3.0 and rather stay with 5.1.5 as the vital parts (relevant for my usage) have not changed in between.

Just out of curiosity - what was the rationale for this move ? And secondly, how does this new dependence affect users of the Express Mesh component of Open CASCADE, which claimed to support interface with SMDS ? Will they now be forced to take burden of VTK dependence ? And, obviously, the SMESH project - http://sourceforge.net/projects/salomesmesh/ - will now be directly adversely affected, won't it ?

Re: Extra dependency on VTK in 6.3.0 SMDS

Hello Roman. For example we had a problem with large meshes ( millions of elements ). If I understand, in 5.1.5 SMDS structures based on containers of pointers. And if you CLEAR the mesh, SMDS clear only containers of elements, but memory not be free.

Do you have the same problem?

Hello Edward,

May be you know. Is special data structures (e.g vtkStructuredGrid or MED::GRID) using in HEXABLOCK framework for represent structured mesh?

Re: Extra dependency on VTK in 6.3.0 SMDS

Hello Roman. For example we had a problem with large meshes ( millions of elements ). If I understand, in 5.1.5 SMDS structures based on containers of pointers. And if you CLEAR the mesh, SMDS clear only containers of elements, but memory not be free.

Do you have the same problem?

Hello Edward,

Thanks for explanation. I see the valid point in reducing memory footprint but am still not convinced if it was strong enough to effectively eliminate a possibility of any GUI-less Salome-based app. Do you know if there were any opportunity to share data between SMDS and vtk_UnstructuredGrid without copying it ?

As for Express Mesh, I seem to confuse it with the OMF component, which claims "Availability of the source code of the SMDS package allows to adapt and to extend the component for particular applications"

. With Salome 6.3.0, I think this benefit either goes away or it will now have to use a fully cloned copy of pre-6.3.0 version ? Neither would be good .

Hello eXav,

Thanks for a comment. The issue of not freed memory is not in the design but in flaws in implementation of memory management and failure to correctly free allocated resources. There seem to be multiple issues at least in SMESH, some were reported in another thread and some on my opencascade blog

. They can be fixed regardless of implementation. I don't know if VTK offers any facilities in garbage collection but given that this is still C++, it is developer's responsibility to correctly use it even if it exists.