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

Initialization using FMI input vars doesn't work properly #63

Open
ldcouto opened this issue Jun 7, 2017 · 2 comments
Open

Initialization using FMI input vars doesn't work properly #63

ldcouto opened this issue Jun 7, 2017 · 2 comments
Assignees
Labels
Milestone

Comments

@ldcouto
Copy link
Member

ldcouto commented Jun 7, 2017

If we initialize an object in the system class using a value from an FMI port (x.getValue()), the FMI value set from the outside is not actually used. It just uses whatever value was fed to the constructor in the beginning.

The only workaround I have so far is putting a check in the thread operation and do initialization on the first call. This is a little hacky.

@ldcouto ldcouto added the bug label Jun 7, 2017
@ldcouto ldcouto changed the title Initialization using FMI input vars doesn't wornot properly respected Initialization using FMI input vars doesn't work properly Jun 7, 2017
@lausdahl lausdahl added this to the v0.2.8 milestone Aug 6, 2017
@lausdahl
Copy link
Member

lausdahl commented Aug 6, 2017

There is not easy way to fix this in the tool I'm afraid. The inputs are set from a main context which is only available after the system is created. However, parameters should be set to the appropriate values before the system is created. How important is this feature? Usually the system in VDM is constructed using a static structure using values and not changing inputs. The system cannot change during simulation so it in that case only reflects the initial input anyway.

@lausdahl lausdahl modified the milestones: v0.2.8, v0.2.10 Aug 6, 2017
@ldcouto
Copy link
Member Author

ldcouto commented Aug 15, 2017

That's a pity. This is a big deviation from the standard.

Our use case for this is pretty standard. We have objects instantiated and deployed in the System class. True, the System class does not change but the variables inside its objects change all the time. These objects use input ports to represent sensor readings so the initial sensor reading is off and is only corrected after taking the first step. In some cases, this can really affect some of the evaluations we want to do.

Anyway, if this too hard to fix, we will live with it. But would be good to try to address in the long run.

@bandurvp bandurvp modified the milestones: v0.2.10, v0.2.12 Sep 22, 2017
@CThuleHansen CThuleHansen modified the milestones: v0.2.12, v0.2.14 Jan 11, 2018
@CThuleHansen CThuleHansen modified the milestones: v0.2.14, v 0.2.16 Nov 23, 2018
@peterwvj peterwvj modified the milestones: v 0.2.18, v 0.2.20 Feb 5, 2019
@lausdahl lausdahl modified the milestones: v 0.2.20, v 0.22.0 May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants