Interface changes made chroma incompatible with qphix/devel

[azrael417]

hello,

using the latest qphix/devel branch together with chroma causes the following issues:

/project/projectdirs/mpccc/tkurth/NESAP/USQCD/install/intel/qphix_knl/include/qphix/inv_richardson_multiprec.h(126): error: no instance of overloaded function "QPhiX::AbstractSolver<FT, V, S, compress12, num_flav>::operator() [with FT=float, V=16, S=8, compress12=true, num_flav=1]" matches the argument list
argument types are: (float (*const [1])[3][4][2][8], float (*const [1])[3][4][2][8], double, int, double, unsigned long, unsigned long, int, bool, int)
object type is: QPhiX::AbstractSolver<float, 16, 8, true, 1>
solver_inner(dx_inner,
^
/project/projectdirs/mpccc/tkurth/NESAP/USQCD/install/intel/qphix_knl/include/qphix/abs_solver.h(94): note: this candidate was rejected because arguments do not match
virtual void operator()(Spinor *x[num_flav],
^
/project/projectdirs/mpccc/tkurth/NESAP/USQCD/install/intel/qphix_knl/include/qphix/abs_solver.h(76): note: this candidate was rejected because arguments do not match
virtual void operator()(Spinor *x[num_flav],
^
/project/projectdirs/mpccc/tkurth/NESAP/USQCD/install/intel/qphix_knl/include/qphix/abs_solver.h(41): note: this candidate was rejected because arguments do not match
virtual void operator()(Spinor *x,

Additionally, some std:: scopes are not explicitly specified, causing issues after using namespace std was removed, e.g.

/project/projectdirs/mpccc/tkurth/NESAP/USQCD/src/chroma/lib/actions/ferm/invert/qphix/syssolver_mdagm_clover_qphix_iter_refine_w.h(506): error: identifier "endl" is undefined
QDPIO::cout << "QPHIX_MDAGM_SOLVER: total time: " << swatch.getTimeInSeconds() << " (sec)" << endl;

The commits are:
chroma: 0618847
qphix: aca7bb148deb7b2762372a76ef25002ce0c48551

Best Regards
Thorsten Kurth

[kostrzewa]

Oh dear... we were hoping to avoid that happening... @martin-ueding could we sit down and figure out what happened here?

[kostrzewa]

This is basically due to JeffersonLab/qphix@906f349, but it's a bit strange it even comes up. As far as I can tell the defaults should always go through without any changes: when the solver base class is created without an explicit template argument for num_flavour, it should automatically be the single flavour one.

[kostrzewa]

/project/projectdirs/mpccc/tkurth/NESAP/USQCD/src/chroma/lib/actions/ferm/invert/qphix/syssolver_mdagm_clover_qphix_iter_refine_w.h(506): error: identifier "endl" is undefined
QDPIO::cout << "QPHIX_MDAGM_SOLVER: total time: " << swatch.getTimeInSeconds() << " (sec)" << endl;

This is within Chroma though, it probably just worked by accident because one of the QPhiX headers contained using namespace std.

[martin-ueding]

I hope that the QPhiX master branch is still compatible with Chroma, such that users can get a working version, right?

The using namespace std in the QPhiX header was bad to start with, this needs to be fixed in Chroma. There one could just do using namespace std in the source files, if desired.

Are there no additional error messages? I will compile with GCC locally later on today (earliest is probably 15:00 +0200) and see what happens there. It seems there is some overload missing. Perhaps Chroma is using const at a point where I did not expect and the Intel compiler is having another T ** to T const *const * conversion issue. While I am at it, I might also fix the std:: issues in order to get a clean compile.

Going forward, perhaps we should somehow add Chroma to Travis CI in order to spot these problems earlier on? I did start some release criteria for QPhiX and I thought that it be sufficient that QPhiX master builds with Chroma and we might break the interface in the devel branch. Should we keep it at that or should we make devel stricter (if so, how and who does the checks)?

[martin-ueding]

There were some const missing, I have fixed that. So devel of Chroma and QPhiX now work for me. So you have to merge #27 in order to get rid of the namespace issues. Chroma compiles from scratch with that version, so I guess that it is good now.

[kostrzewa]

@martin-ueding Thanks for taking care of this! @azrael417 when you have a moment, could you confirm that the issue is resolved?