Hi Michael: You are way ahead of me (I have been busy with few other things). I<br>hope you do not mind if I start to address the older issues.  First thing that<br>I am very puzzled by is  why you can not use lb in ACES II or dup in ACESIII. <br>
<br>The dup and lb is provided as a safety measure for the machines that do not have<br>matching  (64BIT or 32 BIT integer) vendor provided mathematical libraries. <br>ACES II  is built with 64BIT integer flags (-i8 on intel) and should be linked against <br>
the correct 64BIT mathematical libraries. If the vendor does not provide them<br>then lb must be used. ACES III is built with 32BIT integers, so it should<br>be linked against 32BIT libraries. It is very likely all the vendors have 32bit<br>
mathematical libraries, so you can skip dup. <br><br>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<br>the performance but they should always work. If the vendor provides the matching <br>
libs, then it is certainly beneficial to use them but that is not necessary. <br><br>So, I am bit confused. Would you kindly comment on this?<br><br>Thanks, Ajith<br><br><div class="gmail_quote">On Wed, Aug 1, 2012 at 7:41 PM, Michael Banck <span dir="ltr"><<a href="mailto:mbanck@debian.org" target="_blank">mbanck@debian.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On Wed, Aug 01, 2012 at 02:14:55AM +0200, Michael Banck wrote:<br>
> On Wed, Aug 01, 2012 at 01:46:16AM +0200, Michael Banck wrote:<br>
> > I now ran the full testsuite, and unfortunately I get a floating point<br>
> > exception in tran_rhf_ao_sv1.sio:<br>
> ><br>
> > | An instruction timer report will be printed<br>
> > |<br>
> > | Gather on company_rank succeeded.<br>
> > | Static pre-defined array #           2  is first used on line<br>
> > |328<br>
> > |<br>
> > |Program received signal SIGFPE: Floating-point exception - erroneous<br>
> > |arithmetic operation.<br>
> > |<br>
> > |Backtrace for this error:<br>
> > |#0  0x2AEA062F8667<br>
> > |#1  0x2AEA062F8C34<br>
> > |#2  0x2AEA06F104EF<br>
> > |#3  0x447C1C in vtdemo_init_ at vtdemo_init.F:814<br>
><br>
> That line reads<br>
><br>
>                   iproc_company_rank = mod(next_server-1,niocompany)<br>
><br>
> > #0  vtdemo_init (optable=..., noptable=245, array_table=..., narray_table=<error reading variable: Cannot access memory at address 0xc9>, index_table=..., nindex_table=32,<br>
> >     segment_table=..., nsegment_table=193, scalar_table=..., nscalar_table=13, block_map_table=..., nblock_map_table=27364, proctab=..., address_table=..., blocksize=1185921,<br>
> >     end_nfps=..., nshells=16, scf_energy=438.55129855222071, totenerg=0, damp_init=0.19999998807907104, cc_conv=9.9999999999999995e-08, scf_conv=9.9999999999999995e-07,<br>
> >     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<br>
><br>
> and niocompany is indeed zero.<br>
<br>
</div>Using attached patch, I no longer get a floating point exception, but I<br>
am not sure whether this is the right fix.<br>
<br>
In fact, test case 1.1.3.1 keeps spinning on tran_rhf_ao_sv1.sio with no<br>
progress.  I also tried running the test suite with mpirun -np 2, but<br>
there as well I see no progress.<br>
<br>
<br>
Best regards,<br>
<br>
Michael<br>
</blockquote></div><br>