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.

Salome developers: you might want to pay extra attention to architectural issues whenever you introduce new dependencies.

Thank you for your considerations.

Roman

Hello Roman

In 6.3.0, SMDS data structure has been fully redesigned and now it's core is vtkUnstructuredGrid, the rest SMDS classes become just wrappers over vtk data.

Best regards
Edward

Hi Edward,

Thanks for a prompt response (wish it were always like this ).

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 ?

 

Thanks,

Roman

The main reason of the redesign is optimization of memory usage and performance of algorithms and visualization (as vtk grid is used for visualization in vtk viewer).

API of SMDS has not changed.

Express Mesh uses OMF which evolves independently from SMDS.

I know few about SMESH project, probably it will be affected.

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?

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

AFAIK none of those data structures are used in HEXABLOCK

Previously eXav wrote:

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.

 

Thanks to both for caring.

Roman

Hello Roman

Do you know if there were any opportunity to share data between SMDS and vtk_UnstructuredGrid without copying it ?

I see no way how it could be shared as those data structures were quite different, thus we had to duplicate mesh data to visualize it. Now it's not necessary.

Regards
Edward