Clarifications needed in FMI 1.0 to be added to FMI 1.0.1

[modelica-trac-importer]

Modified by andreas.junghanns on 26 Jan 2017 14:11 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	included
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt	included
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none	included
CS	Appendix B speculates about future versions.	1	remove Appendix B	none	included
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none	included

---

Modified by andreas.junghanns on 26 Jan 2017 09:56 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	unclear where, Antoine, please do this.
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt	included
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none	included
CS	Appendix B speculates about future versions.	1	remove Appendix B	none	included
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none	included

---

Modified by andreas.junghanns on 2 Aug 2016 13:07 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME, CS reference?
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	unclear where, Antoine, please do this.
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt	included
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none	included
CS	Appendix B speculates about future versions.	1	remove Appendix B	none	included
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none	included

---

Modified by andreas.junghanns on 2 Aug 2016 12:56 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME, CS reference?
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	unclear where, Antoine, please do this.
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt	included
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none	included
CS	Appendix B speculates about future versions.	1	remove Appendix B	none	included
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none	included
ME, CS	"calculatedParameter" is used to describe what the text often calls "dependent parameter".	1	Since the XML cannot be changed, if we want to have consistent (easy to understand) descriptions, we need to rename dependent parameters in the text to calculated parameters.	none

---

Modified by andreas.junghanns on 6 May 2016 13:05 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME, CS reference?
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	unclear where, Antoine, please do this.
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt	included
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none	included
CS	Appendix B speculates about future versions.	1	remove Appendix B	none	included
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none	included

---

Modified by andreas.junghanns on 6 May 2016 12:46 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME, CS reference?
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	unclear where, Antoine, please do this.
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt	included
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none	included
CS	Appendix B speculates about future versions.	1	remove Appendix B	none	included
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none

---

Modified by andreas.junghanns on 6 May 2016 11:55 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME, CS reference?
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none	unclear where, Antoine, please do this.
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none	included
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none
CS	Appendix B speculates about future versions.	1	remove Appendix B	none
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none

---

Modified by andreas.junghanns on 6 May 2016 11:47 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included in ME, CS reference?
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none
CS	Appendix B speculates about future versions.	1	remove Appendix B	none
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none

---

Modified by andreas.junghanns on 6 May 2016 11:43 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe	included
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none	included
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none	included
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)	included
ME, CS	In the current 1.0 specification, nothing is stated about aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity	included
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise	included
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none
CS	Appendix B speculates about future versions.	1	remove Appendix B	none
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none

---

Modified by andreas.junghanns on 6 May 2016 08:58 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)
ME, CS	In the current 1.0 specification, nothing is stated about that and some FMU define aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none
CS	Appendix B speculates about future versions.	1	remove Appendix B	none
ME, CS	different license texts used in different documents (spec vs. soruce code)	1	harmonise to reflect license specified in project rules	none

---

Modified by andreas.junghanns on 5 May 2016 12:14 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none
ME	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)
ME, CS	In the current 1.0 specification, nothing is stated about that and some FMU define aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none
CS	Appendix B speculates about future versions.	1	remove Appendix B	none

---

Modified by andreas.junghanns on 5 May 2016 12:12 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none
ME, CS	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)
ME, CS	In the current 1.0 specification, nothing is stated about that and some FMU define aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none
CS	Appendix B speculates about future versions.	1	remove Appendix B	none

---

Modified by andreas.junghanns on 5 May 2016 10:48 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it: the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file? or just the path to the FMU file itself?	2	The text now seems to mean the location of the FMU. Clarify.	potentially severe
ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none
ME, CS	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)
ME, CS	In the current 1.0 specification, nothing is stated about that and some FMU define aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none

---

Modified by andreas.junghanns on 5 May 2016 10:47 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =
CS	unclear meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it:

    the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file?
    or just the path to the FMU file itself? || 2 || The text now seems to mean the location of the FMU. Clarify. || potentially severe ||

