Prev: how to get the output of call system in a variable
Next: Is there a log framwork for fortran?
From: Richard Maine on 3 Mar 2010 19:07
Nathan <ngreco32(a)gmail.com> wrote:

> > > DIMENSION ACENG(10),TCFG(10),PCG(10),GCONC(10)
....
> Ah, I left out a piece of information that is probably important.
> From the main function:
> DIMENSION ACENG(5),TCGF(5),PCG(5),GCONC(5)
> (the 0-based ones are the same as in the subroutine)
>
> That appears to be the problem.

Ah. Seems likely. I read this just after sending my other post in this
thread. (Took me a while to write and this one came during that time).

Note that this pretty much is in line with several of the comments.

1. That code in the calling routine was likely to be relevant.

2. Exceeding array bounds.

3. Argument mismatches between actual and dummy.

Looks like all 3 of those applied.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Nathan on 3 Mar 2010 19:38
Although my problem has been solved... here you go:

In the main function AND subroutine declarations, nfsteps was equal to
3.
Later within the subroutine, nfsteps was changed to 4 to help the
person writing the code (me, right now) to understand that nfsteps =
the number of fuels = 4, rather than nfsteps+1 = number of fuels...


I left out the code because there is a lot of it.
The call to the subroutine is as follows:
CALL MULTCOMP(2, nfuel, ngas, 0, 0, XL, ret_XLIQ, ret_TSAT,
1 ret_BT, NCOMPG,ICOMPG,MWGG,TCFG,PCG,ACENG,GCONC,TCGC,tanang,
2 FUELNAME,ICOMPF,MWFF,TBF,TCFF,PCF,ZCF,ACENF,ZRA,ACENWF,VCHF,
3 zzF,TFCC,nfsteps,FCONC)

And the SUBROUTINE declaration is as follows:
SUBROUTINE MULTCOMP(IDB,NFUEL,NGAS,MTYPE,MNUM,XL,XLIQret,TSATret,
1BTret,NCOMPG,ICOMPG,MWGG,TCFG,PCG,ACENG,GCONC,TCGC,tanang,FUELNAME,
1ICOMPF,MWFF,TBF,TCFF,PCF,ZCF,ACENF,ZRA,ACENWF,VCHF,zzF,TFCC,
1nfsteps,FCONC)


"In general, w/o trying to delve into it in much depth w/o the missing
information, undoubtedly the various arrays are stored in proximity to
each other and the indices of one are tromping on another's space.
This, as noted above, is undoubtedly owing to a mismatch in
declarations
and the changing sizes assumed on loop bounds. "

You hit it on the nail. Thanks dpb.

Anyways, just to clear things up a little bit:
In the main function, the gas arrays (ACENG,PCG, etc) were only of
length 5, whilst in the subroutine they were declared as length 10...
The reason that arrays were sharing values IS because the program
reserved certain memory locations for the arrays within the main
function, and the arrays within the subroutine fell beyond those
bounds and started writing to memory that was out of their scope (i.e.
in memory locations of arrays within the main function).
Perhaps that's not too clear, but it seems to make sense to me now.

Thanks for your input.

Also note:
There is a mix of f90 and 70's style because this code has been
manipulated for quite some time.

I was never taught how to code in Fortran and have (since last June)
been inching my way into it, trying to debug this OLD code that has
been passed onto me.

I'm starting to love these newsgroups more and more each day...

-Nathan
From: dpb on 3 Mar 2010 20:00
Nathan wrote:
> Although my problem has been solved... here you go:
>
....

> I left out the code because there is a lot of it.

But, while various respondents were able to provide enough input to
point you in the right direction in this case (which really is pretty
straightforward), that isn't always the case and w/o the actual code as
Richard points out one is relying on an interpretation which is
undoubtedly flawed or there wouldn't be a reason for asking a question.

So, your time communicating to the group and likelihood of success as
you proceed will be reduced and increased, respectively if you just go
ahead and post _JUDICIOUS_ pieces of the code initially.

That doesn't mean just past the whole routine but it does mean the
pertinent declarations in _BOTH_ a calling and called routine, etc.

It's that data that's required to see if there really is a mismatch or
not; w/o it w/ experience one can make some reasonable assumptions of
where may have gone wrong and be right on occasion but it's still not a
certainty unless have actual data to confirm/deny suspicions.

