Skip to content

changes to accomodate fclen > 2**31 seconds#132

Closed
antonl321 wants to merge 66 commits into
ecmwf-ifs:mainfrom
antonl321:syla_fclen_gt_y68.DE-2910
Closed

changes to accomodate fclen > 2**31 seconds#132
antonl321 wants to merge 66 commits into
ecmwf-ifs:mainfrom
antonl321:syla_fclen_gt_y68.DE-2910

Conversation

@antonl321

Copy link
Copy Markdown
Contributor

This PR introduces code changes that allow IFS simulation go over 2^31-1 seconds.
This required promoting a few variable of 64bit integers and interface changes for two subroutines.

Also I think that I found bug, see below.

  1. Structural or significant code changes:
  • incdate.F90 was transform into a module yowincdate.F90 to provide for the time shift kinds with a generic interface
  • difdate subroutine returns a 64bit integer.
  • in wavemdl.F90 the block of code that does incremental change of the end date (CDATEF) was replaced with one call to incdate for it can use 64 integers.
  1. Possible bug
    it seems that a division by 3600 was missed in
    src/ecwam/outmdldcp.F90 line ~ 127 for the variable IFCST
    see also the documentation of the subroutine that uses the variable IFCST, src/ecwam/wgribencode:F90
    and e.g.
    src/ecwam/outspec.F90
    in which the division by 3600 is done

ioanhadade and others added 30 commits February 11, 2025 16:49
* Enable HPC-CI to be run on PRs filed from forks
…evelop-1.4

Merge develop 1.3 to develop 1.4
Pin ecbuild to 3.10.0 to fix failing CI
@awnawab

awnawab commented Mar 18, 2026

Copy link
Copy Markdown
Collaborator

Hi @antonl321. Is this PR intended for 49R3? In which case could you please branch off of develop-1.4 and also PR to the same?

@jkousal32
jkousal32 requested a review from jrbidlot March 19, 2026 10:41
Comment thread src/ecwam/difdate.F90 Outdated

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, a key change is that difdate will now return KSHIFT as an integer of kind JWIB

I assume that we will carefully go through all the instances where difdate is called (maybe we missed a few)

BUT, part of the code is STILL NOT in the ecwam github

See in ifs-souce wam/Wam_oper
There the call in grdata will need to be adapted
(there are also calls to difdate in wamassi but these one are OK because the variables used are part of a module that has been modified

More problematic are all the calls found in wam/Alt and wam/Sar
Problem is all these files are still in fortran 77
One will also see that there are many call to difdate in wam/Buoy, but in there, the code is only used by me and is not compiled with the rest of code (it should be on its own github)

Until we (James Steer) modernise this old piece of code, we could use a 'local' difdate.
This old code deals with Altimeter and Sar data processing and the time difference is never more than a few hours. So no need to worry about promoting to 64 integer.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would a generic difdate subroutine (that can handle 32 or 64 bit integers) located in ecwam would be ok to use in IFS. And drop the difdate version from IFS?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, if it is more generic so that in places where it is used where we know it will never need a long integer and therefore no need to modify the code?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change does imply that all output will need be in grib2. This is fine when running stand alone but you will not be able to bring back this change in the coupled system until 50R2 then?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comments about difdate, noting that incdate is used in part of the code still with ifs-source

Comment thread src/ecwam/outblock.F90

IF (IPFGTBL(2) /= 0) THEN
ITG=ITOBOUT(2)
CALL STHQ (KIJS, KIJL, FL2ND, BOUT(KIJS:KIJL,ITG))

@jrbidlot jrbidlot Mar 19, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this change needed?
All other use of array BOUT in other subroutine calls in this subroutine have BOUT(KIJS, ...
i.e. there is no forced copy in the calling?

Is it connected to outbs_loki_gpu that makes the array a contiguous pointer?
Then all the other subroutine calls needs adapting (you might not have hit the problem because by default the standard test do not output the other parameters produced by these calls

Comment thread src/ecwam/outwspec.F90
ZRECVBUF(:)=0._JWRB

ISTEP=NPROC
!!!debile

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You must have inherited this change from me (if you know French you would comprehend the humour in why I flag it with debile: i.e. I am not sure it is necessary

@jrbidlot jrbidlot left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comments regarding difdate and incdate as well as that this version is grib2 only could therefore only be used in the future 50R2

@antonl321
antonl321 requested a review from jrbidlot March 23, 2026 11:55
@antonl321

Copy link
Copy Markdown
Contributor Author

I have agregates incdate and difdate in one module (yowdate_utils.F90) with generic interfaces to allow 64 bits integer argument. In ifs-source I have introduced yowdate_utils acrorss wam subdirectory.

@antonl321 antonl321 mentioned this pull request Mar 25, 2026
@antonl321

Copy link
Copy Markdown
Contributor Author

This is the first pull request, done against main branch.
I have opened a new one against develop-1.4 as suggested by Ahmad, see
#133

@antonl321 antonl321 closed this Mar 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants