I really don't want to introduce environment variables to CP2K. Adding a side-channel opens a can of worms. A calculation should be entirely specified by the input file.

So please add the keywords and sections you need to setup your tests.

Btw, I noticed that the mcl_log_1 files is pretty large. Any chance you could make it smaller?

Alternatively, we could also create a dedicated integration test like we did e.g. for i-PI.

Sure. In that case I'll have a look at what has been done for i-PI since controlling it through input wouldn't do it for me, as these variables are required at the very beginning of a run, before the input is actually read. An alternative solution on my side would be to compile MCL in a way that would define these values and which would serve solely for testing purposes.

Regarding the file size, I was trying to make it as small as possible, but because it contains electron density and external potential values on the grid, this is how far I managed to get. I can either make the finest grid even coarser or I'll try dropping some data that is not actually checked.
EDIT: If we'd go with a standalone test, with removing a few large chunks of data and a possible compression, I think I can get below 1MB, although I'm not sure how much below.

So, I managed to reduce the log file size to ~500 kB by removing the storage of data that weren't necessary for proper test run and also reducing the cutoffs and box size. The tested energy values are now far from being converged and possibly even unphysical, but I suppose it shouldn't matter too much for the test.

However, I'm still not sure what to do about the environment variable controls, since this is how the communication mechanism of the MCL library is controlled (see README) and unfortunately, it cannot be introduced in the CP2K input as these settings are already required right after the MPI
initialization.

The question is: would you like to refrain from introducing envvar support in do_regtest.py, because it might give an impression that this is a valid way of controlling CP2K, even though it is only used for external libraries? In that case, would it be okay if I implemented a specific type of a reg test in the script, or should we go for a standalone test? If it is the latter, I'm not sure how to approach this as it requires a specific build of CP2K (with MiMiC support), unlike the test for i-PI, in which i-PY is fairly independent (if I understand this correctly).

would you like to refrain from introducing envvar support in do_regtest.py, because it might give an impression that this is a valid way of controlling CP2K,

Yes exactly!

So, how about we sweep it under the rug here:

I hope that the current solution will do. Apart from this, could please check the modifications in message_passing.F? Should write a wrapper around the MCL routines there, or can it stay like it is?

Since message_passing.F is already littered with #ifdefs, I don't think a wraper for MCL will help.
So, let's leave it as is for now.