| Description |
- Recently, I introduced at resetting of the reporting of the time-step counter in routine diag.F after 10 billion steps. The formatted field is I10 (ten digits):
WRITE (stdout,30) MOD(iic(ng)-1,10000000000), &
....
30 FORMAT (i10, ....
Some compilers seem to have issue with this integer operation. For example gfortran gives:
diag.f90:383:53:
WRITE (stdout,30) MOD(iic(ng),10000000000), &
1
Error: Integer too big for its kind at (1). This check can be disabled with the option -fno-range-check
To avoid issues with different compilers, I am changing the statement to a floating-point operation:
WRITE (stdout,30) INT(MOD(REAL(iic(ng)-1,r8),1.0E+10_r8)), &
...
It is more robust to use the MOD intrinsic function with floating-point values.
- Cleaned the documentation in mod_kinds.F. Both byte and bit were used and it is better to do it in bits. Notice that byte and bit are not the same and can get confusing.
- I renamed the i4b integer kind to i8b in files gasdev.F, nrutil.F, ran1.F, and ran_state.F to agree with the 32-bit documentation of the random numbers and the definition in mod_kinds.F.
Be aware that SELECTED_INT_KIND and KIND are different in Fortran when declaring integers:
integer, parameter :: i8b = selected_int_kind(8)
integer :: i ! default
integer (i8b) :: i8
integer (KIND=8) :: j8
A simple program can be written to examine the largest integer possible using the HUGE intrinsic function:
Default, HUGE(i ) = 2147483647
SELECTED_INT_KIND(1 ), HUGE(i1 ) = 127
SELECTED_INT_KIND(2 ), HUGE(i2 ) = 127
SELECTED_INT_KIND(4 ), HUGE(i4 ) = 32767
SELECTED_INT_KIND(8 ), HUGE(i8 ) = 2147483647
SELECTED_INT_KIND(9 ), HUGE(i9 ) = 2147483647
SELECTED_INT_KIND(16), HUGE(i16) = 9223372036854775807
KIND(1 ), HUGE(j1 ) = 127
KIND(2 ), HUGE(j2 ) = 32767
KIND(4 ), HUGE(j4 ) = 2147483647
KIND(8 ), HUGE(j8 ) = 9223372036854775807
Notice that the SELECTED_iNT_KIND(8) and KIND=8 have very different values. Also notice that the default declaration have the same values as SELECTED_iNT_KIND(8) or KIND=8.
|
| Description |
Several Matlab scripts were added:
- 4dvar/obs_extract.m: Extracts data from input data assimilation observations NetCDF file at the requested time interval (days) and creates new observations NetCDF files at such intervals. This script may be used to generate input observation NetCDF files for the Ensemble Kalman Filter (EnKF) from 4D-Var observations files. That is, they can be used for 3-dimensional First Guess at Appropriate Time (3D-FGAT) data assimilation with EnKF.
- utility/daynum.m: Converts requested date (year, month, day, ...) into a serial date number. It uses the Proleptic Gregorian Calendar, which extends backward the date preceding 15 October 1582 with a year length of 365.2425 days. It is similar to Matlab function datenum but differs on the origin (day=0), which corresponds to Mar 1, 0000.
- utility/dayvec.m: Converts a given date number as computed by daynum to a date vector (year, month, day, hour, minutes, seconds). It is the inverse function to daynum. It is equivalent the native datevec function.
- utility/inferno.m: A 256 colormap by Nathaniel J. Smith and Stefan van der Walt.
- utility/magma.m: A 256 colormap by Nathaniel J. Smith and Stefan van der Walt.
- utility/plasma.m: A 256 colormap by Nathaniel J. Smith and Stefan van der Walt.
- utility/viridis.m: A 256 colormap by Eric Firing.
- utility/yearday.m: Given (year, month, day) this function computes the day of the year.
I also updated 4dvar/obs_read.m, landmask/uvp_masks.m, and netcdf/roms_metadata.m scripts.
Try the new colormap palettes. Maybe some of you have used these palettes before.
|
