<div dir="ltr">Bernard<div><br></div><div>I usually define some constants in each routine or module:</div><div><br></div><div>CCTK_REAL, parameter :: zero = 0</div><div>integer, parameter :: rkind = kind(zero)<br></div><div><br></div><div>and then I can write "cmplx(x, kind=rk)".</div><div><br></div><div>-erik</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 20, 2015 at 12:09 PM, Bernard Kelly <span dir="ltr"><<a href="mailto:physicsbeany@gmail.com" target="_blank">physicsbeany@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Erik.<br>
<br>
I wasn't taking any magnitudes, but it looks like my problem was just<br>
blindly using the "cmplx" function to form the complex variable<br>
without a KIND argument, and it defaults to KIND=1 (i.e.<br>
single-precision) even if the real & imaginary components enter as<br>
double-precision.<br>
<br>
For now, I've switched to the GNU "complex" method, which seems to<br>
have fixed my problem on my Macbook.<br>
<br>
Bernard<br>
<span class=""><br>
On 19 July 2015 at 14:52, Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>> wrote:<br>
> Bernard<br>
><br>
> In Fortran, real(z) (where z is complex) does maintain precision. The<br>
> problem is likely caused by your using "-Ofast", "-ffast-math", or an Intel<br>
> compiler that uses the equivalent by default (so you have to explicitly<br>
> switch it off). With such an optimization, e.g. abs(z) is implemented as<br>
> sqrt(real(z)**2 + aimag(z)**2), which overflows the intermediate squares.<br>
> Without -ffast-math, compilers use a more expensive implementation that does<br>
> not overflow.<br>
><br>
> In your case, I'd assume that the problem is no the call to real, but other<br>
> complex or real functions. Can you show us a larger part of the code, and<br>
> the compiler vendor, version, and options you are using?<br>
><br>
> The C functions CCTK_Cmplx* are deprecated. These days, C compilers<br>
> implement complex numbers as defined by the standard, and you'd use the<br>
> respective C standard function instead.<br>
><br>
> -erik<br>
><br>
><br>
</span>> On Sun, Jul 19, 2015 at 2:16 PM, Bernard Kelly <<a href="mailto:physicsbeany@gmail.com">physicsbeany@gmail.com</a>><br>
<span class="">> wrote:<br>
>><br>
>> Hi all.<br>
>><br>
>> The Cactus documentation shows a set of C routines CCTK_CmplxXXXXXX<br>
>> that presumably preserve precision between CCTK_REAL and CCTK_COMPLEX<br>
>> types. Is there a "right" way to handle this in Cactus with Fortran<br>
>> (that isn't "recode in C")?<br>
>><br>
>> Context: I have some Fortran code in a Cactus thorn that works with<br>
>> real & complex fields. I've noticed that when the numbers are very<br>
>> large in magnitude, taking a simple real(z) drops precision --- a<br>
>> finite but large real part ends up as +/- Inf instead. I suspect it's<br>
>> dropping to single precision at some stage. Switching to "dreal"<br>
>> doesn't help, and avoiding the use of CCTK_COMPLEX altogether ---<br>
>> while possible --- leads to longer, less readable code.<br>
>><br>
>> Thanks,<br>
>><br>
>> Bernard<br>
>> _______________________________________________<br>
>> Users mailing list<br>
</span>>> <a href="mailto:Users@einsteintoolkit.org">Users@einsteintoolkit.org</a><br>
>> <a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
><br>
><br>
><br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>><br>
> <a href="http://www.perimeterinstitute.ca/personal/eschnetter/" rel="noreferrer" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>><br><a href="http://www.perimeterinstitute.ca/personal/eschnetter/" target="_blank">http://www.perimeterinstitute.ca/personal/eschnetter/</a></div>
</div>