Pretty traces about dftk.jl

[mfherbst]

Oh wow that really looks awesome!

[GVigne]

I started to take a look at this, by trying to change the default callback. Although I have a MWE, I can't find a way to write a full code to solve the issue.
The problem is that the default callback (ScfDefaultCallback) prints the information which we give him without much structure. What I mean by that is that when using the default callback, it prints various values according to a set of given parameters info, which is updated at each iteration of the solver.
However, SolverTraces requires to first define the number and name of columns which need to be printed: I have not found a way to hide or skip some columns. So the solution I have is to define a column for all the values which could be printed, and fill only the ones which are intersting. I think a picture is in order:

As you can see here, I have not found a generic way to keep none, one or several of the columns Magnet, alpha and Diag, and have to print them all: some have default values (I put Inf there) and can be a bit ugly.
I am still investigating, but I wanted to see if you had any ideas or clues. I might reach out to the creator of SolverTraces to see if he has plans to add a way to hide some columns or values (or do it myself if he agrees).

Edit: I can always define a model for each possibility (one with only Magnet, one with only Diag...), and use the relevant one. This works, but that isn't very clean, as it comes to defining 8 models just to use one...

[antoine-levitt]

Hm, I wonder if this is not more trouble than it's worth, it looks like it's going to be more trouble trying to fit our custom printing into their framework than it's worth...

[GVigne]

That was also what I was considering. I can submit a pull request if you want to take a look at the code. But I feel like the current workflow is not that compatible with the actual version of SolverTraces, as it requires to know exactly what we want to print.
Another problem I encountered is with the step: you have to declare the maximum number of steps when creating a SolverTrace object in order to have those pretty [?/10] markers. However, in our case, it can be hard to know beforehand the exact number of iterations. And because of the way the SolverTrace object is defined (by using immutables structures), you can't change the maximum number of steps after creating an instance of SolverTrace.

[antoine-levitt]

OK let's not bother then. Thanks for looking into this!

[GVigne]

Yes, I think it is best. I have a functional code, but feel like it doesn't bring much -and since SolverTrace doesn't seem very flexible in our case, I think it could raise issues in the future if we want to display other type of information.