weird behaviour

[Martin Tee]

Hi,

Looks like your arguments don't match; 9 actual and 10 dummy.

Regards,
Martin

Éric Depagne wrote:
> Le Thursday 02 August 2007 21:00:58 Brooks Moses, vous avez écrit :
>> Éric Depagne wrote:
>>> That's the way I call the function:
>>>
>>> contrib=LINE(wave,nlo,nup,hlambda,t(k),ne(k),nh1(k),nhe1(k),frac)
>> How are these variables declared?
> 
> Unfortunately, most of them are implicit.
>>> And that's the first lines of the function:
>>>       FUNCTION LINE(WAVE,NBLO,NBUP,WAVEH,T,XNE,HNORM,H1FRC,HE1FRC,DOPPLE)
>>>
>>>       REAL KAP0,KAP0RED,KAPRED,KAP0BLUE,KAPBLUE
>>>       REAL*8 WAVEH,WAVE,WCON,EMERGE,WMERGE,WSHIFT,WTAIL
>>>       REAL*8 BLUECUT,WLBLUE,REDCUT,WLRED,EMERGEH
>>>       REAL*8 EHYD(100),CONTH(15)
>>>       REAL*4 DOPPLE
>>>       REAL*8 VACAIR
>>>       real pg
>>>       LOGICAL FIRST
>>>       SAVE
>> In general, it's a good idea to put IMPLICIT NONE at the beginning of
>> all declaration blocks, to catch undeclared variables.
> I agree, but this code is not mine, and it is rougly 20000 lines long, 
> splitted in almost 90 files.
> And some files are written in pure F77, thus rewriting them so everything is 
> readable is not ( unfrtunately) an option.
> 
>> In particular, NBLO, NBUP, T, XNE, HNORM, H1FRC, and HE1FRC are not
>> declared here, and thus will get an implicit type.  My guess is that
>> this does not match the type that they have in the caller, and that the
>> mismatch is such that the function's location for DOPPLE is off the end
>> of the call stack that the caller supplies.
>>
>> In any case, reducing this to a minimal complete example should enable
>> you to find the problem.  (Steve's suggestions for warning options may
>> find the problem as well, though I'm not sure of that in this case.)
> I'll try his suggestion, hoping it will show the things missing.
> 
> Éric.
>> - Brooks
> 
> 
>