Closed abroxos closed 9 years ago
Hm ... good question.
Currently we have the option to abort a simulation run in the module by setting the sim status to failed. This would make it really simple, as a first go, to refine the status a bit more and simply return it from the executable.
With the file based solution, you have something more fancy in your had?
It is not only about error control. We also need some mechanism for status/progress updates. Currently they are written to the log file. "The fancy thing in my head:" We need some kind of status/progress/error communication between DynaMind instances and external programs (web-server starting DynaMind as new process). How should this communication look like ?
I suggest a status file containing: Timestamp, ProgressPercent, ModuleName, STATUS (failed, ok, ...), Message (String). But keep in mind this should be not a second log file. @leznik what do you think ?
So basically the log file but just cleaned up so it would be easier to parse? That seems to me like the simplest solution.
So do I.
Sounds good to me too, should the return code still be altered depending on the status? To me it would make sense, for a simple execution there would be no need to parse files.
Beside the usual error codes i would only add one more error code which is returned in case of a simulation/DynaMind model fail (and no program crash). More information is stored in the status file.
Maybe model fail should be even subdivided in e.g. no complete flow due to: missing input files/missing attributes/missing modules/false (outdated) module configuration …?
From: Michael Mair [mailto:notifications@github.com] Sent: Monday, December 15, 2014 2:17 PM To: iut-ibk/DynaMind-ToolBox Subject: Re: [DynaMind-ToolBox] Implement consistent error control management (Simulation fail/progress) (#248)
Beside the usual error codes i would only add one more error code which is returned in case of a simulation/DynaMind model fail (and no program crash). More information is stored in the status file.
— Reply to this email directly or view it on GitHubhttps://github.com/iut-ibk/DynaMind-ToolBox/issues/248#issuecomment-66992459.
That would be a straight forward thing to do and could be quite useful.
currently following module codes are supported
enum ModuleStatus
{
MOD_UNTOUCHED,
MOD_EXECUTION_OK,
MOD_EXECUTING,
MOD_EXECUTION_ERROR,
MOD_CHECK_OK,
MOD_CHECK_ERROR,
};
we could add, if this is useful
MOD_INIT_ERROR
MOD_PARAMTER_ERROR
Is everyone fine with following suggestion ?
Type | Syntax | Description |
---|---|---|
TIMESTAMP | [ddmmyyhhxxss] | |
dd......day (1-31) | ||
mm.....month (1-12) | ||
yy.......year (00-99) | ||
hh.......hour (0-23) | ||
xx.....minute (0-59) | ||
ss.......second (0-59) | ||
PERCENTCOMPLETED | [INT] | total percent of completed simulation (0-100) |
MODULENAME | [STRING] | User defined name of the module and if not available native module name |
STATUS | [INT] | Values from ModuleStatus enum |
MESSAGE | ["STRING"] | with arbitrary length |
EXAMPLE: 111114111111 20 AddNode 1 "Added 34 nodes"
Just to clarify, the status file is separate from the log file?
And I don't see how we get the message string in the above example
Yes it is NOT a log file. The message is for example a human readable string representation of the ModuleStatus enum. But if there is no need for that we can remove it.
Not sure if we really need a second file. We could just use the log file and a new flag that is called status and just change the existing line we spit out already form info to status (just need to add the percentage somewhere)?
STATUS Tue Dec 16 23:32:09 2014| running module 2/34 GDALGeometricAttributes 0a31de45-29c4-41a8-a4bf-c1eb34221b9d
But if the status file is easier it is fine with me as well
Skype meeting with @christianurich: Decision: We are going to implement https://github.com/iut-ibk/DynaMind-ToolBox/issues/248#issuecomment-67138438.
@attozeta: Please implement :thumbsup:
How should we implement that: 1) File based or 2) Return codes of executable 3) others
@leznik @csaf4370 @christianurich @attozeta