Comments (10)
Modified by andreas on 25 Nov 2009 20:08 UTC
from fmi-standard.
Comment by anonymous on 4 Dec 2009 09:01 UTC
The suggestion improves the logging, in my opinion, so I second it.
I think we had agreed in Munich to drop the category.
If additional information is needed to be send to the user,
it can be part of the (structured) message.
The reasoning was (if I remember correctly), that as long as we
don't assign fixed semantics to a catalog of categories,
the simulation environment cannot use this for anything except
filtering, which can be done just as well on the message string.
from fmi-standard.
Comment by Martin Otter on 6 Dec 2009 18:00 UTC
For me the proposal with meLogLevel is simpler, clearer and more powerful as the current approach. As remarked in the previous respond, a tool can combine this with a tool specific filtering of a keyword in the message and "category" in the logger should be removed.
I wonder why "meStatus = meWarning" is needed? The calling environment can do nothing with it and has to handle it in the same way as "meStatus = meOK". I would propose to change meStatus to:
typedef enum {
meOK, // continue
meDiscard, // reduce step-size and try again
meError, // stop simulation and free model instance
meFatal // stop simulation and free all model instances
} meStatus.
The meLogLevel should be extended with meDiscard, to have a complete mapping to meStatus:
typedef enum {
meLogTrace,
meLogDebug,
meLogInfo,
meLogWarning,
meLogDiscard,
meLogError,
meLogFatal
} meLogLevel.
from fmi-standard.
Comment by peter.nilsson on 7 Dec 2009 11:30 UTC
I wonder why "meStatus = meWarning" is needed?
Since the necessary logging is expected by the FMI it is somewhat redundant. One reason for keeping it is that it gives the caller a possibility to log something useful in case it does not want to rely on the FMI logging. I have not strong opinion here though.
The meLogLevel should be extended with meDiscard, to have a complete mapping to meStatus:
My intention with meLogLevel was to keep it free from specific errors and decopupled from meStatus since the meLogLevel needs to be strictly ordered while the meStatus should not have this restriction. For flexibility, the mapping from meStatus to meLogLevel should to be determined from context, although most mapping, e.g. meFatal - meLogFatal is typically static.
In particular, meLogDiscard is not necessarily more severe than meLogWarning and thus breaks the strict ordering in meLogLevel. Instead, meDiscard should normally map to meLogWarning.
from fmi-standard.
Comment by aviel on 7 Dec 2009 14:51 UTC
I wonder if the #<Type><ValueReference#>
variable referencing mechanism in the logger function described in section 2.4 is really useful? For my point of view, this is the model responsability to associate a variable name with a value reference, and not the simulator responsability.
from fmi-standard.
Comment by otter on 7 Dec 2009 16:35 UTC
Issue 1: Is #<Type><!ValueReference?>#
needed, since the model should provided the variable name here.
Answer: Potentially this means that all variable names (ScalarVariableName) would have to be stored in the model and this is what we want to avoid with the xml-file. So, there will be models that do no store any variable name in the C-functions and then only the ValueReference is available and then the environment has to insert the ScalarVariableName from the xml file.
Issue 2: Proposal to have a log-level
Answer: Hans, Hilding, Peter (N.) and myself had a phone discussion on this topic. The result is, to not change the definition now. In version 2 introduce the following:
-
Have a new element "LogCategory" in the xml-file which is a vector of strings. These strings represent the supported log-flags, like "logNonlinearEquations", "logEvents", etc.
-
Have a new function "setLogCategories" to set the categories that should be logged. The model can then only send messages of the defined category to the logger (so this is efficient).
The user would like to enable/disable a particular log-feature (like logging events, or logging solution of non-linear equations) and this is more flexible and easier to understand as a log level.
from fmi-standard.
Comment by otter on 14 Feb 2011 14:12 UTC
Decision at meeting on Feb. 8, 2011:
The last proposal is accepted:
-
Have a new element "LogCategory" in the xml-file which is a vector of strings. These strings represent the supported log-flags, like "logNonlinearEquations", "logEvents", etc.
-
Have a new function "setLogCategories" to set the categories that should be logged. The model can then only send messages of the defined category to the logger (so this is efficient).
Additionally, add a list of standardized default log categories
(e.g., logEvents
) to the specification. So if different tools log the "same thing", they use the same name. A tool is free to introduce other log category names.
from fmi-standard.
Comment by otter on 4 Apr 2011 17:16 UTC
Included in FMI 2.0 draft
from fmi-standard.
Modified by dietmarw on 19 Mar 2012 10:04 UTC
from fmi-standard.
Modified by dietmarw on 7 Sep 2012 10:18 UTC
from fmi-standard.
Related Issues (20)
- Bump Reference FMUs submodule to latest version prior to release
- Clarify meaning of DefaultExperiment.stepSize for Model Exchange HOT 1
- Define matching rule "none" in the base FMI standard HOT 1
- Recommend or demand reverse domain notation for TerminalKinds and VariableKinds?
- Backport #1940 to FMI 2.0
- Backport #1941 to FMI 2.0
- Add section on when (not) to use Scheduled Execution
- Clarify what to do if a tool cannot do init iteration, the tool should report that correctly in the modelDescription.xml
- Allow setFloat64() for continuous states in Event Mode if reinit = false
- Clarify which variables can be set in Continuous Time Mode HOT 1
- Formalize naming and capitalization conventions for variables, attributes, elements, and functions HOT 1
- Add statement to forbid changing the modelDescription.xml in v2.0.x Word/PDF document HOT 1
- Clarification on what is meant with " unique on each level" for the "name" attribute of a <Terminal> HOT 3
- Proposal to add the attribute "rotation" to <TerminalGraphicalRepresentation> HOT 2
- Proposal for standardizing `fmiModelDescription` interface HOT 3
- Array Dimensions are always local constants in the FMU HOT 1
- Define the term "reinitialization"
- Backport definition of reinitialization to FMI 2.0.x
- Optional elements of ModelDescription HOT 1
- Unify usage of "reverse domain name notation" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fmi-standard.