Logging in ME interface about fmi-standard HOT 10 CLOSED

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:

1. 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.

2. 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:

1. 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.

2. 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.