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
Clarify need for start values in input clocks #1066
Comments
This depends on the value of strict (as indicated in the subsequent paragraph). |
Decision from web meeting 17-06-2020: |
Ticket viewing Meeting: Andreas: I belive we should be able to set values at the beginning and to have start values |
This waits for clarification on clocks and events. |
Fixed in #1272. |
* Replace "numeric types" in text with concrete types * Move Set/GetClock to proper variable section; fix clock type * Clarify clocks are variables * Improve diagram to show clocked variables in super-dense time * Removed most of the clocks section, rewrote parts, moved stuff to attribute definitions * Changed index in figure to n/n+1 * Fix xrefs * Remove clockType attribute and all references * Change strict to interval * Add Motivation and Concepts of clocks * Move advancnig time; improve text; move Set/Get entire state * Fix clock descriptions * Add shift API * Add math definition for time-based clocks * Cleanup TODOs and empty section * Add qualifier description * Improve resolution and API description * Remove useless Representation section * Remove attribute `periodic` * Merge ClockType into general types * Fix inputClock and outputClock references * Remove useless clock overview table * Remove special case for input/output clocks in causality description * Fix a to an * Remove superfluous section on Clocks in Co-Sim * xrefs to early-return * Move code snippet * Change co-simulation algorithm to importer * Remove section Clock Support - correct content needs to be in state description * Revert "Remove section Clock Support - correct content needs to be in state description" This reverts commit 121cc2d. * Move counter resolution mechanics to table * Add Clock type image and link * Fix double of of * Move useful part of Sources Directory to proper section and reference to there * Merge multiple, multiple interface type sections * Explain information flow for clocks * Improve example for triggered input clock * Improve ZIP-description; fold in Source Code description * Fix chrbertsch comments * Resort and rename aperiodic clock types * Remove color coding descriptions; move concepts to state descriptions * Add math description to Instantiated and Initialization Mode * Improve description of structuralParameter * Move fmi3Terminate to proper state; add math description to Config Mode * Add math table to Terminated, Inititalized, Reconfig Mode * Cleanup * Improve Intermediate Update Mode description * Fix *Event Mode*, started only * Fix *Event Mode* math++; some formatting * Finish Event Mode update * Sort schema sections * Start fix to Continuous-time Mode * Finish fixing Cont-Time Mode * Move sections inside Model Exchange * Sort Co-Simulation chapter * Sort Scheduled Execution order * Fix *Step Mode* description * Fix appostrophies * Fir more of CS chapter * Finish fixing Co-Sim; add earlyReturnAllowed * Fix Model-Exchange Intro & Concepts * Fix ME Concepts, started * Merge a88a399 * Merge 45c32d9 * Finish fixing common concepts still in ME * Move concepts to general; fix rest * Move GetContStates and move GetVariables * Fix clock attributes in xsd; reexport xsd images * Fix formatting math and indentation * Fix formatting math and indentation II * Turn all states to xrefs * Add many xrefs to arguments and capability flags * Improve How-to-read-this-document * Cleanup TODOs * Turn platform to xref * Fix figures, remove unused images * Fix Fraction handling and attributes * Add definition of model partition and clocked variables; resorted common paragraphs; remove clockReference from xsd * Add DiscreteTimeState; renamed Derivative to StateDerivative * Fix formatting in SE * Turn Enumerations to long in XSD and prescribe proper Get/Set * Fix min/max handling * Improve Min-Max descriptions * Explain multi-Interface FMUs and variable lists * Generalize routing of IO * Clarify directly entering CS Event Mode * Clarify time-event cause * Add SPDX reference * Clarify units for function arguments and XML attributes when referring to time * Update copyright year; Add reference to CCLA * Fix example XML to use StateDerivative * Add super-dense time instant to glossary, replace time instance with time instant * Add non-normative explanation for nValues and nValueReferences * Fix #1281 going back to FMI 2.0 restrictions. * Fix #1066 * Add intro to terminals and icons; list in whats-new * Explain dynamic state selection, including reference * Add TODO * Fix umlaut * First run through SE, add math, fix functions, formatting * Fix in "before hand" and move clock sentence to clock row in table. * Start new sentence in non-normalize remark. * Typo: importer * Add missing comma. * Typo: localizing of * add "... or fmi3ActivateModelPartition" * intermediateUpdateTime not relevant here * Adding SE to Definition of Model Variables * dependencies + SE * fix clock type * rm TODO markers * add clock interval for triggered input * fix clock interval * Make clock type description consistent by using the title to start the sentence. * Remove lone parenthesis and wrong verb. * Improve English of sentence. * Fix typo. * Clarify non-normative text. * Fixing Christian´s and Claudio´s comments * Fix (3) and (4) for variability/causality combinations * Remove (19) in table * remove todos * fix typo * Fixing #1272 (review) * Add Allowed Function Calls to enter * Clarify caching Co-authored-by: Andreas Junghanns <andreas.junghanns@synopsys.com> Co-authored-by: Claudio Gomes <cla.gms@gmail.com> Co-authored-by: Matthias Blesken <MatthiasBl@dspace.de> Co-authored-by: Christian Bertsch <Christian.Bertsch@de.bosch.com>
Why do we force the FMU to provide a start value for a clock?
The following description is problematic:
Because:
offset = interval * shiftCounter / resolution
, can be zero, therefore the environment will (will it?) know when to execute them (right after initialization), without having the need for a start value for the clock.@KarlWernersson , the working group on clocks need your input on this one.
The text was updated successfully, but these errors were encountered: