loops / tbc code has time

[kostrzewa]

The focus right now should be to make sure that the connected part for the scalar ff works so we can get started.

Since this now exists, but is untested, the other things are not urgent right now. I would prefer if we could feature-freeze the code-base for a moment to reflect clearly on what else is required in tmLQCD for the TBC / loops, if anything.

At the same time, I would now like to perform the necessary cross-checks.

I would also like to merge the build system, if you want that in there. If not, then we have to construct Makefiles for QBIG and PizDaint. I would much prefer to have the build system there because it makes getting up and running easier, at least in principle. In particular, it makes writing tests trivial, which is always a good thing...

[marcuspetschlies]

Far as I understood, as per latest call, loops are urgent for comparison with GPU code;
Yes, testing would be great.
I will look at the build system hopefully middle of next week, before I won't have time. If need be I can provide Makefiles.

[marcuspetschlies]

"what else is required in tmLQCD for the TBC / loops"
As I had remarked in the beginning, I would find it rather comfortable, if tmLQCD could use a gauge field provided by the calling package. Given that tmLQCD is used a layer to call inverter packages like DDalphaAMG or QUDA, that would make sense to me. Same for further parameters. That would make it more versatile.
Also the parameter structs from e.g. QUDA could be made directly accessible in the interface.

But as for the tbc, I'd be happy to use a now available solution, that works, even if it changed some time in the future and needs some adaption for the inverter call.

[kostrzewa]

As I had remarked in the beginning, I would find it rather comfortable, if tmLQCD could use a gauge field provided by the calling package

Yes, we should definitely implement that. The only problem is that all the gauge copies and meta-information have to be updated so it's not as easy as just overwriting the gauge field behind the pointer.

Same for further parameters. That would make it more versatile.

I agree, but this is difficult to achieve in general unless one takes apart the input file reader completely and separates it into a reader and many setter routines (basically constructors). Then, the constructors can be called externally to set up any parameter one desires.

But as for the tbc, I'd be happy to use a now available solution, that works, even if it changed some time in the future and needs some adaption for the inverter call.

The solution was limited to the QUDA-direct call. It has now been superseded by a general solution as discussed in etmc/tmLQCD#449 and previously here etmc/tmLQCD#446

[kostrzewa]

As I had remarked in the beginning, I would find it rather comfortable, if tmLQCD could use a gauge field provided by the calling package

Yes, we should definitely implement that. The only problem is that all the gauge copies and meta-information have to be updated so it's not as easy as just overwriting the gauge field behind the pointer.

Keep in mind, however, that this would not include being able to set boundary conditions externally by phase-multiplications. This is because the tmLQCD-native Dirac operators do the actual phase-multiplication, as does the QPhiX Dirac operator with gauge compression. The QUDA Dirac operator, on the other hand, is passed a phase-multiplied gauge field.