 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
JohnCampbell
Joined: 16 Feb 2006
Posts: 2625
Location: Sydney
|
 Posted: Thu Jul 22, 2010 12:33 pm Post subject: |
 |
|
Paul,
Sorry to continue with this; My understanding is that "No shape" is required as they are both vectors, although we do need their size, which I assume /check provides.
When compiling with /check, the call "get_angle_props (tprop(9:12), angle_props)" needs to say that "tprop(9:12)" is a vector of length 4 and "angle_props" is a vector of length 9.
The length 4 is not being correctly provided. The value of nd = size(dimen) gives a value of 1.
Is "call get_angle_props (tprop(9:12), angle_props)" the same as
"call get_angle_props (tprop(9:12), angle_props(1:9) )" ?
Or am I wrong in assuming angle_props means the same as angle_props(1:9) as a subroutine argument ?
It is my assumption that tprop(9:12) should be equivalent to a real*8 1-dimensional array of length 4, but that is not happening. Am I wrong in assuming this ? I thought array sections were themselves arrays.
I again changed the program, and ran it on Ver 4.9.1 with /check /lgo and got some interesting results:
| Code: |
INTEGER*4 SEC_TYPE, UPROP(13)
REAL*8 TPROP(13)
!
tprop = 0
tprop(9:10) = .100
tprop(11:12) = .005
call SECTION_PROP (SEC_TYPE, TPROP, UPROP)
end
SUBROUTINE SECTION_PROP (SEC_TYPE, TPROP, UPROP)
!
! calculate section properties for generic section type
!
INTEGER*4 SEC_TYPE, UPROP(13)
REAL*8 TPROP(13)
real*8 angle_props(9)
!
call get_angle_props (tprop, angle_props, 'tprop, angle_props ')
call get_angle_props (tprop, angle_props(1:9), 'tprop, angle_props(1:9) ')
call get_angle_props (tprop(1:13), angle_props, 'tprop(1:13), angle_props ')
call get_angle_props (tprop, angle_props(4:6), 'tprop, angle_props(4:6) ')
call get_angle_props (tprop, angle_props(2:7), 'tprop, angle_props(2:7) ')
call get_angle_props (tprop, angle_props(1:6), 'tprop, angle_props(1:6) ')
call get_angle_props (tprop(1:13), angle_props(4:6), 'tprop(1:13), angle_props(4:6) ')
call get_angle_props (tprop(1:), angle_props(5:), 'tprop(1:), angle_props(5:) ')
call get_angle_props (tprop(1:8), angle_props(4:6), 'tprop(1:8), angle_props(4:6) ')
call get_angle_props (tprop(4:8), angle_props(4:7), 'tprop(4:8), angle_props(4:7) ')
!
100 RETURN
!
END SUBROUTINE SECTION_PROP
subroutine get_angle_props ( dimen, props, desc )
!
! calculate the properties of an (un)equal angle
!
real*8 dimen(*), props(*)
character desc*(*)
integer nd, np
!
nd = size (dimen)
np = size (props)
write (*,*) 'nd = ',nd,' np = ',np, ' ', desc
!
RETURN
END
|
The local array "angle_props" is treated differently that the argument array "tprop"
It would appear that any angle_props(3:y) gets the same length, irrespective of the value of y,
while any value of tprop(x:y) gets a length of 1
To me this shows that /check is not including the correct length
John |
|
| Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006
Posts: 2625
Location: Sydney
|
| Posted: Thu Jul 22, 2010 1:16 pm Post subject: |
|
|
run results are
| Code: |
[FTN95/Win32 Ver. 4.9.0 Copyright (C) Silverforst Ltd 1993-2005]
NO ERRORS [<main program> FTN95/Win32 v4.9.0]
0014) INTEGER*4 SEC_TYPE, UPROP(13)
WARNING - The argument SEC_TYPE has not been used
WARNING - The argument UPROP has not been used
0029) 100 RETURN
WARNING - Label 100 is declared, but not used
NO ERRORS, 3 WARNINGS [<SECTION_PROP> FTN95/Win32 v4.9.0]
NO ERRORS [<GET_ANGLE_PROPS> FTN95/Win32 v4.9.0]
Creating executable: C:\John\test\lgotemp@.exe
Program entered
nd = 13 np = 9 tprop, angle_props
nd = 13 np = 9 tprop, angle_props(1:9)
nd = 1 np = 9 tprop(1:13), angle_props
nd = 13 np = 6 tprop, angle_props(4:6)
nd = 13 np = 8 tprop, angle_props(2:7)
nd = 13 np = 9 tprop, angle_props(1:6)
nd = 1 np = 6 tprop(1:13), angle_props(4:6)
nd = 1 np = 5 tprop(1:), angle_props(5:)
nd = 1 np = 6 tprop(1:8), angle_props(4:6)
nd = 1 np = 6 tprop(4:8), angle_props(4:7)
|
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8283
Location: Salford, UK
|
| Posted: Thu Jul 22, 2010 1:49 pm Post subject: |
|
|
John,
You need to change from assumed-size arrays (star sized) to assumed-shape arrays (using a colon). You also need to include the interface that I have posted. If you do this then you will get the correct results.
Even a vector has shape and this must be passed to get_angle_props. The interface makes this happen.
I have now added code to the compiler to trap the error when SIZE is called for an assumed-size array where the DIM is equal to the rank. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2625
Location: Sydney
|
| Posted: Fri Jul 23, 2010 1:36 am Post subject: |
|
|
Paul,
I disagree with the approach you are taking.
If I take you back to my original problem where ftn95 /check is not providing the correct argument sizes.
I have a subroutine defined as
| Code: |
subroutine get_angle_props ( dimen, props)
real*8 dimen(4), props(9)
... |
The info for dimen(4) is taken from part of a larger array.
If I use the old style ftn call I would have the call " get_angle_props (tprop(9), angle_props) " and all runs ok.
The problem came when I wanted to check the program and tried to use /check to see if there were any problems in other parts of the program. The error came back that the supplied array was too small.
To overcome this I had two easy options, I could define a temporary array "real*8 dimen(4)" to use in the call and define it by "dimen = tprop(9:12)"
Alternatively, I thought I could show /check that the array had 4 elements by using the array section in the call as " get_angle_props (tprop(9:12), angle_props) ", which minimises the changes to the original code. I am trying not to put lots of temporary array patches through my code.
I do not see why calling the routine " get_angle_props " needs an interface, as the dimensions expected are clearly defined and this extra info is only required by /check.
You appear to be saying I need an interface so that /check can work.
/check should be able to recognise that "tprop(9:12)" is an array of 4 elements.
In the example I posted last night, "IF" SIZE is working with the declaration " real*8 dimen(*), props(*) " then "ftn95 /check" is supplying incorrect information about the size of the arguments. (The use of SIZE is the only way I could see how to easily report the array sizes provided by /check. If I don't compile with /check the size is not available)
Indeed, in SUBROUTINE SECTION_PROP, any array section of the supplied (dummy argument?) array "tprop" appears to be given a length of 1, while any array section of the local array "angle_prop" appears to ignore the defined end, eg angle_prop(3:5) is compiled as angle_prop(3: ).
It is my impression that
1) /check should be able to provide the array size, being 4 for the array section "tprop(9:12)" .
2) We should not have to provide an INTERFACE just for /CHECK to work.
I have been assuming that when compiling with /CHECK, extra information is provided on the stack about the supplied subroutine arguments and in this case it is not being done correctly.
John |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2625
Location: Sydney
|
| Posted: Fri Jul 23, 2010 2:07 am Post subject: |
|
|
Further,
If I modify the routine so that an interface is required, all works using
| Code: |
INTERFACE
subroutine get_angle_props (dimen, props)
real*8 dimen(:), props(:)
end subroutine get_angle_props
END INTERFACE
|
But I can not get the INTERFACE or call to work with /check if the original subroutine is defined as
| Code: |
subroutine get_angle_props (dimen, props)
!
! calculate the properties of an (un)equal angle
!
real*8 dimen(4), props(9)
REAL*8 AX,AY,AZ, B,D,T,W, B1,D1
!
...
|
This simple definition should not be incompatible with /check and it should not be reported that tprop(9:12) is the wrong size, which is saying that /check does not support array sections.
John |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8283
Location: Salford, UK
|
| Posted: Fri Jul 23, 2010 8:44 am Post subject: |
|
|
Perhaps it would be simpler to wait till you see the next release.
As I have noted earlier in this thread, I agree that /check was not working for array sections (it was reporting the wrong size). For the next release I have fixed this problem by changing the compiler so that it does not provide data for the runtime check in this particular case. (i.e. this check is not carried out, allowing the executable to run naturally).
With the current release, if you use assumed-shape arrays and the interface then SDBG should show the correct sizes but the runtime checking will cause it to fail. i.e. the compiler sizes (via the shape that is passed) will be correct but the runtime checking values will be wrong.
As I say, lets leave this till you see the fix that I have provided for the next release. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2625
Location: Sydney
|
| Posted: Fri Jul 23, 2010 10:19 am Post subject: |
|
|
Paul,
Thanks for that. I'll look forward to the next update.
John |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
