ROPP FM Coding Problem

[frae]

The g95 bails out in ropp_fm/common/ropp_fm_obs2roprof.f90:186

  do i = 1, int((int(sqrt(8.0_wp * size(y%cov%d)) + 1.0_wp) - 1.0_wp) / 2)
     ro_data%Lev2a%refrac_sigma = sqrt(y%cov%d(i + i*(i-1)/2)) ! pp, uplo = 'U'
  enddo

Not sure if I understand this construct correctly, the first int(...) in the for loop was introduced by me since the g95 compiler was complaining. But it seems that the size(y%cov%d) is actually 1, and the loop runs to 1 before it core dumps. Mabye the netcdf file should have a covariace in there, the ones I use at the moment have not (also the ones in ropp_fm/data don't seem to have one). So there should be an error message somewhere. Also, should errors be part of the FM, or should they be just in the 1DVar part?

In addition, the ro_data%Lev2a%refrac_sigma = puzzles me, why is there no index in there. Maybe my f90 knowledge is failing me here.

The same problem will likely also occur a few lines earlier when the same is done for bending angles.

Funny enough the Intel Fortran compiler does not seem to mind at all.

[marq]

That's an interesting one... to be honest, I do not even know why I used these strange loop boundaries. Probably I intended to obtain the number of available values from the size of the covariance matrix. Anyway, it can be done much simpler - the number of required sigmas is of course the length of the observation vector, so... The target arrays need to be indexed, of course; I have corrected that in [807] and [808].

On the covariance matrices in general: The observation vectors (Obs1dbangle and Obs1drefrac) do indeed carry the covariance information with them. Upon "checkout", that is when I copy data from the observation vector back to an ROprof structure, I set the error estimate for that particular observation from the diagonal elements of the covariance matrix. In a similar way, the initial error covariance for an observation is set from the error estimates in the ROprof structure. The same, by the way, happens for the background data.

I now realise that the test program in ropp_fm doesn't even allocate the covariance matrices. So I have added a check (in [809]) if the matrix is used and has the correct size before copying anything. Note that no warning or error message is issued in this case; the default (or previous) settings of the sigmas aren't touched at all.

And finally: I believe the Intel compiler was fine because it returns 0 for unallocated pointers. So the number of iterations turned out to be zero, and the nothing was copied. But g95 obviously returns something different in that particular case... I remember we (Dave and myself) stumbled over this strange behaviour before, when I was using the size of an array as an indicator if it was allocated or not. I also remember that Dave, when asking the g95 developers, basically got the answer that they wouldn't change the behaviour because the Fortran standard says the compilers behaviour is undefined in such a case, and that the associated() or allocated() intrinsics should be used in a proper way.

Please check if this fixes the problem for g95 and reopen the ticket if not.

Chris.

[Dave Offiler]

The g95 answer was disappointingly correct. The F95 standard does not define what might be returned if a pointer is not associated or an array not allocated. The Intel happens to return zero for size() in these cases; other compilers are free to return something else (I think for g95 it was unity) or might even crash. Hence it can't be relied upon and to do so is bad practice and programming.

Dave

[(none)]

Milestone 0.9 deleted