From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.intec.unl.edu.ar (intec.santafe-conicet.gob.ar [200.9.237.140]) by sourceware.org (Postfix) with ESMTPS id 455A23858CDB for ; Sat, 22 Apr 2023 10:37:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 455A23858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=intec.unl.edu.ar Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intec.unl.edu.ar Received: from localhost (localhost [127.0.0.1]) by mail.intec.unl.edu.ar (Postfix) with ESMTP id 1E4A32835E1; Sat, 22 Apr 2023 07:46:15 -0300 (ART) Received: from mail.intec.unl.edu.ar ([127.0.0.1]) by localhost (mail.intec.unl.edu.ar [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1IUrIH2zAPyK; Sat, 22 Apr 2023 07:46:13 -0300 (ART) Received: from localhost (localhost [127.0.0.1]) by mail.intec.unl.edu.ar (Postfix) with ESMTP id B3D242836E3; Sat, 22 Apr 2023 07:46:13 -0300 (ART) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.intec.unl.edu.ar B3D242836E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intec.unl.edu.ar; s=95F69FDA-B53A-11E9-B408-E2E41DC56D40; t=1682160373; bh=iEOXhK/PPaUJNUvjYK9zLHuX4alYwLm7D2OXJqmkZPk=; h=Date:From:To:Message-ID:MIME-Version; b=otwKQxd6WurrE5okzDru2OyREzpDXNX3NYL17nW79ExvdDi1ekuuY3j390y+unM5Z M3pp44ATFafw18RrPBAes2M+lbzaN0FGfP5z7Y7MGJMtyF3jJnX4DPvLBSVzMgVM/I 2d62MfJ7Jys/F+Al15uA9iE9Z67gaHOL9zXJ/ap5n2RyOfwvQKH7hRhnSRrzIEA4ek Rhz50+6hWBnIZB7NbeWhPEEyKiDPt1xn0eUMZBDj4OnYpAVut3zuyTwf1+mhGxtjy5 3NP82+I3roS+z9PJmjIAYrOUtVOcb2QgEM3WGPQjxwHH6EfP8uJsP6Ni4Wx397T6SM 9UnTTJIahcdKg== X-Virus-Scanned: amavisd-new at intec.unl.edu.ar Received: from mail.intec.unl.edu.ar ([127.0.0.1]) by localhost (mail.intec.unl.edu.ar [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PV97QjR71txd; Sat, 22 Apr 2023 07:46:13 -0300 (ART) Received: from mail.intec.unl.edu.ar (mail.intranet [192.168.0.134]) by mail.intec.unl.edu.ar (Postfix) with ESMTP id 74C5F2835E1; Sat, 22 Apr 2023 07:46:13 -0300 (ART) Date: Sat, 22 Apr 2023 07:46:12 -0300 (ART) From: Jorge D'Elia Reply-To: Jorge D'Elia To: Gfortran List Message-ID: <752042381.292.1682160372932.JavaMail.zimbra@intec.unl.edu.ar> In-Reply-To: References: <328135304.91027.1682076811330.JavaMail.zimbra@santafe-conicet.gov.ar> Subject: Re: coarrays using extended precision (80 bits) ? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.8.12_GA_3803 (ZimbraWebClient - FF112 (Linux)/8.8.12_GA_3794) Thread-Topic: coarrays using extended precision (80 bits) ? Thread-Index: 5WSL8zrwi6wHMHBILevrTw4Q/bB31A== X-Spam-Status: No, score=4.1 required=5.0 tests=BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FOREIGN_BODY1,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Dear Steve, ----- Mensaje original ----- > De: "Gfortran List" org> > Para: "Jorge D'Elia" conicet.gov.ar> > CC: "Gfortran List" org> > Enviado: Viernes, 21 de Abril 2023 19:53:26 > Asunto: Re: coarrays using extended precision (80 bits) ? > > On Fri, Apr 21, 2023 at 08:33:31AM -0300, Jorge D'Elia wrote: >> Dear GFortran developers, >> >> 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. >> >> Thanks in any case. >> > > 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? > > -- > Steve 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?). Best regards. Jorge. -- CIMEC (UNL-CONICET), cimec.conicet.gov.ar, www.cimec.org.ar