Prev: building a project and creating a dynamik link library
Next: DRAIN-2DX compile
From: Les on 21 Sep 2005 09:51
"nancy80" <nkazantzi(a)yahoo.com> wrote in message
news:2d59bab58794bc559757f72eb046306d(a)localhost.talkaboutprogramming.com...
> Can you have a look in the source code?You can find it
> in:http://nisee.berkeley.edu/software/drain2dx/

OK
I'm using DVF on Windows XP. Intel processor.
I downloaded the source and one by one set up projects for each
subdirectory. I got as far as ELEM07 and got the alignment errors you
reported.
The "offending" include file is infel07.h common /infel/

Several of the include files (in subdirectory common and other ELEMxx
directories) have the named common block "infel".
And each include file has a different set of variable names for that common.

There is no "implicit none", neither are the variables given explicit data
types so assumed data types will be used [integer (for variable names
beginning with I through N) and real (variable names beginning with A
through H, and O though Z) ]

Without looking more closely at the code I cannot tell whether the various
uses of the common blocks are isolated and independant, or whether data
values are carried across from one sub-directory to another (in the CALLing
sense).

So there appears to be no simple answer to your problem. Though since they
are warnings it should be ok to ignore them.

As an aside, and purely a style issue :
When I used common (before modules) I preferred to have one common for
integer, one for real, one for logical and one for character data.
eg
common /infel_I/ .... integer data
common /infel_R/ .... real data
etc.
Making life much easier for adding/removing items without too many of these
alignment problems.


Les


From: Tim Prince on 21 Sep 2005 10:06
Les wrote:
> "nancy80" <nkazantzi(a)yahoo.com> wrote in message
> news:2d59bab58794bc559757f72eb046306d(a)localhost.talkaboutprogramming.com...
>
>>Can you have a look in the source code?You can find it
>>in:http://nisee.berkeley.edu/software/drain2dx/
>
>
> OK
> I'm using DVF on Windows XP. Intel processor.
> I downloaded the source and one by one set up projects for each
> subdirectory. I got as far as ELEM07 and got the alignment errors you
> reported.
> The "offending" include file is infel07.h common /infel/
>
> Several of the include files (in subdirectory common and other ELEMxx
> directories) have the named common block "infel".
> And each include file has a different set of variable names for that common.
>
> There is no "implicit none", neither are the variables given explicit data
> types so assumed data types will be used [integer (for variable names
> beginning with I through N) and real (variable names beginning with A
> through H, and O though Z) ]
>
> Without looking more closely at the code I cannot tell whether the various
> uses of the common blocks are isolated and independant, or whether data
> values are carried across from one sub-directory to another (in the CALLing
> sense).
>
> So there appears to be no simple answer to your problem. Though since they
> are warnings it should be ok to ignore them.
>
> As an aside, and purely a style issue :
> When I used common (before modules) I preferred to have one common for
> integer, one for real, one for logical and one for character data.
> eg
> common /infel_I/ .... integer data
> common /infel_R/ .... real data
> etc.
> Making life much easier for adding/removing items without too many of these
> alignment problems.
>
>
The standard did not support half-size integers, or use of CHARACTER
along with
numeric data types in COMMON. As this application shows, it would be
possible
to combine violations of the standard and standard practice with lack of
adequate testing, so as to ensure unreliability on future platforms.
From: glen herrmannsfeldt on 21 Sep 2005 14:17
nancy80 wrote:

> Glen thanks again for your reply.I am on a x86 Intel machine. No luck until
> now.I am trying to use the Salford Plato 3 compiler to see if something
> will change.It seems my problem requires advance programming skills i do
> not have. While ignoring the warnings and build the executable ,trying to
> run the program produces an error for array bounds.Any other ideas?

On x86 intel processors alignment is a warning, so for now don't
worry so much about them.

If it is just alignment it should not cause array bounds problems.

Worse than alignment problems, though, is having different COMMON
blocks in different routines not matching up with each other.
That shouldn't be compiler dependent, but it is possible, and
could easily cause array bounds problems.

If you can find out which compiler was used before to supposedly
correctly compile this, I would try to use that. Even so, I
would not be surprised if there are a large number of bugs left
in this program. At one point I saw a ten line COMMON statement
followed by comments describing how many integer, real, and
character variables were on each of nine lines. It seems that
some had been added without updating the comment.

It might be that many changes have been made by many different
people without understanding the interaction between them.
To really fix this program would probably take years.

-- glen

First  |  Prev  | 
Pages: 1 2 3
Prev: building a project and creating a dynamik link library
Next: DRAIN-2DX compile