ME, CS	is it allowed to call the get/set functions with zero-length array arguments? At least two possibilities: it is allowed, and the function returns fmiOK; it is not allowed, and the function returns fmiDiscard.	1	I think we should be liberal and allow zero-length	none
CS	remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.	1	agreed, maybe we should also cleanup the appendix	none
ME, CS	fix the issue #74 about displayUnit.	2	The ticket #74 suggests the obvious fixes	none (most people must have implemented that correctly)
ME, CS	In the current 1.0 specification, nothing is stated about that and some FMU define aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.	3	forbid aliased start value.	none - improving this only removes ambiguity
ME, CS	allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.	2	small sentence should do the trick	none - this is what most implementations already do, we just sanction standard practise
ME	the definition ti = limeps?0 ti+eps from page 11 of document (mathematical description of Model Exchange, section 2.1) is meaningless.	1	remove it	none
ME	fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.	1	add this in the function description	none
ME	it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected	3	we should clarify that the importer has to call fmiEventUpdate explicitly	small, if some FMUs handle this themselves now, calling the fmiEventUpdate a second time should not hurt
ME, CS	we need to clarify the license conditions	1	simply add a reference to the CCLA in the document	none

---

Reported by andreas.junghanns on 3 Mar 2016 16:34 UTC
This ticket is a collection of clarification needed in case we decide to have a maintenance-release of FMI 1.0.

Please add here in the ticket description your points:

• add reference to CCLA
• call/don't call eventUpdate() on discrete variable change

---

Migrated-From: https://trac.fmi-standard.org/ticket/370

[modelica-trac-importer]

Modified by andreas.junghanns on 3 Mar 2016 16:37 UTC

[modelica-trac-importer]

Comment by aviel on 14 Mar 2016 10:27 UTC
Some clarifications proposed for the 1.0.1 maintenance release of the two specifications. CS (resp. ME) means that it applies only to Co-simulation (resp. Model Exchange) or both:

• CS: clarify the meaning of the fmuLocation argument of the fmiInstantiateSlave function. Is it:
  • the path to a directory that contains the extracted (unzipped) content of the FMU, with exactly the same directory hierarchy as in the zip file?
  • or just the path to the FMU file itself?
• ME/CS: is it allowed to call the get/set functions with zero-length array arguments? At least two posibilities:
  • it is allowed, and the function returns fmiOK;
  • it is not allowed, and the function returns fmiDiscard.
• CS: remove the canSignalEvents from the list of co-simulation capability flags since there is no way for the FMU to do this.
• ME/CS: fix the issue Error in displayUnit definition in FMI 1.0 standard #74 about displayUnit.
• ME/CS: forbid aliased start value. In the current 1.0 specification, nothing is stated about that and some FMU define aliased variables that have different start values. This yields nondeterministic behaviour at initialization. Only one start value should be allowed for each group of aliased variables.
• ME/CS: allow additional DLLs or shared libraries in the binaries/ subdirectory that can be loaded by the FMU main DLL or shared library.
• ME: remove the definition t_i = lim_eps->0 t_i+eps from page 11 of document (mathematical description of Model Exchange, section 2.1), since it is meaningless.
• ME: fmiGetStateValueReferences must return either fmiUndefinedValueReference or a value reference of a variable which is declared in the XML model description.

[modelica-trac-importer]

Comment by andreas.junghanns on 14 Mar 2016 14:45 UTC
Karl, any additions?

[modelica-trac-importer]

Comment by anonymous on 21 Mar 2016 14:52 UTC
How can a 1.0.1 release be adressed in the modeldescription.xml?
Tools supporting FMI 1.0 will not know how to deal with a "1.0.1" version number

[modelica-trac-importer]

Comment by andreas.junghanns on 3 May 2016 10:50 UTC
Replying to [comment:4 anonymous]:

