mixed precision tridiagonal #1363
Conversation
| allocate(TRID_REAL_TYPE%cc(size(x,1),size(x,2),size(x,3))) | ||
| !$OMP END SINGLE | ||
|
|
||
| TRID_REAL_TYPE%e(:,:,1) = - a(:,:,1) / b(:,:,1) |
There was a problem hiding this comment.
Fortran question, I don't see how this works. a and b are optional arguments so if they're not present... do a and b exist?
There was a problem hiding this comment.
its just the way this module is written. It's kind of like instead of an init routine you provide the first call to tri_invert with a,b, and c, and then those values are stored and used when the optional arguments aren't provided. It assumes a,b, and c will all be there or not at all.
I'll add present checks for b and c as well just to be safe.
| do i=1, IN_LEN/2 | ||
| end=IN_LEN-i+1 | ||
| if(mod(i, 2) .eq. 1) then | ||
| ref_array(1,1,i) = -(i/2) + (mod(i,2)* IN_LEN/2) |
There was a problem hiding this comment.
i'll add one to the whole thing but the math here (divisions) needs to done with int's so that the value * k is accurate.
| ref_array = ref_array * k | ||
| ! check | ||
| do i=1, IN_LEN | ||
| if(ABS(x(1,1,i) - ref_array(1,1,i)) .gt. 0.1e-12_kindl) then |
There was a problem hiding this comment.
Is there a reason for this mismatch, answers not agreeing?
There was a problem hiding this comment.
for i=1, is the answer supposed to be 8/9? It seems like both x and ref_array are off then hence the discrepancy
| #endif | ||
|
|
||
| !> Tests the tridiagonal module routines (tri_invert and close_tridiagonal) | ||
| !! Tests reals with the kind value set above, |
There was a problem hiding this comment.
Perhaps for the future TODO, FMS tridiagonal solver could be compared to the LAPACK version to check that it's implemented correctly
|
Yay ready to be merged?! Woot! |
* mixed precision column_diagnostics (#1076) * mixed precision mosaic2 (#1074) * mixed precision topography unit tests (#1364) * mixed precision tridiagonal (#1363) * mixed precision: add test for coupler_types and data_override changes (#1361) * Mixed precision `amip_interp_mod` (#1365) BREAKING CHANGE: Several variables and arrays which were previously public have been made private. These variables and arrays are not used in ice_amip or ocean_amip. amip_interp_type(r4_kind) and amip_interp_type(r8_kind) should be used for r4_kind and r8_kind precision, respectively. amip_interp_type without a kind parameter defaults to r8_kind. Co-authored-by: rem1776 <Ryan.Mulhall@noaa.gov> Co-authored-by: mlee03 <Mikyung.Lee@lscamd50-d.gfdl.noaa.gov> Co-authored-by: Caitlyn McAllister <65364559+mcallic2@users.noreply.github.com> Co-authored-by: Jesse Lentz <42011922+J-Lentz@users.noreply.github.com>
Description
mixed precision for tridiagonal mod.
For this module the optional a,b,c arguments are always required for the first call to
tri_invertand are stored in the module to be used if not provided. One change to note is that the previousclose_tridiagonalroutine did not setinit_tridiagonalto false so that was added in.For mixed precision support, I created separate copies of these module level variables that are exclusive to calls using each kind. That behavior can then be overidden with the
store_both_kindsargument so that calls with either kind will store to both module level variables. This meant adding in separate init_tridiagonal logicals for the two kinds as well. I figured this approach provides more flexibility, but we could also just simplify it and always store r8_kind. Also adds a unit test.Fixes # (issue)
How Has This Been Tested?
oneapi 23.2 on the amd box
Checklist:
make distcheckpasses