Problem with zero sized arrays

[pmarguinaud]

What happened?

A problem appeared between version 0.3.6 and version 0.3.7; the following piece of code :

ALLOCATE (ZDATA0 (10, 11, 0))

CALL FIELD_NEW (YLF, DATA=ZDATA0)

ZDATA => GET_HOST_DATA_RDWR (YLF)

PRINT *, " LBOUND (ZDATA0) = ", LBOUND (ZDATA0)
PRINT *, " UBOUND (ZDATA0) = ", UBOUND (ZDATA0)

PRINT *, " LBOUND (ZDATA) = ", LBOUND (ZDATA)
PRINT *, " UBOUND (ZDATA) = ", UBOUND (ZDATA)

IF (ANY (LBOUND (ZDATA0) /= LBOUND (ZDATA))) THEN
  STOP 1
ENDIF

IF (ANY (UBOUND (ZDATA0) /= UBOUND (ZDATA))) THEN
  STOP 1
ENDIF

works with 0.3.6 and fails with 0.3.7

This is illustrated in the following branches :

https://github.com/pmarguinaud/field_api/tree/v0.3.6-zerodim
https://github.com/pmarguinaud/field_api/tree/v0.3.7-zerodim

where a new test has been added.

The output of the new test case was (0.3.6):

  LBOUND (ZDATA0) =            1           1           1
  UBOUND (ZDATA0) =           10          11           0
  LBOUND (ZDATA) =            1           1           1
  UBOUND (ZDATA) =           10          11           0

and is now (0.3.7):

  LBOUND (ZDATA0) =            1           1           1
  UBOUND (ZDATA0) =           10          11           0
  LBOUND (ZDATA) =            1           1           1
  UBOUND (ZDATA) =            1           1           1

What are the steps to reproduce the bug?

The test case test_zerodim.F90 in :

https://github.com/pmarguinaud/field_api/tree/v0.3.6-zerodim
https://github.com/pmarguinaud/field_api/tree/v0.3.7-zerodim

reproduces the issue

Version

0.3.7

Platform (OS and architecture)

Linux belenoslogin2.belenoshpc.meteo.fr 3.10.0-1160.102.1.el7.x86_64 #1 SMP Mon Sep 25 05:00:52 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux

Relevant log output

Accompanying data

No response

Organisation

No response

[awnawab]

Hi @pmarguinaud,

Thanks for narrowing down the above behaviour change. This was indeed an intentional change, and it came in via this PR: #106.

We were seeing repeatable OpenACC data table problems when trying to offload zero sized fields in both IFS (with field_api) and ecTrans (with native OpenACC, not field_api), and this went away with the above change that offers protection against registering zero sized allocations in the OpenACC data table.

At this point we rely on the above behaviour, and we would like to keep it. Of course we can make it optional, I am happy to prepare a PR. Would you prefer a run-time or a compile-time option to control this behaviour? I would prefer a compile-time option.

[pmarguinaud]

Hello Ahmad,

Thank you for your answer.

I suppose the issue has been reported to NVIDIA and will be solved, so this should be a temporary feature of field_api. The issue is that it breaks all ARPEGE assimilation jobs in cycle 50t2.

Please provide a compile time option, I think we can work with that.

[awnawab]

This was fixed and merged in #149.