[molpro-user] Compiling on AMD

[Andy May]

Thorsten,

The file user.F should contain almost nothing, just a dummy routine for 
development. This leads me to conclude that you are using a modified 
version of the source code. I of course have no way to know what has 
been modified, and suggest you contact whoever gave you access to the 
modified source code for advice.

We have seen these testjob failures before, but quite a long time ago. 
The SHA1 tag you gave is from the end of April, and there have been 
hundreds of commits to the code since then. Stable versions 2010.1 and 
2012.1 do not have these testjob failures, or indeed the latest 
development snapshot. You need to update to the latest version of the 
source code and then everything should work.

Best wishes,

Andy

On 04/09/12 22:10, Thorsten Stolper wrote:
> Hi Andy,
>
> sorry for the delay and thanks for the reply. Recently I managed to
> compile it, though some issues remain of course. To do that, I added
> some includes ("common/maxbfn" and "common/nbo") to the functions in
> user.F that were giving the errors (region_spectra, noi_calculation). I
> admit that I did it more or less not knowing if that's the right thing
> to do. But after that it compiled fine. The testjobs showed the same
> errors though and some additional were introduced, which resulted in
> bogus results for some jobs. That also seems to be a cause of the Open64
> compiler suite, since it even occurred with the Intel MKL and Open64.
>
> Last time I really didn't think about the possibility, that my
> development version wasn't up to date ;). I actually just copied the
> directory to another computer and recompiled it, so it's most certainly
> not the newest snapshot. Nevertheless, this should be the SHA1:
> cf690dd233fe1b6e8478b1244842594ccedb38c8
>
> I attached the files you requested. For the Intel compiled and the
> Open64 version I also attached textfiles with a list of testjob
> failures. The output file is from the Intel version. There might be
> outputs with different errors though. If you also need examples for
> those, I'll be happy to send them in another mail.
>
> Thanks and best wishes,
> Thorsten
>
>
> On 08/21/2012 11:57 AM, Andy May wrote:
>> Thorsten,
>>
>> I have just this week tested Molpro with AMD 4.5.2 compilers and found
>> no problems in building 2010.1 or a serial copy of the development
>> branch. There are problems with building the parallel development
>> version (which are more generic and affect other compilers). Certainly
>> there were no problems compiling file user.F.
>>
>> Can you send the CONFIG file for the build? Also, what is the git SHA1
>> for the development clone you have?
>>
>> If you also send the Intel CONFIG file, list of testjob failures, and
>> one of the failing output files then I will take a look.
>>
>> Best wishes,
>>
>> Andy
>>
>> On 21/08/12 08:32, Thorsten Stolper wrote:
>>> Hi all,
>>>
>>> I hope this wasn't already discussed and I was just too ignorant to find
>>> it.
>>> I got a development version of Molpro and would like to compile it on an
>>> AMD machine. That's why I would ultimately like to use the AMD Open64
>>> compiler suite with their ACML library. It compiles fine using the Intel
>>> Composer XE compiler suite and their MKL. But if I just swap their
>>> library for ACML, I get a linkage error at the end (though I used the
>>> AMD binaries for the Intel compilers).
>>> If I use OpenCC and OpenF90 however, I already get errors at
>>> compilation. This reads:
>>>
>>> "Assignment of a LOGICAL(KIND=8) expression to a REAL(KIND=8) variable
>>> is not allowed."
>>>
>>> in src/util/user.F
>>> Are those problems known and is there (going to be) a fix for that, or
>>> am I missing something?
>>> Btw, I'm using the newest versions of the compiler suite (4.5.2) and
>>> library (5.1.0).
>>>
>>> And something different I noticed with the intel-compiled version:
>>> If I run the tests I'm getting a few calculations which abort with
>>> errors. But all of the just complain about too few RAM that was
>>> assigned. So I wonder if that should just be changed in the input, or if
>>> there's some inefficiencies in my compiled version (because there's so
>>> many of them).
>>>
>>> thanks and best wishes,
>>> Thorsten
>>> _______________________________________________
>>> Molpro-user mailing list
>>> Molpro-user at molpro.net
>>> http://www.molpro.net/mailman/listinfo/molpro-user
>
>