The ABINIT Users Mailing List ( CLOSED )

[Masayoshi Mikami <mmikami@rc.m-kagaku.co.jp>]

Salut,

Yes,  the problem here was very similar, looks like this:
<   >Total DC energy in eV        = <C0><8C>R<D0><F0><BC><C9><96>
>   >Total DC energy in eV        = -9.06352021670248E+02
and your modification did work after checking diff.t06 etc.
(not with fldiff.report)  Merci bien !

By the way, the problem with t88 looks like this:
        (snip)
<  E^0_gap         11.838
>  E^0_gap          9.363
1116
<  E^GW_gap        12.303
>  E^GW_gap         9.518
1117
<  DeltaE^GW_gap    0.465
>  DeltaE^GW_gap    0.155
1119
<  New Fermi energy :     2.051841E-01 Ha ,    5.583344E+00 eV
>  New Fermi energy :     2.463957E-01 Ha ,    6.704768E+00 eV
1373
< +Overall time at end (sec) : cpu=         27.3  wall=         27.3
> +Overall time at end (sec) : cpu=         66.9  wall=         75.2

Cheers, and Bon weekend,
Masayoshi

On 2007/04/06, at 15:49, Anglade Pierre-Matthieu wrote:

> Hi,
>
> For me the problem on tests
> v4:t04-08
> and v4:t88
> is only at the line where the "Total DC energy in eV" is printed. Do
> you have other differences ?
> For my case, I get some output like:
> <   >Total DC energy in eV        = ^N*w(c)<9a>¥¿
> >   >Total DC energy in eV        = -4.15475259271129E+02
> But I was incorrect when reporting my trick. The line 279 must be
> changed by something like:
>   if (optdc==2) write(message, '(a)') ch10
> or    if (optdc==2) write(message, '(a)') "   "
> With this mod, the printed number is correct but the line is obvously
> changed : so the report keep saying the test is not OK yet PAW users
> will be able to read the energy in a much more human friendly way :-)
>
> regards
>
> PMA
>
> On 4/6/07, Masayoshi Mikami <mmikami@rc.m-kagaku.co.jp> wrote:
> > Dear all,
> >
> > Please let me correct something. After rebooting,
> > some tests passed successfully. (v4:86,87, 92,93,94)
> > I suspect  hardware problems with my Mac(G5),
> > e.g. memory...
> > Still, the situation remains the same with v4:t04-08
> > and v4:t88 .
> >
> > Cheers,
> > Masayoshi
> >
> > On 2007/04/05, at 20:49, Masayoshi Mikami wrote:
> >
> > > Salut !
> > >
> > > Please let me have a similar report with MacOSX(Tiger, 10.4.9)
> > > and gfortran (version 4.3.0 20061223 (experimental)).
> > >
> > > v1-v3 : no fatal problems
> > > v4: t04-t08, the same problem with the printout of
> > > "the total DC energy", even after the remedy by Pierre-Matthieu.
> > > v4:t86, t87 ... sudden death (NB: no problems with v.5.3.3 !)
> > > v4:t88, the big numerical difference
> > > v4: t92, sudden death, t93 many NaN, t94 sudden death
> > > (NB: no problems of v4:t92-94 with v.5.3.3 on the same Mac,
> > >  interestingly ...)
> > > v5: t08, 09; the same problem with the DC total energy...
> > >
> > > So something seemed to happen between v.5.3.3 and v.5.3.4 ...
> > > at least for the MacOSX/gfortran.
> > > (I did not try with MacOSX/XLF8.1. How was the results ?)
> > >
> > > Cheers,
> > > Masayoshi
> > >
> > > On 2007/04/05, at 18:20, Anglade Pierre-Matthieu wrote:
> > >
> > >> Hi guys,
> > >>
> > >> For me, under linux (fc6 on x86_64 nocona and core duo), with
> > >> gfortran
> > >> (4.2.0 20070110 and 4.2.0 20070317) the tests results for abinit
> > >> 5.3.4
> > >> is as follows:
> > >> V1: OK
> > >> V2: OK
> > >> V3:
> > >> - t19 gives a large discrepancy on an unconverged SCF cycle.  
> > This is
> > >> a very old problem and maybe a bug.
> > >> -  t83 has too many differents line but is in fact perfectly OK
> > >> V4:
> > >> T06, t07, t08, have a problem at printing the Total DC energy  
> > in eV.
> > >> This is a bug. It is easily solved by  changing in 15comon/ 
> > prtene.F90
> > >> line 279 from:
> > >> if (optdc==2) message=""
> > >> to
> > >> if (optdc==2) message="   "
> > >> or by removing this line.
> > >> The "" is misunterpeted by gfortran and causes a bug that appears
> > >> only
> > >> for this compiler (we may think the bug is in fact a gfortran
> > >> bug). It
> > >> hought I had commited a fix for that. Apparently this was not the
> > >> case.
> > >>
> > >> t88: This is a real abinit/gfortran bug for GW self consistent.  
> > It is
> > >> known since v5.3.2 (at least) and matteo giantomassi is  
> > investigating
> > >> the case.
> > >>
> > >> V5:
> > >> t08: same PAW problem as v4 t06-08
> > >>
> > >> So, unless you are conducting self-consistent GW calculations
> > >> gfortran
> > >> compiled (latest gfortran 4.2 I mean) is safe with abinit 5.3.4.
> > >> What is the version o gfortran you use Nuno ? I
> > >> reagards
> > >>
> > >> PMA
> > >>
> > >> On 4/4/07, Anglade Pierre-Matthieu <anglade@gmail.com> wrote:
> > >>> HI,
> > >>>
> > >>> Those tests are (mostly v3, v4) PAW and GW tests. They undergoes
> > >>> problem with gfortran before the final merges. Yet I was thinking
> > >>> most
> > >>> of the problems with gfortran were fixed during 5.3.2-> 5.3.3.  
> > and
> > >>> then fixed better again in the 5.3.3 -> 5.3.4 by Marc and  
> > Matteo. I
> > >>> haven't already checked what's up with 5.3.4.+gfortran.
> > >>> I'll tell you tomorrow.
> > >>>
> > >>> regards
> > >>>
> > >>> PMA
> > >>>
> > >>> On 4/4/07, Nuno A. G. Bandeira <nuno.bandeira@ist.utl.pt> wrote:
> > >>> > gay@sfu.ca wrote:
> > >>> > > I found recent versions of gfortran gave big errors on
> > >>> > > tests v2, 61-66, which did not happen with earlier (Oct 06)
> > >>> > > versions of gfortran. Do you find this?
> > >>> > >
> > >>> > Yes I do ! v2-21,58,61-66 have a failure report. Also
> > >>> v3-30,31,57 and 97
> > >>> > fail and so too do v4-8,57,84-88 and v5-63.
> > >>> > Does anyone on the development team see a pattern or are these
> > >>> tests
> > >>> > totally unrelated ?
> > >>> >
> > >>> > I had noticed this with previous editions of abinit but  
> > since they
> > >>> > weren't so many compared to the full range of tests I didn't
> > >>> pay too
> > >>> > much attention.
> > >>> >
> > >>> > It has also been my experience that g95 makes pretty good
> > >>> binaries but
> > >>> > they are painfully slow and the people at AMD have yet to make
> > >>> a g95
> > >>> > compiled ACML for Windows. The one I use is a special hack of a
> > >>> g77
> > >>> > binary libacml to become usable with gfortran. ACML makes it
> > >>> run much
> > >>> > faster. The benchmark tests are run from an x86-64 platform  
> > and my
> > >>> > humble pentium 4 can beat the timings for most of them.
> > >>> >
> > >>> > pgf90 is comparable in performance to gfortran+acml.
> > >>> >
> > >>> > --
> > >>> > Nuno A. G. Bandeira, AMRSC
> > >>> > Graduate researcher and molecular sculptor
> > >>> > Inorganic and Theoretical Chemistry Group,
> > >>> > Faculty of Science
> > >>> > University of Lisbon - C8 building, Campo Grande,
> > >>> > 1749-016 Lisbon,Portugal
> > >>> > http://cqb.fc.ul.pt/intheochem/nuno.html
> > >>> > Doctoral student @ IST,Lisbon
> > >>> > --
> > >>> >
> > >>> >
> > >>>
> > >>>
> > >>> --
> > >>> Pierre-Matthieu Anglade
> > >>>
> > >>
> > >>
> > >> --
> > >> Pierre-Matthieu Anglade
> > >>
> > >
> > >
>
>
> --
> Pierre-Matthieu Anglade