How can a 1.0.1 release be adressed in the modeldescription.xml?
Tools supporting FMI 1.0 will not know how to deal with a "1.0.1" version number

If we want to stay compatible with version 1.0, I think we have to keep "1.0" as the version string.
Otherwise we have to return "1.0.1" and require that the importing tools know how to check version strings.

[modelica-trac-importer]

Modified by andreas.junghanns on 5 May 2016 10:47 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 5 May 2016 10:48 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 5 May 2016 10:52 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 5 May 2016 12:12 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 5 May 2016 12:14 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 6 May 2016 08:58 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 6 May 2016 11:43 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 6 May 2016 11:47 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 6 May 2016 11:55 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 6 May 2016 12:46 UTC

[modelica-trac-importer]

Comment by andreas.junghanns on 6 May 2016 13:05 UTC
I think I finished with (almost) all the obvious changes listed in the ticket.
Please proof-read and fix or let me know what we should discuss.

Antoine - I did not find the formula you think should be deleted (and now am running out of time). Could you please fix this yourself? Thank you!

[modelica-trac-importer]

Modified by andreas.junghanns on 2 Aug 2016 12:56 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 2 Aug 2016 13:07 UTC

[modelica-trac-importer]

Comment by pierre.mai on 28 Sep 2016 09:54 UTC

Another Issue: Leading prefixes on zip archive members

While I think the specification is clear on this, in practice we have encountered a number of implementations, which generate FMUs where the ZIP Archive contains entries of the form "./modelDescription.xml", "./binaries/win32/myfmu.dll", etc. This can happen for certain zip archive utilities if the paths are specified in a certain way, especially under Unix/Linux. Not all importing implementations will support FMUs like this, especially when using their own unzipping implementations, to e.g. read the modelDescription.xml on-the-fly without decompressing the whole archive. In order to avoid this from happening, it might be useful to add a clarifying sentence to the specification, indicating that no leading prefixes, not even "./", are allowed in the zip archive entries.

Proposed table entry:

= variant effected =	= description =	= severity, 1-low, 3-high =	= suggested fix =	= compatibility issues for the suggested fix =	= status =
ME, CS	Clarify that leading prefixes like "./" are not allowed in zip archive members.	2	Clarify.	Minor.

[modelica-trac-importer]

Comment by pierre.mai on 28 Sep 2016 10:05 UTC
With regards to the suggested fix for the fmuLocation parameter, I'm not certain that this fix is very helpful: Current practice seems to indicate that very many implementations interpreted the document to mean the location of the unzipped directory, as this was also more in keeping with the various FMI 2.0 drafts and release candidates, and also more useful for the FMU when trying to locate included resources.

So fixing it in this form would actually require implementations to change to a behavior that was not very helpful in the first place (FMUs would need to do their own unzipping into a temporary directory to access resources) and also differs markedly from FMI 2.0 and current behavior for those implementations.

IMHO it would be better to replace the section with the FMI 2.0 section (which also contains fixes for the URI schema vs. protocol vs. authority confusion in the 1.0 text), potentially changed to let the URI point to the root of the unzipped directory and not the resources directory, thereby matching current practice for quite a number of implementations.

If that is considered too major a change, then I'd consider not clarifying at all, since this clarification means breaking current practice while not enabling any new practice (in practice binary FMUs would probably perform resource lookup mostly via DLL/SO-relative lookups like they do for FMI 1.0 ME in any case, and will need to continue to do so).

[modelica-trac-importer]

Comment by andreas.junghanns on 28 Sep 2016 10:21 UTC
Replying to [comment:19 pierre.mai]:

== Another Issue: Leading prefixes on zip archive members

