Improve user friendliness of the output of the @show of the energy_problem

[datejada]

What and Why

Fix significant digits and units in the timing and objective function.

Format the values of the timing and objective function

• objective function: Plain format (no scientific format). Instead of 3.35e3, it should be 3350
• timing: do not show "(in seconds)" -> format it to have in the meaningful format, e.g., 17ms

Possible Drawbacks

No response

Related Issues

No response

[greg-neustroev]

Since I was the one bothered by this, I assigned it to myself.

There is a default Date formatter, but its output is rather long:

julia> 123456789123456 |> Dates.Nanosecond |> Dates.CompoundPeriod |> Dates.canonicalize
1 day, 10 hours, 17 minutes, 36 seconds, 789 milliseconds, 123 microseconds, 456 nanoseconds

I'd rather have something like:

1d 10h 17m 36s 789ms 123μs 456ns

I looked at the existing packages that output time in this format (TimerOutputs.jl and BenchmarkTools.jl), and they both implement their own formatters. We can do the same, it's not hard to write a formatter like this. The question is, should this be a part of Tulipa or a separate thing (e.g., a micropackage with just a few pretty formatting tools). It's not really a part of TulipaEnergyModel per se, and I can see other libraries like TulipaPlots using the formatting tools later.

Or maybe I missed something and there exists a nice time formatting library we can use?

@abelsiqueira @suvayu thoughts?

[suvayu]

Most Tulipa* libraries will depend on TEM. So I wouldn't bother creating a separate package, because then to use it easily you would need to register it as well.

[abelsiqueira]

I'm in favour of not implementing anything new for this. Instead, maybe we change how we use the timing packages to benefit from their printing. If that doesn't work, we can check with, for instance, TimerOutputs, to see if it makes sense to export their pretty printing function.