Monomials are referred to by their C++ classes and not the user's monomial_id

[martin-ueding]

While going through the log files (solver, forces), the monomials are all referred to by their C++ classes. This makes sense from the solver or force computation code as it does not care what physics the user wants to describe with those. In the N_f = 2 + 1 simulations that I run with clover term, there are two log-det terms. From the output of the solvers and the force monitor I cannot tell which block belongs to which monomial (light log-det or strange log-det):

<elem>
  <EvenOddPrecLogDetEvenEvenMonomial>
    <S>-1078819.68276751</S>
  </EvenOddPrecLogDetEvenEvenMonomial>
</elem>

<EvenOddPrecLogDetEvenEvenMonomial>
  <Forces>
    <F_sq_per_direction>5.06968661479971e-09 5.17655652393928e-09 5.15228167670478e-09 5.09518950267906e-09</F_sq_per_direction>
    <F_avg_per_direction>6.77851025083714e-05 6.83683866616008e-05 6.82822311070698e-05 6.78154167053338e-05</F_avg_per_direction>
    <F_max_per_direction>0.000193982091162627 0.000175413372051822 0.00017905863116576 0.000194948531090264</F_max_per_direction>
    <F_sq>5.12342857953071e-09</F_sq>
    <F_avg>6.80627842455939e-05</F_avg>
    <F_max>0.000194948531090264</F_max>
  </Forces>
</EvenOddPrecLogDetEvenEvenMonomial>

In the flat text output, there seems to be no way to connect the iterations of the solvers to the monomial. It would be really interesting to know the relative iteration counts and residuals for two similar monomials (two Hasenbusch terms on different time scales for instance).

Looking through the code I saw that the monomials themselves do not know their monomial_id, only the singleton map knows those. So I thought that one could attach the name to the base class of the monomials. However, the XML emission code is redundant for every monomial type such that it would mean changes at a lot of places in order to get this done consistently.

Is there perhaps an easier way to make this more end-user friendly?