While I think the specification is clear on this, in practice we have encountered a number of implementations, which generate FMUs where the ZIP Archive contains entries of the form "./modelDescription.xml", "./binaries/win32/myfmu.dll", etc. This can happen for certain zip archive utilities if the paths are specified in a certain way, especially under Unix/Linux. Not all importing implementations will support FMUs like this, especially when using their own unzipping implementations, to e.g. read the modelDescription.xml on-the-fly without decompressing the whole archive. In order to avoid this from happening, it might be useful to add a clarifying sentence to the specification, indicating that no leading prefixes, not even "./", are allowed in the zip archive entries.

Proposed table entry:

||= variant effected =||= description =||= severity, 1-low, 3-high =||= suggested fix =||= compatibility issues for the suggested fix =||= status =||
|| ME, CS || Clarify that leading prefixes like "./" are not allowed in zip archive members. || 2 || Clarify. || Minor. || ||

With a strict formulation like that, we are - I think - breaking forward compatibility: Some FMUs perfectly legal in 1.0 will not be legal in 1.0.1. I think this would be against our development rules.
We should formulate this in 1.0.1 as a recommendation/clarification and make sure we add this restriction into future versions of the standard.
Please confirm my take on this.

[modelica-trac-importer]

Comment by aviel on 4 Oct 2016 09:28 UTC
In the Model Exchange specification, page 10, it seems there is an issue with the definition of the "input signal" related to "time event". A footnote states that it is defined below, but the rest of the document defines "input variables", whereas in the context of time events, "input signal" more specifically refer to "discrete input variable". The text could be changed to:
... or by the environment of the FMU due to a discontinuous change of a discrete input variable ...
and the footnote to
Discrete input variables are defined below

[modelica-trac-importer]

Comment by andreas.junghanns on 4 Oct 2016 09:35 UTC
Replying to [comment:22 aviel]:

In the Model Exchange specification, page 10, it seems there is an issue with the definition of the "input signal" related to "time event". A footnote states that it is defined below, but the rest of the document defines "input variables", whereas in the context of time events, "input signal" more specifically refer to "discrete input variable". The text could be changed to:
... or by the environment of the FMU due to a discontinuous change of a discrete input variable ...
and the footnote to
Discrete input variables are defined below

Hi Antoine: Please feel free to introduce these changes to the 1.0.1 document.

[modelica-trac-importer]

Comment by pierre.mai on 6 Oct 2016 23:01 UTC
Replying to [comment:21 andreas.junghanns]:

Replying to [comment:19 pierre.mai]:

||= variant effected =||= description =||= severity, 1-low, 3-high =||= suggested fix =||= compatibility issues for the suggested fix =||= status =||
|| ME, CS || Clarify that leading prefixes like "./" are not allowed in zip archive members. || 2 || Clarify. || Minor. || ||

With a strict formulation like that, we are - I think - breaking forward compatibility: Some FMUs perfectly legal in 1.0 will not be legal in 1.0.1. I think this would be against our development rules.
We should formulate this in 1.0.1 as a recommendation/clarification and make sure we add this restriction into future versions of the standard.
Please confirm my take on this.

From my point of view, those FMUs were already illegal in 1.0: The standard clearly states the directory structure of the FMU, and including additional structure components like "./" (non-portable, btw., since the interpretation of . as current directory is not specified anywhere in the ZIP APPNOTE specification) is not allowed anywhere. Or to put it another way, if having "./modelDescription.xml" entries in the ZIP archive is allowed, then what makes having "../modelDescription.xml", or "abc/modelDescription.xml" not allowed?

So for me this is a pure clarification of something that the standard already specifies fairly clearly (but that can be easily violated inadvertently by using some common zip utilities with wrong arguments). However if the general agreement of everyone is that these kinds of FMUs were actually legal to begin with -- but then again, what prevents other prefixes from being valid -- I could certainly live with a softer formulation.

[modelica-trac-importer]

