Logging

[RemDelaporteMathurin]

Sometimes it is hard to know what FESTIM is doing and when it's failing.

We have some print statements here and there but a lot is lost in between.

We would need a more robust way of logging what happens, with different logging levels (just like fenics has a log system).

I believe fenics uses this.

I think we can do something similar.

[KulaginVladimir]

@RemDelaporteMathurin Do you want to implement all log_levels of the logger or a reduced variant?

I also think that some re-work would help in the case of parallel computing, As I observe, the current info messages are printed by each core that I provide with mpirun -np.

[RemDelaporteMathurin]

What do you think? Would it be better to use the fenics logging system or rather make our own with maybe different levels?

[KulaginVladimir]

Adapting the fenics log system seems to be a good idea. We can override some of fenics methods similar to Newton solver.

Though, it's a tough question. I think we can re-create log levels 50, 40, 30, and probably 20, whereas 16, 13, 10 - I haven't tested/used a lot yet.

At least, I think that festim and fenics errors/warnings should be clearly divided, the messages should be appropriately spread across cores during parallel computing, and tracing of festim processes is needed

[RemDelaporteMathurin]

Though, it's a tough question. I think we can re-create log levels 50, 40, 30, and probably 20, whereas 16, 13, 10 - I haven't tested/used a lot yet.

We don't have to recreate all the log levels. I think we can start with just a binary system like INFO and NOTHING. And we will figure out later if we need to add levels

At least, I think that festim and fenics errors/warnings should be clearly divided, the messages should be appropriately spread across cores during parallel computing, and tracing of festim processes is needed

By clearly divided do you mean that we shouldn't use fenics' log system?

[KulaginVladimir]

By clearly divided do you mean that we shouldn't use fenics' log system?

I meant a dedicated message as:

*** -------------------------------------------------------------------------
*** FESTIM encountered an error. If you are not able to resolve this issue
*** using the information listed below, you can ask for help at
***
***     https://festim.discourse.group/
***
*** Remember to include the error message listed below and, if possible,
*** include a *minimal* running example to reproduce the error.
***
*** -------------------------------------------------------------------------
*** Error:   Error.
*** Reason:  Reason.
*** Where:   Where.
*** Process: Process.
*** -------------------------------------------------------------------------

This also implies that dolfin_error does not suit, I guess

[RemDelaporteMathurin]

Yes we don't want to make our own errors like this. But what we want is for users to have enough information about what is going on (eg. Defining boundary conditions, defining source terms, solving nonlinear problem for solubility, etc. ) but with the possibility to disable it if needed.

[KulaginVladimir]

Are there any thoughts on how FESTIM log_levels should be related to fenics log_levels?

[RemDelaporteMathurin]

I think we need to sit down and: 1) clearly define what we want to read. For instance: know if the stepsize is shrunk or relaxed, know if a field is being exported, etc. 2) for each item that we print, we need to decide what log level (i guess many of them would be INFO)?

I think we can simply use the fenics logging system instead of making another one, for the sake of simplicity.