Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input functions of the form (u,t) for CS FMUs #183

Open
sathvikbhagavan opened this issue May 1, 2023 · 7 comments
Open

Input functions of the form (u,t) for CS FMUs #183

sathvikbhagavan opened this issue May 1, 2023 · 7 comments
Assignees

Comments

@sathvikbhagavan
Copy link
Contributor

From #123, input functions of the form (u, t) was introduced.

For CS-FMUs, it was not defined as internal states are not really accessible during simulation.

But it is possible to access the observables and use it for computing the next inputs, for example in closed loop controllers.

Is it possible to add this type of input function for CS-FMUs?

@ThummeTo

@ThummeTo
Copy link
Owner

ThummeTo commented May 2, 2023

Sure, you can use values = fmi2GetReal(componentOrFMU, identifierArray) with componentOrFMU is a fmi2Component or FMU2 inside the input function. identifierArray can include any value reference that is accessible (doesnt matter if state, derivative, input, output or parameter).

import FMIImport: fmi2GetReal

function myInput(t)
  values = fmi2GetReal(myFMU, ["value1", "value2"])
  inputs = ... # compute inputs based on values[1] and values[2]
  return inputs
end

@ThummeTo
Copy link
Owner

ThummeTo commented May 2, 2023

Basically one could also define a dedicated input function that gathers a fixed subset of values for every call (by calling fmi2GetReal in the background), but my first thought is that the way above is much more flexible and not much more complicated to handle.

@ThummeTo
Copy link
Owner

ThummeTo commented Jul 3, 2023

Does this answer your issue?

@ThummeTo ThummeTo self-assigned this Jul 3, 2023
@sathvikbhagavan
Copy link
Contributor Author

Sure, the answer works but it would be great if we have support for this in the API just like ME FMUs to maintain consistency.
If the implementation is not in your priority list, I would be happy to take it up.

@ThummeTo
Copy link
Owner

ThummeTo commented Jul 4, 2023

What method head do you have in mind?
I ask because larger FMUs often have thousands of observable variables and gathering all of them in a input function will be (unnecessary) expensive... so this should be coupled with an elegent way to define a subset of variables that are returned when the input function is executed.

@sathvikbhagavan
Copy link
Contributor Author

sathvikbhagavan commented Jul 10, 2023

What method head do you have in mind?

The method is the same as ME FMUs where the input function in this case can take in observables, i.e. variables in recordValues here

I am not sure if that is expensive or not.
Also, I would say the number of observables would be far less than number of states?

@ThummeTo
Copy link
Owner

I think something in this direction could be done (specifing the value references to retrieve when giving the input function).

Many FMI-Tools allow for the export of any variable in the system as observable value, so currently I am working with a model with only 6 states, but over 600 observables (would be really slow to retrieve them in every step) - but the suggested solution sems a good option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants