Change variable key in `Fmi2Slave`

[fcollonval]

As the standard does not enforce the reference integer to be unique (I recalled we had some discussion about that).

Should we use a different key logic for the vars dictionary in Fmi2Slave?

May be something like typename_reference to be quickly built in the setter and getter.

[markaren]

The standards say that an Integer, Real, Boolean, String and Enumeration all can have valueReference=1

PythonFMU on the other hand uses unique valueReferences. This allows us to use the value reference as a key.

Any reason you'd want to change the current logic?

[fcollonval]

From my side no. But I know that sometimes people store data in array by type. This is probably the reason the standard allows the same reference for different type.

For example if the user applies that technique with bumpy array. He may want to use the reference to get a quick access to the data without the need for finding an owner/reference.

[markaren]

I'm sorry, but i don't see the use-case. Can you elaborate?

[fcollonval]

If the user has a data storage like the following:

class NpSlave(Fmi2Slave):

    def __init__(self, **kwargs):
        self.reals = numpy.array([1., 2., 3.], dtype=float)
        self.ints = numpy.array([-1, -2], dtype=int)


        self.register_variable(Real("real0"))  # value_reference=0
        self.register_variable(Real("real2"))  # value_reference=2
        self.register_variable(Integer("int0"))  #  value_reference=0
        self.register_variable(Integer("int1"))  #  value_reference=1

He may want to have a value_reference coherent of the array index storing the variable value.

[markaren]

But why?

Also that point is void if there are multiple arrays of type XXX.

[fcollonval]

To have generic efficient getter and setter.

    def get_integer(self, vrs: List[int]) -> List[int]:
        return self.ints[vrs].tolist()

    def set_integer(self, vrs: List[int], values: List[int]):
        for vr, value in zip(vrs, values):
            self.ints[vr] = value

[markaren]

Ok, so it is to override the current behavior. Then I can get on board. Although I still don't see the benefit for the user in doing so. But we can change the current implementation and have separate vars dicts for Integers, Reals, etc.

[fcollonval]

I know a couple of softwares that use internally that kind of data vector storage by type.

But as I said earlier, it is just a thought. And we could keep it like it is. As you said this will change the internals of the slave but not its API. So I think we can let this open, in case somebody shows an interest.

[markaren]

Closing for now