Comment by andreas.junghanns on 7 Oct 2016 09:28 UTC
I would go as far as declaring the "./" prefix as a nuisance. But illegal?
Since most FMUs are platform dependent, because they contain binaries inside that are platform dependent, one could argue that that platform also defines the semantics of the "./" prefix. That is, if one would argue that "./" requires specification as all systems that I know have a common interpretation of that prefix.

The case of "./" seems also quite different from "../" and other clear directory prefixes as these clearly do change the location of the files, by any of the systems I know and are clearly not allowed by the standard (and little argument seems needed to agree here, I think).

If we want to be clear in the standard, we would also have to be clear on similar non-canonical path variants, e.g. "binaries/win32/../win64/" (even if I have no idea how to place this into a zip file).

I strongly believe that we should just clarify the expectations, but not outlaw liberal interpretation if they are consistent with most system interpretations.

I suggest the following wording:

Paths in the .zip file should be canonical.

[modelica-trac-importer]

Comment by pierre.mai on 7 Oct 2016 20:44 UTC
Replying to [comment:25 andreas.junghanns]:

I would go as far as declaring the "./" prefix as a nuisance. But illegal?

Legal/Illegal is probably not a good dichotomy to apply here (since the FMI standard oviously has no legal impact by itself), so let me phrase it this way: Is there anything in the 1.0 standard(s) that can be used to argue that an FMU importing implementation is required to support such FMUs? If there is not, then, since the whole point of FMI is as an interchange standard, exporting implementations should not produce such FMUs. Or in the terms of e.g. the C standard, "." in zip archive entries currently would be implicitly undefined behavior, the clarification would make it explicitly undefined behavior.

If there is something in the 1.0 standard(s) that can be used to argue that such FMUs must be supported, then I think this needs to be clarified, since otherwise importing FMUs might not support such FMUs (the fact that currently many implementations just use infozip or 7-zip internally in such a way that makes . transparent to the calling program on many platforms is just a happy accident that obscures the problem but cannot really be relied upon since ZIP implementations are not required to handle . or .. in this way, and there is an obvious security aspect to supporting .. that can lead to non-support).

The case of "./" seems also quite different from "../" and other clear directory prefixes as these clearly do change the location of the files, by any of the systems I know and are clearly not allowed by the standard (and little argument seems needed to agree here, I think).

Since neither the FMU standard nor the implicitly referenced ZIP APPNOTE give semantics for either . or .. it seems to me that they are identical from the POV of the standard (i.e. both . and .. are just simple text with no attached semantics).

If we want to be clear in the standard, we would also have to be clear on similar non-canonical path variants, e.g. "binaries/win32/../win64/" (even if I have no idea how to place this into a zip file).

I agree that it would be a good idea to include such variants in the clarification (as an aside: Using e.g. infozip this can be accomplished easily: zip my.fmu binaries/win32/../win64/my.dll for example creates such a zip archive).

I strongly believe that we should just clarify the expectations, but not outlaw liberal interpretation if they are consistent with most system interpretations.

Unless there is wording in the standard to require importing implementations to support FMUs containing such entries, I do not think that exporting implementations can rely on it. And since there is really no benefit in using non-canonical names, I don't see the point. Obviously importing implementations are (and should be) free to support such FMUs if they so wish...

I suggest the following wording:

Paths in the .zip file should be canonical.

I can certainly live with this wording, if that is more amenable to consensous, though it should be noted that the standard currently does not as far as I can see provide a definition of what canonical means in this context...

[modelica-trac-importer]

Comment by andreas.junghanns on 7 Oct 2016 22:17 UTC
The FMI development process states that bug-fix releases must be forward and backward compatible. If we add a restriction to 1.0.1 that would outlaw a 1.0-compliant FMU, we would break that rule.

That means: We can argue a lot about what we should have done, it does not help here: If something was not explicitly forbidden, we cannot start forbidding it in a bug-fix release.

For exporters it is a good idea to be as clean as possible following the standard - adding clarifications helps that. For importers, it is a quality of implementation issue to handle even liberal interpretations of the standard.
And we need to remember these issues and make sure newer versions of the standard will be as strict as possible on all those points.

