[mesa-users] Problem building library adipls on my first MESA install
Simon Jeffery
csj at arm.ac.uk
Wed Sep 17 17:11:54 EDT 2014
HI Rob..
You seem to have identified the problem.
armac27%adipls> which gfortran
/Applications/mesasdk/bin/gfortran
armac27%adipls> ./build_and_test
cd ../adipack.c/adiajobs; make; cd ../../adipack.c/adipls; make; cp libadipls.a ../../make
gfortran -fbounds-check -c -o asymp-scale.d.o asymp-scale.d.f
cd ./sr; make
gfortran -fbounds-check -c -o inrnge.o inrnge.f
gfortran -fbounds-check -c -o intmdl.d.o intmdl.d.f
...
armac27%adipls> echo $FFLAGS
-fbounds-check
armac27%adipls> grep FFLAGS ~/.cshrc
setenv FFLAGS "-fbounds-check" # check initilisation
So this is coming from my own .cshrc file.
I do a lot of fortran development and I find array bounds checking to be essential ...
one would be mad to think of developing safe code without it. But maybe you want to
live dangerously! At the moment I run mesasdk_init.csh at the time of working with mesa;
it obviously isn't resetting FFLAGS to anything. 'make' will use $FFLAGS with fortran if it is defined.
Since I can't be the only person who uses FFLAGS, I would suggest ensuring
that the mesasdk_init.csh resets FFLAGS to what is assumed/required - or removes it altogether (unsetenv).
Having said that ...
armac27%adipls> unsetenv FFLAGS
armac27%adipls> ./clean
armac27%adipls> ./build_and_test
cd ../adipack.c/adiajobs; make; cd ../../adipack.c/adipls; make; cp libadipls.a ../../make
gfortran -c -o asymp-scale.d.o asymp-scale.d.f
cd ./sr; make
gfortran -c -o inrnge.o inrnge.f
gfortran -c -o intmdl.d.o intmdl.d.f
...
runs successfully.
and
armac27%mesa-r6794> ./install =>
************************************************
************************************************
************************************************
MESA installation was successful
************************************************
************************************************
************************************************
So tomorrow I will try to make some stars.
Cheers,
Simon
On 17 Sep 2014, at 19:19, Robert FARMER <rjfarmer at asu.edu> wrote:
> Okay so i can reproduce this if i turn on -fbounds-check in the adipls makefiles. Which suggests the problems always been here and through the fun of implicit variables, common blocks and f77 code it somehow just "works". But then the question is why your triggering this? Can you do:
> which gfortran
>
> Lets just make sure your picking up the sdk gfortran and not your system compiler.
>
> Also when adipls is building are the lines similar to this?
> gfortran -c -o adirhs.c.d.o adirhs.c.d.f
> ie there shouldn't be any compiler flags other than -o and -c
>
> Rob
>
>
> On Wed, Sep 17, 2014 at 11:03 AM, Simon Jeffery <csj at arm.ac.uk> wrote:
>
> OK - done that
>
> Last few lines of output in .list:
>
> Log in standard name: adipls-status.log
> openf - statusu 2
> openf - statusu 2
> openf - statuso 2
> openf - statuso 2
>
> So that looks fine.
> The output from ./build_and_test now looks like:
>
>
> At line 110 of file readml.n.d.f
> Fortran runtime error: Index '2' of dimension 2 of array 'aa1' above upper bound of 1
>
> FAILED
>
> ..
> Simon
>
>
> On 17 Sep 2014, at 18:50, Robert FARMER <rjfarmer at asu.edu> wrote:
>
>> Hi
>> So i'd like you to try this please to see if it works:
>>
>> The second set of openf calls is occurring in adipack.c/adipls/readml.n.d.f lines 74 and 80.
>>
>> It appears they are passing in status as a single character string rather than the expected two character string (Notice how the statement si got you to print the 2 and the 1 are misaligned there's an extra blank space)
>>
>> So i'd like you to try replacing both calls in adipack.c/adipls/readml.n.d.f
>> call openf(ids,'o','u')
>> with
>> call openf(ids,'o ','u')
>>
>> and then do ./clean && ./build_and_test and lets see if this works
>>
>> Rob
>>
>> On Wed, Sep 17, 2014 at 10:36 AM, Robert FARMER <rjfarmer at asu.edu> wrote:
>> So running on my machine the differences occurs at the end, i have:
>>
>> Log in standard name: adipls-status.log
>> openf - statusu 2
>> openf - statusu 2
>> openf - statuso 1
>> openf - statuso 1
>>
>> So i get an extra openf call. Tracking down the "Log in standard name: adipls-status.log" string, thats in adipack.c/adipls/adipls/c.d.f line 1510 but that only does the first 2 openf calls (the openfc calls arn't called). So now to track down where the next two openf calls occur and see why you don't call the final openf
>>
>> Rob
>>
>>
>> On Wed, Sep 17, 2014 at 3:28 AM, Simon Jeffery <csj at arm.ac.uk> wrote:
>> It would be handy to have the adipls package -- I want to do some pulsation work...
>> I downloaded a clean version of mesa-r6794, but not the sdk kit,
>> and inserted the diagnostic line ... code and output below.
>>
>> Hope this helps, Simon
>>
>>
>> Around line 360 of adipls/adipack.c/gensr/ofiles.c.f
>>
>>
>> c
>> c diagnostic output
>> c
>> if(istdpr.gt.0) write(istdpr,110) id,stat1,form1
>> c
>> else
>> write(*,*) 'openf - status',status,len(status)
>> if(status(1:2).eq.'ut'.or.status(1:2).eq.'nt'.or.
>> * status(1:2).eq.'ot') then
>> files=file(nfin)
>> if(files.ne.'/dev/null') then
>>
>>
>> Output in adipls/test/.list (took a while to track this down!)
>>
>>
>> cntrd?
>> mod.osc.int.out.dgn
>> ifind,xmod,imlds,in,nprmod?
>> -1 0.0000000000000000 2 1 0
>> xtrnct,ntrnsf,imdmod?
>> 0.0000000000000000 0 0
>> el,nsel,els1,dels,dfsig1,dfsig2,nsig1,nsig2?
>> 1.0000000000000000 0 10.000000000000000 1.0000000000000000 0.0000000000000000 0.0000000000000000 1 1
>> itrsig,sig1,istsig,inomd1,itrds?
>> 0 10.000000000000000 1 1 10
>> dfsig,nsig,iscan,sig2?
>> 0.0000000000000000 1 1 0.0000000000000000
>> eltrw1, eltrw2, sgtrw1, sgtrw2?
>> 0.0000000000000000 -1.0000000000000000 0.0000000000000000 -1.0000000000000000
>> cgrav?
>> 6.6732000000000005E-008
>> iplneq,iturpr,icow,alb?
>> 0 0 0 1.0000000000000000
>> istsbc,fctsbc,ibotbc,fcttbc?
>> 1 0.0000000000000000 0 0.0000000000000000
>> mdintg,iriche,xfit,fcnorm,eps,epssol,itmax,dsigre?
>> 1 0 0.50000000000000000 0.50000000000000000 2.0000000000000001E-013 1.0000000000000001E-005 8 0.0000000000000000
>> fsig,dsigmx,irsevn,xmnevn,nftmax,itsord?
>> 1.0000000000000000E-003 0.10000000000000001 2 0.0000000000000000 3 0
>> istdpr,nout,nprcen,irsord,iekinr?
>> 6 50 0 0 0
>> iper,ivarf,kvarf,npvarf,nfmode?
>> 0 1 2 0 0
>> irotkr,nprtkr,igm1kr,npgmkr,ispcpr?
>> 0 0 0 50 0
>> icaswn, sigwn1, sigwn2, frqwn1, frqwn2, iorwn1, iorwn2, frlwn1, frlwn2?
>> -1 0.0000000000000000 -1.0000000000000000 0.0000000000000000 -1.0000000000000000 0 -1 0.0000000000000000 -1.0000000000000000
>> openf - statusu 2
>>
>> Opening standard print on unit 9 file ttt.adipls.prt
>>
>>
>> ----------------------------------------------
>>
>>
>> cntrd
>> mod.osc.cst.int.out @
>> ifind,xmod,imlds,in,nprmod
>> -1 0.0000000000000000 2 1 0 @
>> xtrnct,ntrnsf,imdmod
>> 0.0000000000000000 0 0 @
>> el,nsel,els1,dels,dfsig1,dfsig2,nsig1,nsig2
>> 0.0000000000000000 3 0.0000000000000000 1.0000000000000000 0.0000000000000000 0.0000000000000000 1 1 @
>> itrsig,sig1,istsig,inomd1,itrds
>> 1 220.00000000000000 1 1 10 @
>> dfsig,nsig,iscan,sig2
>> 0.0000000000000000 2 100 1000.0000000000000 @
>> eltrw1, eltrw2, sgtrw1, sgtrw2
>> 0.0000000000000000 -1.0000000000000000 0.0000000000000000 -1.0000000000000000 @
>> cgrav
>> 6.6723200000000006E-008 @
>> iplneq,iturpr,icow,alb
>> 0 0 0 1.0000000000000000 @
>> istsbc,fctsbc,ibotbc,fcttbc
>> 1 0.0000000000000000 0 0.0000000000000000 @
>> mdintg,iriche,xfit,fcnorm,eps,epssol,itmax,dsigre
>> 5 0 0.98999999999999999 0.50000000000000000 2.0000000000000001E-013 1.0000000000000001E-005 8 0.0000000000000000 @
>> fsig,dsigmx,irsevn,xmnevn,nftmax,itsord
>> 1.0000000000000000E-003 0.10000000000000001 2 0.0000000000000000 3 -1 @
>> istdpr,nout,nprcen,irsord,iekinr
>> 9 10 0 20 0 @
>> iper,ivarf,kvarf,npvarf,nfmode
>> 1 1 2 0 0 @
>> irotkr,nprtkr,igm1kr,npgmkr,ispcpr
>> 0 0 0 50 0 @
>> icaswn, sigwn1, sigwn2, frqwn1, frqwn2, iorwn1, iorwn2, frlwn1, frlwn2
>> 10010 0.0000000000000000 -1.0000000000000000 0.0000000000000000 -1.0000000000000000 -5000 100 0.0000000000000000 -1.0000000000000000 @
>>
>> 20 not found
>>
>> List of files available:
>> 2 amdl.mesa
>> 9 ttt.adipls.prt
>> 11 agsm.mesa
>> 15 ttt.adipls.ssm
>> 16 ttt.adipls.fsm
>>
>>
>> Log in standard name: adipls-status.log
>> openf - statusu 2
>> openf - statusu 2
>> openf - statuso 1
>>
>>
>>
>>
>>
>>
>>
>> On 17 Sep 2014, at 01:00, Robert FARMER <rjfarmer at asu.edu> wrote:
>>
>>> So, i cant reproduce this, so there's two options
>>>
>>> a) As long as you don't want to use adipls we can skip the tests. Go to adipls/build_and_test/ on line 35 (./ck >& diff.txt) comment it out (#./ck >& diff.txt)
>>>
>>> b) if you dont mind helping me track down the problem, can you add a write(*,*) status,len(status)
>>> before the if block so we can see what status contains
>>>
>>> Rob
>>>
>>> On Tue, Sep 16, 2014 at 12:35 PM, Robert FARMER <rjfarmer at asu.edu> wrote:
>>> No, that's just the documentation being out of date. gcc 4.10 is the current sdk version
>>>
>>> Rob
>>>
>>> On Tue, Sep 16, 2014 at 12:25 PM, Simon Jeffery <csj at arm.ac.uk> wrote:
>>> I'll check tomorrow - but these were both clean first time downloads
>>> as I am new to MESA. The online docs (prereqs and installation)
>>> says that mesa sdk should fix gcc at version 4.9, but I found it gave
>>> me 4.10; is this something that should concern me?
>>>
>>> Simon
>>>
>>> On 16 Sep 2014, at 19:29, Robert FARMER <rjfarmer at asu.edu> wrote:
>>>
>>>> Hmm, interesting I'll have a look. Adipls isn't normally a problem. The only thing i can think off for the moment while i have a look is to try a clean checkout of mesa and the sdk, just in case something went wrong.
>>>>
>>>> Rob
>>>
>>>
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mesastar.org/pipermail/mesa-users/attachments/20140917/7108601e/attachment.html>
More information about the Mesa-users
mailing list