On 14. Dec. 2014 at 21:56, Joakim Hove wrote:
The log levels, i.e. Warning, Error and so on should be dynamic;
and each backend should have it’s own loglevel.
On 15. Dec. 2014 at 10:18, Atgeirr Rasmussen wrote:
If the way to specify a Warning changes with the backend then
there is no polymorphism here, so I fail to see how that could be
done.
On 15. Dec. 2014 at 10:19, Roland Kaufmann wrote:
With this you mean that the event generators still create events
with a fixed number of levels, but that each backend have its own
filter?
On 15. Dec. 2014 at 11:12, Joakim Hove wrote:
default will of course be built in, but it should be possible from
clientcode to say something like:
size_t message_id = Log::addMessageType();
Log::addMessage(message_id , “This message is tagged with the new
message_id tag”);
In a way I share Atgeirr's sentiments; I don't quite see how the modules
can communicate which events they generate straightforwardly.
One alternative is of course that: (a) modules register different types
of events with the logging module using an identifier, which is practice
becomes a string, (b) each backend reports its willingness to log with
the logging module identifying itself with something which again
probably will turn out to be a string name, and (c) there exists a
user-given mapping with some sensible default that tells the logging
module which events can be sent to which backends. It is this m-to-n
mapping I fear can get messy for anything but non-trivial cases.
>> The logging facility should not be used for all communication with
>> the user, only warnings/errors etc. I think that regular output
>> should not be a part of this, even though that prompts more
> Why not – that is my ambition? At least in a production setting the
> simulator will be run in queue system and all output must/will be
> redirected to a file. By having multiple backends we can send
> messages many places, including stdout with a common use pattern in
At least that enables ad-hoc setups such as: if there is more than three
convergence problems in a row, then write a restart and send an email
before aborting.
--
Roland.
_______________________________________________
Opm mailing list
[email protected]
http://www.opm-project.org/mailman/listinfo/opm
