Do functions check size/rank of input arrays? If not why?

[rgba]

@kargl

A minimum working example.

Fair enough, here you have:

program MWE_for_Kargl

   implicit none

   integer, parameter   :: Norb=3, Nspin=2, Lmats=1000, Nk=5

   complex(8)           :: dDelta(Nspin,Nspin,Norb,Norb,Lmats,Nk)
   complex(8)           :: Htmp(Nspin*Norb,Nspin*Norb)
   integer              :: k

   Htmp = dcmplx(0d0,0d0)

   do k=1,Nk
      dDelta(:,:,:,:,:,k)=so2nn_inlined(Htmp,Nspin,Norb,Lmats)
   enddo

contains

   pure function so2nn_inlined(Hso,Nspin,Norb,L) result(Hnn)
      !! Local version of so2nn_reshape, doing all iω at once
      !! > with high optimization levels it should be inlined
      integer,intent(in)    :: Nspin,Norb,L
      complex(8),intent(in) :: Hso(Nspin*Norb,Nspin*Norb,L)
      complex(8)            :: Hnn(Nspin,Nspin,Norb,Norb,L)
      integer               :: io,is,istride
      integer               :: jo,js,jstride
      do concurrent(is=1:Nspin,js=1:Nspin,io=1:Norb,jo=1:Norb)
         istride = io + (is-1)*Norb  !spin-orbit stride
         jstride = jo + (js-1)*Norb  !spin-orbit stride
         Hnn(is,js,io,jo,:) = Hso(istride,jstride,:)
      end do
   end function so2nn_inlined

end program MWE_for_Kargl

This actually fails at runtime (segfault) so yes, I think is better than what I see on the bigger example. Nevertheless it is confirmed that even rank is not checked at compile time.

$ fpm @debug --target mwe
mwe.f90                                done.
mwe                                    done.
[100%] Project compiled successfully.

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fee6fb153af in ???
#1  0x4012aa in so2nn_inlined
	at test/mwe.f90:30
#2  0x401514 in mwe_for_kargl
	at test/mwe.f90:14
#3  0x401591 in main
	at test/mwe.f90:13
<ERROR> Execution failed for object " mwe "
<ERROR>*cmd_run*:stopping due to failed executions
STOP 1

@Euler-37

Explicit-shape Array and Assumed-size Array don’t check the size and the rank.

Thanks a lot! This clarifies a lot to me, I had forgot about this (and probably didn’t expect the caveat to apply to rank too).

@PierU

if the routine does a little amount of computation and is repeatedly called, then the runtime tests can severely arm the performances

Well. this is exactly the point in my original use case: that cost function is called many many times by the minimizer, so I indeed want to avoid wasting time on anything. That’s why I avoided assumed-shape (and a manual runtime check with a if construct), I thought this way the compiler would have checked for me at build time, my bad.

@PierU

As for the rank, they could not be easily checked at the times where no interfaces exist.

This is a little perplexing to me, the so2nn_inlined function is a module procedure in my original code (or at least I thought so… it is placed in the contains section of the same module where grad_delta_replica is). I thought an explicit interface was in place, am I wrong on this?

@PierU

And the ability to pass a rank 1 array as an actual argument to a routine where the dummy argument is a rank 2 (or more) array has been extensively used in the past (and is still used, even if there are now other mechanisms to achieve that).

I find this interesting anyway, thanks for pointing out. Could you give an example (or a pointer to find out more?). Thanks anyway!