SALOME-9.5.0 Save/Load Study with multiple Python modules

Hello,

we have multiple python modules (let us say different PYHELLO modules that has implemented Save/Load in the engine class). When creating cases in these modules and then saving the study, the data saves to the hdf (we save bytestrings so it is easy to check in the hdf).

But when we load the study, I see that the first module that gets activated get's all the data passed to the Load function. The Load functions from other modules don't get called.

So basically, when saving a study, all the Save functions from modules are called and all the bytestreams get joined into one bytestring. And when we open the study the whole bunch of data is served to the first python module that is activated.

Can someone help with this? Is our thinking wrong? Should there be only one Python CORBA module that handles the data? Or should all the data be stored in SALOME objects (attributes)?

Best regards,

Gregor Simic

Hello Gregor,

It is normal behavior that when a module is activated only its data is loaded. In SALOME, each module's data is stored in a separate record within the HDF file. When you activate a module, only its part of data is loaded and transferred to that module. Data of other modules will be loaded only when those modules, in their turn, will be activated.

On the other hand, you can forcibly load data to other modules when one module is activated (if this is really necessary for you) - in this case you must manually load that module (salome.lcc.FindOrLoadComponent()) and then load its data via study builder (salome.myStudy.NewBuilder().LoadWith()).

See an example of such behavior in SMESH module which automatically loads GEOM (since Mesh module relies on the Geometry data), see SMESH_Gen_i::UpdateStudy() method:

https://git.salome-platform.org/gitweb/?p=modules/smesh.git;a=blob;f=src/SMESH_I/SMESH_Gen_i.cxx;h=66f8570a3e32ba65299fd78a702c1b8e5ee42959;hb=refs/heads/master#l691

SMESH is written in C++, but the same approach can be implemented in Python as well.

Regards,
Vadim.

Hello Vadim,

thanks for the answer. The problem we are observing is that the first python module that gets activated gets the complete saved (its data + all the other custom python modules saved data) and those modules do not get loaded with salome.lcc.FindOrLoadComponent.

I am beginning to suspect that we have registered these modules incorrectly, i.e., all have equal identifier and SALOME cannot distinguish between them when loading a study.

Thanks for help and best regards,

Gregor Simic

Hello Gregor,

Indeed, there is a bug in the SALOME GUI module Thank you for reporting this problem and thus helping us detecting and solving it.

Unfortunately there is no workaround to easily solve this problem, you'll need to rebuild GUI module The fix will be soon available in Git repository.

Regards,
Vadim.

Here's the fix: https://git.salome-platform.org/gitweb/?p=modules/gui.git;a=commit;h=8faac81a

Hello Vadim,

rebuilt GUI with this patch and it works. Thank you very much!

Best regards,

Gregor Simic

Hello Vadim,

sadly I have to report another issue. The fix works when opening a study which has saved data for multiple python modules. Each module is properly loaded. But if we do this, in the same SALOME session:

1. Launch SALOME

2. Open a study that contains data for python module 1. Activate python module 1. Data is loaded for module 1.

3. Open a study that contains data for python module 2. Activate python module 2. Data is not loaded for module 2, i.e., same behavior as before.

I am in the dark to python module loading. Is this all performed via GUI module? It seems that the module is activated but not notified about the change of the study?

Best regards,

Gregor Simic

Hello Gregor,

With the fix I implemented described scenario must work correctly. I tried on the small Python modules I implemented to debug this bug and did not see the problem you described. Maybe there's something wrong with your implementation of modules. When a study is closed, each Python module is notified via the Close() method. See attached archive with sample modules.

If you can provide a scenario that reproduces the problem, I should be able to debug it. Thank you in advance.

Regards,
Vadim.

Hello Vadim,

sorry, you are right. Thank you for providing the test modules. The problem is connected in the implementation of our modules. Everything works now! Thanks again.

Best regards,

Gregor Simic

Hello Vadim,

sorry to disturb you again. I have found the problem to the previously mentioned issue. The problem is when we activate modules in such an order (open study1, activate module1, then open study 2 and activate module 2) the IOR strings for both module engines is the same. If we activate the modules in one study, this problem does not arise.

The modules we made are based on PyHello. At the same time if I test your provided simple modules this does not happen.

Could this help with our issue?

Best regards,

Gregor Simic

Initial problem was in GUI module - there was a static variable used to store engine IOR's value. The fix consisted in removing that static variable.

Since you use an implementation based on PYHELLO, please pay attention on what is returned in the engineIOR() method implemented in your GUI Python modules. The problem must be there.

Hello Vadim,

I agree, the error must be there, but apart from adding GUI functionality, editing Save/Load functions we didn't modify the MODULE_utils.py functions, except for module identifiers. And I am baffled. If I use the MODULE_utils.getEngineIOR function from SALOME python window, then I see that each module creates an instance of the module containers and all the other sub-objects and returns a unique IOR.

But if I use salome.lcc.FindOrLoadComponent('FactoryServer', 'MODULE_NAME') then I obtain the same IORs. Attached is SALOME_VERBOSE=1 trace with std::cout put in the same function where the patch is. I have renamed the module names to MODULE1 and MODULE2.

Of course I double checked if I applied the patch, just to be sure I am not wasting your time. I also suspect that I do not understand fully the procedure of the interface between the python module and GUI.

Best regards,

Gregor Simic

Hello Gregor,

Thank you very much for reporting - you helped us to debug an important problem. I found and removed another static variable in the code, please try one more patch:

https://git.salome-platform.org/gitweb/?p=modules/gui.git;a=commit;h=2b4080cc 

Regards,
Vadim.

Hello Vadim,

I am glad I've helped. I have rebuilt GUI with both patches applied and it works!!!!

Best regards,

Gregor Simic