<div dir="ltr"><div class="gmail_default" style="font-family:'trebuchet ms',sans-serif;color:rgb(68,68,68)"><div class="gmail_default" style>When I don't use -O2 or -O3, both compilers produce the correct answers.</div>
<div class="gmail_default" style>When I use ifort with -O2/-O3, it produces wrong answer.</div><div class="gmail_default" style>When I use gfortran-4.7 with -O2/-O3, it cannot even read in the input file. </div><div class="gmail_default" style>
When I use gofrtran-4.4 with -O2/-O3, it also produce correct answer.</div><div class="gmail_default" style>I think the problem is on the Fortran code.</div><div class="gmail_default"><br></div><div class="gmail_default">
All the error information is about "used uninitialized" from valgrind:</div><div class="gmail_default"><br></div><div class="gmail_default"><pre style="color:rgb(0,0,0)">==8397== Memcheck, a memory error detector
==8397== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==8397== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==8397== Command: ./eco2n
==8397==
==8397== Conditional jump or move depends on uninitialised value(s)
==8397== at 0x11E1F367: __intel_sse2_strcat (in /opt/intel/composer_xe_2013.3.163/compiler/lib/intel64/libirc.so)
==8397== by 0xC728F0: read_configuration_files (in /home/lchen/seq_v2/eco2n)
==8397== by 0xC20DE3: MPID_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEAC54: MPIR_Init_thread (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEA443: PMPI_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBB6CAC: mpi_init (in /home/lchen/seq_v2/eco2n)
==8397== by 0x43C724: MAIN__ (t2cg22.f:319)
==8397== by 0x40C2CB: main (in /home/lchen/seq_v2/eco2n)
==8397==
==8397== Use of uninitialised value of size 8
==8397== at 0x11E1F3DA: __intel_sse2_strcat (in /opt/intel/composer_xe_2013.3.163/compiler/lib/intel64/libirc.so)
==8397== by 0xC728F0: read_configuration_files (in /home/lchen/seq_v2/eco2n)
==8397== by 0xC20DE3: MPID_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEAC54: MPIR_Init_thread (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEA443: PMPI_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBB6CAC: mpi_init (in /home/lchen/seq_v2/eco2n)
==8397== by 0x43C724: MAIN__ (t2cg22.f:319)
==8397== by 0x40C2CB: main (in /home/lchen/seq_v2/eco2n)</pre><pre style="color:rgb(0,0,0)"><br></pre><pre style="color:rgb(0,0,0)"><pre>==8397== Memcheck, a memory error detector
==8397== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==8397== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==8397== Command: ./eco2n
==8397==
==8397== Conditional jump or move depends on uninitialised value(s)
==8397== at 0x11E1F367: __intel_sse2_strcat (in /opt/intel/composer_xe_2013.3.163/compiler/lib/intel64/libirc.so)
==8397== by 0xC728F0: read_configuration_files (in /home/lchen/seq_v2/eco2n)
==8397== by 0xC20DE3: MPID_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEAC54: MPIR_Init_thread (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEA443: PMPI_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBB6CAC: mpi_init (in /home/lchen/seq_v2/eco2n)
==8397== by 0x43C724: MAIN__ (t2cg22.f:319)
==8397== by 0x40C2CB: main (in /home/lchen/seq_v2/eco2n)
==8397==
==8397== Use of uninitialised value of size 8
==8397== at 0x11E1F3DA: __intel_sse2_strcat (in /opt/intel/composer_xe_2013.3.163/compiler/lib/intel64/libirc.so)
==8397== by 0xC728F0: read_configuration_files (in /home/lchen/seq_v2/eco2n)
==8397== by 0xC20DE3: MPID_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEAC54: MPIR_Init_thread (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBEA443: PMPI_Init (in /home/lchen/seq_v2/eco2n)
==8397== by 0xBB6CAC: mpi_init (in /home/lchen/seq_v2/eco2n)
==8397== by 0x43C724: MAIN__ (t2cg22.f:319)
==8397== by 0x40C2CB: main (in /home/lchen/seq_v2/eco2n)</pre><pre>...</pre><pre style>hundreds of similar error.</pre></pre></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Best regards,<div>Longxiang Chen</div>
<div><br></div></div></div>
<br><br><div class="gmail_quote">On Fri, Jun 28, 2013 at 11:05 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Jun 29, 2013, at 12:24 AM, Longxiang Chen <<a href="mailto:suifengls@gmail.com">suifengls@gmail.com</a>> wrote:<br>
<br>
> I find that the fortran program cannot add optimization flag (-O2 or -O3) if I use gfortran-4.7.2 or ifort to compile.<br>
<br>
</div> What do you mean? Do you mean to say that if use -O2 or -O3 flags with gfortran 4.7.2 or ifort it produces the wrong answer? Does it produce the same wrong answer with both compilers? If you use no optimization with both compilers does it produce the "correct" answer?<br>
<div class="im"><br>
> When I change the compiler to gfortran-4.4, now the --with-debug=0 (adding -O3) works.<br>
<br>
</div> but if you use -O3 flag with gfortran 4.4 it runs with the correct answer?<br>
<br>
Since it works incorrectly with two very different fortran compilers (optimized) it is more likely there is something wrong with your code than with both compilers. You most definitely should run with valgrind and make sure there is no memory corruption in your code.<br>
<span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Thank you all.<br>
><br>
> Best regards,<br>
> Longxiang Chen<br>
><br>
><br>
><br>
><br>
> On Fri, Jun 28, 2013 at 3:25 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
> Run both debugged and optimized versions with valgrind: <a href="http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind" target="_blank">http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind</a><br>
><br>
> Barry<br>
><br>
> On Jun 28, 2013, at 3:30 PM, Longxiang Chen <<a href="mailto:suifengls@gmail.com">suifengls@gmail.com</a>> wrote:<br>
><br>
> > A is formed by three arrays IA[NZ], JA[NZ] and VA[NZ]<br>
> > IA[i] is row index, JA[i] is column index and VA[i] is the value in (IA[i], JA[i]).<br>
> ><br>
> > For intel compiler:<br>
> > when I use --with-debugging=0, the VA[] is not correct. I don't know what kind of optimization it does.<br>
> ><br>
> > A[0][0] = 1.000000e-25<br>
> > A[0][1] = 0.000000e+00<br>
> > A[0][2] = 0.000000e+00<br>
> > A[1][0] = 0.000000e+00<br>
> > A[1][1] = -3.479028e+02<br>
> > A[1][2] = 0.000000e+00<br>
> > A[2][0] = 0.000000e+00<br>
> > A[2][1] = 0.000000e+00<br>
> > A[2][2] = -3.479028e+02<br>
> > A[3][3] = 1.000000e-25<br>
> > ...<br>
> ><br>
> > CORRECT:<br>
> > A[0][0] = -2.961372e-07<br>
> > A[0][1] = 1.160201e+02<br>
> > A[0][2] = 2.744589e+02<br>
> > A[1][0] = 0.000000e+00<br>
> > A[1][1] = -3.479028e+02<br>
> > A[1][2] = 0.000000e+00<br>
> > A[2][0] = -8.332708e-08<br>
> > A[2][1] = 0.000000e+00<br>
> > A[2][2] = -3.479028e+02<br>
> > A[3][3] = -3.027917e-07<br>
> > ...<br>
> ><br>
> > For gcc-4.7.2:<br>
> > when I use --with-debugging=0, the fortran main function cannot read input data before it starts the LOOP, the ksp_solver() is called inside the loop.<br>
> > ===><br>
> > ERRONEOUS DATA INITIALIZATION STOP EXECUTION---------<br>
> ><br>
> > Best regards,<br>
> > Longxiang Chen<br>
> ><br>
> > Do something everyday that gets you closer to being done.<br>
> ><br>
> ><br>
> ><br>
> > On Thu, Jun 27, 2013 at 6:42 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > On Jun 27, 2013, at 2:23 PM, Tabrez Ali <<a href="mailto:stali@geology.wisc.edu">stali@geology.wisc.edu</a>> wrote:<br>
> ><br>
> > > Fortran can be tricky.<br>
> > ><br>
> > > Try to run the program in valgrind and/or recheck all your arguments. I once forgot MatAssemblyType in the call to MatAssembly and the code still ran fine on one machine but failed on other. It is better to test with at least 2-3 compilers (GNU, Solaris and Open64 Fortran/C compilers are all free on Linux).<br>
> > ><br>
> > > T<br>
> ><br>
> > You can also run both versions with -snes_monitor -ksp_monitor and see if they both start out the same way.<br>
> ><br>
> > Barry<br>
> ><br>
> > ><br>
> > ><br>
> > > On 27.06.2013 14:52, Longxiang Chen wrote:<br>
> > >> Dear all,<br>
> > >><br>
> > >> I use ksp_solver to solve Ax=b, where A is from an outer loop of PDE.<br>
> > >> Under debug mode(default), it solves the problem in about 4000<br>
> > >> iterations.<br>
> > >> And the final answer is correct (comparing to another solver).<br>
> > >><br>
> > >> I use intel compiler.<br>
> > >> The program is in Fortran (by mpif90), except the solver is in c (by<br>
> > >> mpicc).<br>
> > >><br>
> > >> However, when I re-configure with --with-debugging=0 (the only<br>
> > >> change),<br>
> > >> the program terminates in about 30 iterations with the wrong final<br>
> > >> solution.<br>
> > >><br>
> > >> Thank you.<br>
> > >><br>
> > >> Best regards,<br>
> > >> Longxiang Chen<br>
> > >><br>
> > >> Do something everyday that gets you closer to being done.<br>
> > ><br>
> ><br>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>