GitLab

Introducing python script plot.py containing several classes used to
plot matrices stored in block-cyclic distribution as a 1 global matrix.
Docstrings in plot.py should explain the ussage. There are also two
use cases included, both with commented scripts (using classes from
plot.py) and a screenshot. One of the use cases contains also tarball
with data.

Apart from that, a VERY simple module matrix_plot.F90 was created. It
is really simplistic, a more systematic approach towards loging should
be designed. At the moment, matrix output has to be triggered explicitly
in the code by calling a macro SAVE_MATR(event_description, iteration).

- Did not properly handle case when $HOST is not set
- String comparison with "[" is done with a single "="

Because it could be difficult to run the runner directly on miy01,
it is being run on dvl02, but the runner method is "ssh" and the
tests are then build and run on miy01

In the current form, the assert macro is not usable, since it might
generate too long lines depending on the lenght of __FILE__ string.
This is a temporary fix to allow setting up tests on Minsky

the test failed, since THIS_REAL_ELPA_KERNEL_API has not been specified
as it is in other simmilar tests. This fixed the issue, but probably the
behavior of elpa_solve_evp_real_double should be changed not to check
value of THIS_REAL_ELPA_KERNEL_API for 1stage test

PGI compiler does not like too long lines even though they are comments

Otherwise we stumble upon file system limits when 'manual_cpp' has to be
used. This whole situation with the 'manual_cpp' is very unsatisfying...

The PGI compiler (of course) complained about a missing module
(elpa_generated_fortran_interfaces.mod) when compiling the test
programs.

It is true (in a way) that some part of this module is indeed necessary,
as the public-facing function signatures have arguments that are
referring to those three functions in their type:

  elpa_strerr_c(elpa_error)
  elpa_int_value_to_string_c(name, value, string)
  elpa_int_value_to_strlen_c(name, value)

Thus, for these three we create another header prefix,

  !pf>

for Fortran definitions that should be public. Those are included in
elpa_api.F90.

It is not quite clear to me why GCC complains here when
WANT_SINGLE_PRECISION_REAL is not defined, as the variables are then not
used _at all_.

Nonetheless, this again prevents build on the SuSE OBS, so fix it to
make the compiler happy

Another blocker for the SuSE build server: Even though the variable is
later not actually used by the function, a recent GCC complains about
the use of an uninitialized value for that variable.

This prevents build on the OBS, as they use compiliation flags that
detect such behaviour.

Error message there:

 ../test/C/driver/legacy_interface/legacy_real_driver_c_version.c:193:12: warning: 'THIS_REAL_ELPA_KERNEL_API' is used uninitialized in this function [-Wuninitialized]
     success = elpa_solve_evp_real_double(na, nev, a, na_rows, ev, z, na_rows, nblk, na_cols, mpi_comm_rows, mpi_comm_cols, my_mpi_comm_world, THIS_REAL_ELPA_KERNEL_API, useQr, useGPU,

 [...]

 I: Program is using uninitialized variables.
    Note the difference between "is used" and "may be used"
 W: elpa uninitialized-variable ../test/C/driver/legacy_interface/legacy_real_driver_c_version.c:193

Recent GCC complain that an assignment involving a transfer statement
might potentially overflow the destination buffer. This prevented a
build on the SuSE build server.

Replaced this with a proper C string pointer.

Error message there:

 ../src/elpa_driver/legacy_interface/./elpa_driver_c_interface_template.X90:117:0:

        methodFortran(1:charCount) = transfer(method(1:charCount), methodFortran)

 Warning: '__builtin_memset': writing between 1 and 2147483640 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]

 [...]

 I: Statement might potentially overflow a destination buffer, where a size larger
     than the actual buffer was specified
 E: elpa destbufferoverflow Warning: '__builtin_memset'