GeraultTr / Root_CyNAPS

0 stars 0 forks source link

Knowledge source definition for module coupling is not working when working outside MTG #31

Open GeraultTr opened 1 year ago

GeraultTr commented 1 year ago

Facing an issue while building the link function between modules. When setting attributes as inputs from another module's outputs, if both defined their properties with links from the same MTG, everything updates fine. However, when one of the modules is managing its property outside the MTG, the property is not updated between the two modules (here in with self for the FakeShoot.model, but I imagine it would be the same with a data enforcing module or while trying to communicate between two distinct MTG)

(See where this issue is refered in code)

GeraultTr commented 1 year ago

Understood the problem, at collar I tried to pass single values, as only list and dict are mutable. Solved with 2fb9520

pradal commented 1 year ago

Do not understand well your problem. But be carefull: In the code sometime it is xxx[1] and sometines xxx[0]

GeraultTr commented 1 year ago

Yes this is normal, I use xxx[1] to access the collar element in MTG's properties dict. However, when the passed variable between modules was simply a float, it was not mutable and then when shoot updates a flow, it was not seen by the roots. Thus, to be able to solve this issue, I enclosed this single value in a list (which is mutable), and this is why you saw xxx[0] to access the values. Maybe there is a better strategy but I didn't found better for now using the link_mtg() function.

pradal commented 1 year ago

OK. But working only with side effect is a problem. I do not have the whole picture, but in a way you want to share the properties between the processes. If each process have access to the dict (property): no problem. Otherelse, if you have a reference to the property value, you will need to work with side effect. And this is not good.

You can think about:

  1. having a global access to properties
  2. Get the local property value
  3. Modify it locally (like a local value in a function)
  4. update to the global property

I think this can be done nicely but we have to make it correctly.

GeraultTr commented 1 year ago

Ok thank you I will try to adapt things this way and I'll notify you when I have a proposition. Have a nice week end !

GeraultTr commented 1 year ago

Did another attempt with 596495f I declared global properties as spatialized MTG properties but only in vertice 1. That way :

  1. A global access to both types of properties is managed through MTG
  2. I get local properties value in the class the same way for globals and spatialized properties 3 and 4. As global properties are stored in {1: value}, value is modified in a mutable object that is properly updated between modules.