About "canonical": I think we can reasonably rely on definitions that can be found (consistently) with web searches - no need to define that in the standard.

[modelica-trac-importer]

Comment by pierre.mai on 8 Oct 2016 13:15 UTC
I'm replying in more detail since this goes above the issue at hand, imho...

Replying to [comment:27 andreas.junghanns]:

The FMI development process states that bug-fix releases must be forward and backward compatible. If we add a restriction to 1.0.1 that would outlaw a 1.0-compliant FMU, we would break that rule.

That is not something I am disputing. And I'm not arguing what should have been done, I'm arguing about what the standard actually states and means. While the underlying issue is not that significant, the same issues apply e.g. to the fix for the fmuLocation parameter issue... I.e. since the standard was unclear, it is allowed that FMUs relied on the URI pointing to the unpacked archive, hence we cannot now forbid this?

That means: We can argue a lot about what we should have done, it does not help here: If something was not explicitly forbidden, we cannot start forbidding it in a bug-fix release.

This blanket statement makes me somewhat unsure of the semantics of the FMI standard: If everything that is not explicitly forbidden (and is not even implicitly allowed) is allowed, and hence must be supported by implementations (which is what "allowed" in practice means, because of course everyone is allowed to do whatever they please unless they want it to actually work across implementations), then this is the reverse of any language or interchange standard that I have ever worked on or implemented: Usually only behaviour that is explicitly or at least implicitly specified is defined behavior, and only that is behavior that implementations are required to support. Or in other words: What does compliance to the FMI standard for both exporters and importers actually mean: If everything that is not explicitly forbidden is "allowed", then compliance for importers is probably not achievable (and probably not achievable for exporters, too, for issues cutting in the other direction).

For exporters it is a good idea to be as clean as possible following the standard - adding clarifications helps that. For importers, it is a quality of implementation issue to handle even liberal interpretations of the standard.

It cannot be a quality of implementation issue if that is actually standard allowed, non-optional behavior, it would be a compliance issue. Otherwise compliance has no operative meaning (i.e. two implementations could both be compliant yet unable to exchange FMUs that do not use any optional features).

So if the accepted position is that a FMU using ./ prefixes and other non-canonical (FWIW) paths in the zip archive is standard compliant (i.e. operating under a valid interpretation of the standard), then I think the clarification needs to point this out so that importing implementations do in fact support these FMUs, because they would otherwise not be standard compliant.

About "canonical": I think we can reasonably rely on definitions that can be found (consistently) with web searches - no need to define that in the standard.

I'd at least spell out the common cases of concern, since path canonicalization also usually includes case and Unicode canonicalization and differs between OSes to a large degree and those are not issues we are concerned with.

[modelica-trac-importer]

Modified by andreas.junghanns on 26 Jan 2017 09:56 UTC

[modelica-trac-importer]

Modified by andreas.junghanns on 26 Jan 2017 14:11 UTC

[modelica-trac-importer]

Comment by karl.wernersson on 10 May 2017 10:31 UTC
Hi
I have gone through the changes and I only have one remark.

I don’t like the changes regarding

it is unclear if the importer has to call fmiEventUpdate after a discrete variable changed, or if this should be auto detected

In the V 1.0 states (regarding what is an event)

1. At a predefined time instant ti = Tnext(ti-1) that was defined at the previous event instant ti-1 either by the FMU, or by the environment of the FMU due to a discontinuous change of a continuous input signal variable or a change of a discreteI input uj at ti. Such an event is called time event.

I also has the following false footnote Input signals are defined below.

In V 1.0.1 the part that considers discrete changed inputs and the footnote are removed so it now states

1. At a predefined time instant ti = Tnext(ti-1) that was defined at the previous event instant ti-1. Such an event is called time event.

