Add a new type of service TimeseriesService

[jinningwang]

Is your feature request related to a problem? Please describe.
N/A

Describe the solution you'd like
A new type of Service or Variable TimeseriesService to lazy evaluating given expression, for value accessing and plotting. This enhancement can reduce unnecessary calculation burden in DAE.

For example, GENROU.Pe is now an Algeb being calculated in DAE, but it is mainly used in plotting after simulation.

andes/andes/models/synchronous/genbase.py

Lines 245 to 248 in 5ab784b

	self.Pe = Algeb(tex_name='P_e',
	info='active power injection',
	e_str='u * (vd * Id + vq * Iq) - Pe',
	v_str='u * (vd0 * Id0 + vq0 * Iq0)')

Describe alternatives you've considered

@cuihantao Welcome your further suggestion

The major point is this type does not have internal storage and does not involve DAE. The values are presented given predefined e_str when calling only.

A possible implementation can be:

class TimeseriesData:
    
    def __init__(self):
        ...

    @property
    def v(self):
        ...
        return v

Additional context
N/A

[jinningwang]

@cuihantao Hantao, if a new patch or minor version is not in hurry, I can finish this in 2~3 weeks. Then we can include this feature in the new version.

[cuihantao]

Sure. There's already something similar. It allows one to load a series of data from CSV. See if that's what you need.

[jinningwang]

Sure. There's already something similar. It allows one to load a series of data from CSV. See if that's what you need.

Not the same. Let me further clarify my expectation in short.

[cuihantao]

Do you mean dependent variables that do not need to be calculated in the DAE? It's also known as observed variables in the Julia ModelingToolkit. If would be great if we can have that feature!

[jinningwang]

I checked the thing you mentioned, and I feel yes. The only drawback I can see right now, we might need manually remove dependent variables. Although I don't know if ModelingToolkit.jl can do it automatically, we can at least manually eliminate some dependent variables for better DAE calculation and storage.

A quick follow up is, I expect to develop this class under the category of Services, as they have expressions, and they do not have storage in DAE. Does this sound like a good idea with current ANDES framework?

Reference:

https://docs.sciml.ai/ModelingToolkit/stable/internals/#Observables-and-Variable-Elimination

In the variable “elimination” algorithms, what is actually done is that variables are removed from being unknowns and equations are moved into the observed category of the system. The observed equations are explicit algebraic equations which are then substituted out to completely eliminate these variables from the other equations, allowing the system to act as though these variables no longer exist.
However, a user may want to interact with such variables, for example, plotting their output. For this reason, these relationships are stored, and are then used to generate the observed equation found in the SciMLFunction interface, so that sol[x] lazily reconstructs the observed variable when necessary. In this sense, there is an equivalence between observables and the variable elimination system.

[cuihantao]

Service is not designed to facilitate this purpose. Service does not store the values over time, which is what you are looking to address.

The observed/dependent variables are like variables. They would benefit from having an address, so that one dimension is the variable values and the other dimension is time. This will require an overhaul of the address manager.

The difference from DAR variables is that the dependent variables can be calculated after the simulation is completed (or not computed at all).

[jinningwang]

Let me maybe do an initial draft first given your input. Then we can dive into more details.

[jinningwang]

My idea is to use a Service and use a property method v to do calculation upon request.

class OBService(BaseService):

    def __init__(self):
        self.v_str: str = v_str

    ...

    @property
    def v(self):
        """
        Return the value of the observable service.

        Returns
        -------
        array-like or a scalar
            The value of the observable service
        """
        # NOTE: do the calculation here
        pass

Comparison:

Mine:
pros: easy-to-implement (now I doubt it)
cons: takes extra efforts to fit plot functions

Your:
pros: a more decent implementation; directly fit plot functions
cons: need more knowledge with the address manager

Conclusion:

Maybe let me take a look with address manager

[cuihantao]

Good summary!

[jinningwang]

Hantao, after first step evaluation these two days, I feel this issue needs more efforts than I expected before.

I can keep this in mind as a mid-term in mind and discuss with you after coming up with a more decent plan.

Feel free to do a minor/patch release before we address this.