[Debichem-devel] ACESIII-3.0.7 Availability

[Ajith perera]

Hi Michael: You are way ahead of me (I have been busy with few other
things). I
hope you do not mind if I start to address the older issues.  First thing
that
I am very puzzled by is  why you can not use lb in ACES II or dup in
ACESIII.

The dup and lb is provided as a safety measure for the machines that do not
have
matching  (64BIT or 32 BIT integer) vendor provided mathematical libraries.
ACES II  is built with 64BIT integer flags (-i8 on intel) and should be
linked against
the correct 64BIT mathematical libraries. If the vendor does not provide
them
then lb must be used. ACES III is built with 32BIT integers, so it should
be linked against 32BIT libraries. It is very likely all the vendors have
32bit
mathematical libraries, so you can skip dup.

>From this discussion it must be clear that the dup and lb should always
work because you are building them along with the rest of the source. It
may hurt
the performance but they should always work. If the vendor provides the
matching
libs, then it is certainly beneficial to use them but that is not
necessary.

So, I am bit confused. Would you kindly comment on this?

Thanks, Ajith

On Wed, Aug 1, 2012 at 7:41 PM, Michael Banck <mbanck at debian.org> wrote:

> Hi,
>
> On Wed, Aug 01, 2012 at 02:14:55AM +0200, Michael Banck wrote:
> > On Wed, Aug 01, 2012 at 01:46:16AM +0200, Michael Banck wrote:
> > > I now ran the full testsuite, and unfortunately I get a floating point
> > > exception in tran_rhf_ao_sv1.sio:
> > >
> > > | An instruction timer report will be printed
> > > |
> > > | Gather on company_rank succeeded.
> > > | Static pre-defined array #           2  is first used on line
> > > |328
> > > |
> > > |Program received signal SIGFPE: Floating-point exception - erroneous
> > > |arithmetic operation.
> > > |
> > > |Backtrace for this error:
> > > |#0  0x2AEA062F8667
> > > |#1  0x2AEA062F8C34
> > > |#2  0x2AEA06F104EF
> > > |#3  0x447C1C in vtdemo_init_ at vtdemo_init.F:814
> >
> > That line reads
> >
> >                   iproc_company_rank = mod(next_server-1,niocompany)
> >
> > > #0  vtdemo_init (optable=..., noptable=245, array_table=...,
> narray_table=<error reading variable: Cannot access memory at address
> 0xc9>, index_table=..., nindex_table=32,
> > >     segment_table=..., nsegment_table=193, scalar_table=...,
> nscalar_table=13, block_map_table=..., nblock_map_table=27364, proctab=...,
> address_table=..., blocksize=1185921,
> > >     end_nfps=..., nshells=16, scf_energy=438.55129855222071,
> totenerg=0, damp_init=0.19999998807907104, cc_conv=9.9999999999999995e-08,
> scf_conv=9.9999999999999995e-07,
> > >     stabvalue=0, excite=0, eom_tol=0, eom_roots=0, io_company_id=2,
> niocompany=0, need_predef=..., npre_defined=19, dryrun=.TRUE.) at
> vtdemo_init.F:814
> >
> > and niocompany is indeed zero.
>
> Using attached patch, I no longer get a floating point exception, but I
> am not sure whether this is the right fix.
>
> In fact, test case 1.1.3.1 keeps spinning on tran_rhf_ao_sv1.sio with no
> progress.  I also tried running the test suite with mpirun -np 2, but
> there as well I see no progress.
>
>
> Best regards,
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20120802/ebcd58c2/attachment.html>