Let <EventIndicator> inherit from fmi3Unknown

[t-sommer]

• Re-generated schema figures.

see #1370

[andreas-junghanns]

@t-sommer : what is missing here for review? Can I help?

[t-sommer]

The schema figures still need to be regenerated.

[KarlWernersson]

Dont we get dependecies and dependenciskind if we do this?
I don't think we want that.

I am quite sure float32 is not supported for event indicators just as it is limited for derivatives states etc?

[KarlWernersson]

See previous comment

[KarlWernersson]

@t-sommer @masoud-najafi @TorstenBlochwitz @CSchulzeTLK

Hi

I just want to make sure that we all understand the changes we make and its implications before we implement them, as I did not understand that at the start of the discussion.

I am no longer contesting the need to expose event indicators. And if I understand the use case for that was additional debug information.
Because of this when it was first implemented we explicitly say in the standard that we don’t have dependencies (unless this was a bug?)

Now there is a proposal to add the dependencies to event indicators as this will uniform model structure. I agree that this goal is good but we need to go over the implications before we do the change. If it is just for debugging, do we want all these extra features? Or will we expand the use case?
If we do not want these features should we put the information somewhere else instead of in the modelStructure.

• GetDirectional/Adjoint Derivative, for all other variables in modelStructrue getDireciotnalDerivtatves is allowed at some state. If we allow this for modelStructre it requires any exporter that supports this functionality to also support it for eventIndicatros. The state is is allowed should be listed in 2.2.11 my assumption would be that we allow it during continuous time but disallow during event mode.
  If do not want to allow this it needs to be explained why.

• Should they be included in Initial Unknowns. Then we need to update table 24 as well
  -- I would say yes if we go for dependencies

• can they have a fixed start value?
  -- I do not see a reason to forbid it

[TorstenBlochwitz]

Looks OK.

[chrbertsch]

What was the conclusion at the regular design meeting on this PR? Could someone please summarize?

[andreas-junghanns]

What was the conclusion at the regular design meeting on this PR? Could someone please summarize?

We accept this PR, but need to extend it by some restrictions w.r.t. derivative computations for EventIndicators.

@KarlWernersson will provide some wording with a pointer where to put it in this issue as comment and I will add this to the PR.

[KarlWernersson]

@andreas-junghanns
reading the document I am not compliantly sure on were to put such a restriction.
As we are now explicitly stating which variables can be retried at which state by defining unknowns at 2.2.11. Getting Partial Derivatives

However to avoid confusion I would recommend a remark something in this style..

_Note that Event indicators are not included among the unknowns. This is intentional as their dependences in modelStructure are intended for debugging purposes and not for partial derivatives. _

[KarlWernersson]

A similar remark could be put in InitialUnknowns 2.4.8 table 24

Event indicators are available during initialization mode however since their dependencies are intended for debugging purposes and not for connection with other FMU's they should not be listed among the initial unknowns

[andreas-junghanns]

Event indicators are available during initialization mode however since their dependencies are intended for debugging purposes and not for connection with other FMU's they should not be listed among the initial unknowns

Please check if my changes reflect your intendions...

[andreas-junghanns]

Note to self:
We need to merge master back into this branch and regenerate images before merging back into master.

[KarlWernersson]

Looks great thanks =)

[andreas-junghanns]

t-sommer: Can you merge the XSD changes, regenerate the images and then merge into master? Please?