> The call to the subroutine is as follows:
> CALL MULTCOMP(2, nfuel, ngas, 0, 0, XL, ret_XLIQ, ret_TSAT,
> 1 ret_BT, NCOMPG,ICOMPG,MWGG,TCFG,PCG,ACENG,GCONC,TCGC,tanang,
> 2 FUELNAME,ICOMPF,MWFF,TBF,TCFF,PCF,ZCF,ACENF,ZRA,ACENWF,VCHF,
> 3 zzF,TFCC,nfsteps,FCONC)
>
> And the SUBROUTINE declaration is as follows:
> SUBROUTINE MULTCOMP(IDB,NFUEL,NGAS,MTYPE,MNUM,XL,XLIQret,TSATret,
> 1BTret,NCOMPG,ICOMPG,MWGG,TCFG,PCG,ACENG,GCONC,TCGC,tanang,FUELNAME,
> 1ICOMPF,MWFF,TBF,TCFF,PCF,ZCF,ACENF,ZRA,ACENWF,VCHF,zzF,TFCC,
> 1nfsteps,FCONC)
....

What would be needed as well is the declarations in both program units
and such other "minor" details as the IMPLICIT statements if present, etc.

HTH for future...and glad found the specific problem

-dpb

--
From: Nathan on 3 Mar 2010 20:26
On Mar 3, 5:00 pm, dpb <n...(a)non.net> wrote:
> Nathan wrote:
> > Although my problem has been solved... here you go:
>
> ...
>
> > I left out the code because there is a lot of it.
>
> But, while various respondents were able to provide enough input to
> point you in the right direction in this case (which really is pretty
> straightforward), that isn't always the case and w/o the actual code as
> Richard points out one is relying on an interpretation which is
> undoubtedly flawed or there wouldn't be a reason for asking a question.
>
> So, your time communicating to the group and likelihood of success as
> you proceed will be reduced and increased, respectively if you just go
> ahead and post _JUDICIOUS_ pieces of the code initially.
>
> That doesn't mean just past the whole routine but it does mean the
> pertinent declarations in _BOTH_ a calling and called routine, etc.
>
> It's that data that's required to see if there really is a mismatch or
> not; w/o it w/ experience one can make some reasonable assumptions of
> where may have gone wrong and be right on occasion but it's still not a
> certainty unless have actual data to confirm/deny suspicions.
>
> > The call to the subroutine is as follows:
> >            CALL MULTCOMP(2, nfuel, ngas, 0, 0, XL, ret_XLIQ, ret_TSAT,
> >    1       ret_BT, NCOMPG,ICOMPG,MWGG,TCFG,PCG,ACENG,GCONC,TCGC,tanang,
> >      2     FUELNAME,ICOMPF,MWFF,TBF,TCFF,PCF,ZCF,ACENF,ZRA,ACENWF,VCHF,
> >      3    zzF,TFCC,nfsteps,FCONC)
>
> > And the SUBROUTINE declaration is as follows:
> >    SUBROUTINE MULTCOMP(IDB,NFUEL,NGAS,MTYPE,MNUM,XL,XLIQret,TSATret,
> >    1BTret,NCOMPG,ICOMPG,MWGG,TCFG,PCG,ACENG,GCONC,TCGC,tanang,FUELNAME,
> >      1ICOMPF,MWFF,TBF,TCFF,PCF,ZCF,ACENF,ZRA,ACENWF,VCHF,zzF,TFCC,
> >      1nfsteps,FCONC)
>
> ...
>
> What would be needed as well is the declarations in both program units
> and such other "minor" details as the IMPLICIT statements if present, etc..
>
> HTH for future...and glad found the specific problem
>
> -dpb
>
> --

BTW, I did give the declarations of the relevant data for each program
unit, just not all together.

In my second post, I posted the differing declarations in the main
function and stated that the others were the same in both.

I guess I just don't know how little is TOO little information to give
and how much is TOO much information to give. My program is scattered
with relevant information, but within this relevant information is
irrelevant information that would (probably) prompt further queries.

You're right, however, that what I assume to be the problem is not
necessarily the problem, and posting the code will lead to the correct
problem (and hopefully correction OF the problem).

Thanks for your insight.

-Nathan
From: Richard Maine on 3 Mar 2010 20:50
Nathan <ngreco32(a)gmail.com> wrote:

> In my second post, I posted the differing declarations in the main
> function and stated that the others were the same in both.

It wasn't the case here, but it isn't at all unusual for descriptions
like "the same" to cover up a problem. It can easily be that the poster
just didn't see the difference. That kind of thing happens all the time
- that your eyes just see what they think should be there instead of
what is actually there. My eyes aren't imune to that either (not by a
long shot). Those can be the easiest kinds of problems for someone else
to help with. Or it can be that what you thought was essentially the
same turned out to have a difference that you didn't appreciate.

As noted, that wasn't he case here, but it happens often enough that any
time I see any description at all substituted for actual code, it sets
off an internal warning light. Yes, that definitely includes
descriptions like "the same".

I'd much rather see both copies so that I can verify they are the same.
It might seem like showing one copy and saying that the other was "the
same" could save work, but it doesn't. It certainly doesn't save work if
that covers up the problem. But even if the description is accurate,
that still slows me down because of needing to consider the possibility
that it wasn't accurate.

Just for future reference.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: how to get the output of call system in a variable
Next: Is there a log framwork for fortran?