So we have removed the reference to discreet inputs in the event section.
To make up for this a new part has been added to the function definition of fmiEventUpdate

fmiEventUpdate() has to be called from the simulation environment after discrete input variables where changed or continuous inputs where changed discontinuously.

I don’t like this change because

1. Discrete input changes are no longer defined as events
2. In the function definition we suddenly defines one case when it has to be called but not the other cases
3. We should probably update the state chart if we do this change
4. Although explicitly stated to call event update for inputs the fragmentation of the event handling information makes the text more confusing
   If we really want to be clear we should define external event from fmi2

1. The environment of the FMU triggers an event at the current time instant because at least one
discrete-time input changes its value, a continuous-time input has a discontinuous change, or a
tunable parameter changes its value. Such an event is called external event. [Note, if an FMU A is discontinuous at this time instant. It is therefore adviceable to trigger an external event for B at this
time instant too, if an output of A is connected to B. This means to call fmi2EnterEventMode on B.]
All the following events are internal events.
This might propagate to other parts of the document and requires an update of the state chart

My opinion is that the current text (minus the footnote) is good enough but I have a proposed change to make it slighly better.
My proposal is, remove the bad footnote, don’t have the explicit statement in the function definition and update the original text in the following way
1. At a predefined time instant ti = Tnext(ti-1) that was defined at the previous event instant ti-1 by the FMU. By the environment of the FMU due to a discontinuous change of a continuous input ucj at ti or a change of a discrete input udj at ti. Such an event is called time event.

I will update the source at the end of this week if no one protests.
/Kalle

[modelica-trac-importer]

Comment by andreas.junghanns on 29 May 2017 17:32 UTC
Karl improved the document significantly by adding the clarifications w.r.t. the fmiEventUpdate() function at a better place. I am happy with this improvement. Please give these changes a final read and be prepared to release version 1.0.1 during the next steering committee meeting (I think in early July).

[modelica-trac-importer]

Comment by aviel on 12 Jun 2017 16:36 UTC
According to the state machine of calling sequence (section 2.9, p.22) the fmiGetContinuousStates function can be called in the instantiated state. In the section 2.7, "Evaluation of Model Equations", p. 26, the definition of the fmiGetContinuousStates says nothing about what is expected from the FMU when this function is called in the instantiated state. The table 1 of the mathematical description (section 2.1, p. 11) defines an equation for initialization, depending on x₀, that is defined as the "initial states". However, it seems that in some cases this is not the actual initial value of the state vector, that is defined by the initialization process (i.e. after the call to the fmiInitialize function).
There is a need to clarify the semantics of both the call to fmiGetContinuousStates before initialization, and the meaning of x₀. At least two alternatives can be proposed:

• either forbid a call to the fmiGetContinuousStates before initialization (since it does not make sense, the actual initial value being provided after initialization)
• or clearly states the fmiGetContinuousStates function returns the x₀ value, that is defined as a default or guess value for the initialization of the continuous-time state variables. This value is stored in the fmiInstantiateModel function, and is not known in the XML.
  Moreover, the meaning of x₀ in the third statement of p. 26 should be changed from "initial states" to "default values or guess values of the initial states".

[modelica-trac-importer]

Comment by aviel on 14 Jun 2017 14:14 UTC
The state machine of calling sequence, section 2.9, of the FMI for Model Exchange 1.0.1 specification was changed. In instantiated mode, it is only allowed to get the value of the Real, Integer, Boolean, and String scalar variables that have a start value defined (this corresponds to the fmiGetINS keyword on figure 4).

[modelica-trac-importer]

Comment by efredriksson on 20 Jun 2017 16:28 UTC
From Modelon we don't have any problem with forbidding fmiGetContinuousStates calls before initialization (or define an expected behavior).

[modelica-trac-importer]

Comment by aviel on 13 Jul 2017 07:23 UTC
New specification documents for 1.0.1 released July 10th, 2017.