wstar_units test fail with index out of range error

[Lucian Anton]

The build was done with gfortran 7.3.0 with the flag DEBUG=no

The error message and the trace back are below:

At line 122 of file functional_tests.fpp
Fortran runtime error: Index '-10560' of dimension 2 of array 'omegas' outside of expected range (1:0)

Error termination. Backtrace:
#0  0x4070a9 in __functional_tests_MOD_check_growth_rates_equal_in_list
    at /home/lanton/Projects/gs2/functional_tests.fpp:122
#1  0x406008 in __checks_mod_MOD_checks
    at /lustre/home/lanton/Projects/gs2/tests/linear_tests/wstar_units/wstar_units.f90:9
#2  0x406122 in __functional_tests_MOD_test_gs2
    at /home/lanton/Projects/gs2/functional_tests.fpp:167
#3  0x406028 in wstar_units
    at /lustre/home/lanton/Projects/gs2/tests/linear_tests/wstar_units/wstar_units.f90:22
#4  0x40605f in main
    at /lustre/home/lanton/Projects/gs2/tests/linear_tests/wstar_units/wstar_units.f90:18 

The offending bit of code is below:

do i = 1,njobs
          if (iproc==grp0(i-1)) ijob = i 
       end do
       ! Get the omegas from this job
       omegas(:,ijob) = aimag(omegaavg(1,:))
       if (wstar_units) then
          omegas(:, ijob) = omegas(:,ijob) * aky(:) / 2.0

...

From the code inspection in the call tree I think that the crash is caused by the fact that grp0 is not initialised. For this initialisation to take place the code must pass through utils/mp.fpp:init_jobs subroutine called by utils/job_manage.fpp:job_fork.

[David Dickinson]

Thanks for the report. We've had a number of similar issues with a number of tests but have had some difficulty in reproducing all of them. Could you let us know which system this is on?

I agree with your analysis -- I think there are probably a lot of places where potentially uninitialised values end up being used in the tests (i.e. where we don't go through the "usual" gs2 initialisation).

[Lucian Anton]

I have looked a bit more into the code and I have found out that if a file with extension.list is used as argument the code should work. Indeed I have found wstar_units.list for this test and if I pass this file instead of the *.in file the test runs fine.

The only problem I have is the format of *.list file:

lanton@GS23:~/gs2/tests/linear_tests/wstar_units$ cat *list
2
wstar_units
wstar_units_false
lanton@GS23:~/gs2/tests/linear_tests/wstar_units$

It is a bit short, isn't it?

Probable the test will run fine from the build_gs2 but I work directly only with one or two tests while transferring the old explicit time advance scheme to the current code.

[Joseph Parker]

I think the list file is formatted as number of jobs, and then lists the names of those jobs. So when you do mpirun -np 2 ./wstar_units wstar_units.list you're submitting wstar_units.in to run on one processor, and wstar_units_false.in to run on the other.

[David Dickinson]

Ah, it's expecting a list file. These specify a list of input files to run with in a single run -- a home-grown way of doing array jobs .