On Sat, Apr 22, 2023 at 07:46:12AM -0300, Jorge D'Elia wrote: > > On Fri, Apr 21, 2023 at 08:33:31AM -0300, Jorge D'Elia wrote: > >> > >> One question: is there any chance of encoding with coarrays using > >> extended precision (80 bits) at least inside a multicore computer? > >> (as if to simplify a bit). > >> > >> To date, the possibility of using double precision (64 bits) or > >> extended precision (80 bits) is an alternative in our production > >> code, but sometimes we would like to do computations in > >> 80 bits and, in certain parts, there are coarrays. > >> We have validated even in quadruple precision (128 bits), using > >> ifort although, as is well known, the CPU times are largely > >> excessive. > >> > > Well, I just installed OpenCoarray and downloaded a pi/4 > > monte carlo code that Thomas wrote using REAL. I changed > > everything to use REAL(10). Compiled and executed without > > a problem. I also tested REAL(16), which worked although > > it's painfully slow due to software floating point. So, > > I guess I don't understand what you're asking? > > > > Thanks a lot for your answer. Now: > > Since we were noticing numerical issues in certain cases in our code, > we moved on to a toy model. The toy model is based on a standard LU > factorization with a dense block-distributed system matrix. So: > > 1/2) When we use gfortran+opencoarrays: > The verification computation of the numerical solution of the system > of equations is OK if we use precision either (single, double, extended, > quadruple) when the number Z of images is equal to 1. It is also OK if > we use precision either (single, double) when Z>1. But it fails if we > use precision either (extended, quadruple) when Z>1. > > 2/2) When we use ifort: > The verification computation of the numerical solution of the system > of equations is OK if we use precision either (single, double, quadruple) > either when Z=1 or when Z>1. We cannot check it in extended precision > because ifort does not support the use of extended precision. > > As a first attempt to explain the discrepancy, we assume that those > verification failures in the solution could be attributed to > gfortran+opencoarrays not quite correctly transmitting numbers in > extended precision, because opencoarrays relies on some standard MPI > for single and double precision (it would be like this?).
This might be a bug in OC or gfortran or both. It is unclear if there is any further work being done on OC. If the LU toy code is short enough, you might try compiling it with -fcoarray=lib -fdump-tree-original to see if there are any obvious function argument mismatches in the underlying code. I looked more closely at Thomas's code. It was passing integer arrays between images while the images internally used REAL(10). If it's an argument passing issues with REAL(10), his code would not expose it. -- Steve
