changes to accomodate fclen > 2**31 seconds#132
Conversation
* Enable HPC-CI to be run on PRs filed from forks
…nt resolution than the model one
…evelop-1.4 Merge develop 1.3 to develop 1.4
Pin ecbuild to 3.10.0 to fix failing CI
… remove old hardcoding in yowgribhd
…tifier_via_namelist Set generatingProcessIdentifier via namlist
|
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? |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
See my comments about difdate, noting that incdate is used in part of the code still with ifs-source
|
|
||
| IF (IPFGTBL(2) /= 0) THEN | ||
| ITG=ITOBOUT(2) | ||
| CALL STHQ (KIJS, KIJL, FL2ND, BOUT(KIJS:KIJL,ITG)) |
There was a problem hiding this comment.
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
| ZRECVBUF(:)=0._JWRB | ||
|
|
||
| ISTEP=NPROC | ||
| !!!debile |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
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
… 64 bits integers
|
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. |
|
This is the first pull request, done against main branch. |
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.
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