 |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Fri Mar 20, 2009 1:46 am Post subject: /check and sub-arrays |
|
|
I occasionally have problems compiling with /check, when sub arrays are used.
In the following example, the 4th argument is declared as integer, dimension(2), but supplied as a part of an integer array iilist(6:7).
This all works well (with /debug) unless /check is used. When running the program, there is an error "Attempt to call a routine with argument number four containing too few argument elements".
I overcame the problem, by declaring the array as variable length then reporting the size of the array, which was always 2. As the dimension was declared "dimension(: )", I also used an interface declaration in all calling routines.
Is this a bug in /check, not being able to recognise "iilist(6:7)" is dimension 2 ?
( I'm also getting another "Error: ALLOCATE was unable to obtain sufficient storage" when trying to allocate an integer*4 array of dimension (5);( 20 bytes! ), after a combined ALLOCATE of 1.58 mb in 4 other arrays, but that is another puzzle )
John
Code: |
! typical call to routine
call fix_Beam_release_code (0, etype, jk, iilist(6:7))
subroutine fix_Beam_release_code (ftype, etype, jk, end_code)
!
! First declaration
integer*4 ftype, etype, jk(6,2), end_code(2)
!
! Revised declaration
integer*4, intent (in) :: ftype ! format type
integer*4, intent (in) :: etype ! element formulation type
integer*4, dimension(6,2), intent (in) :: jk ! end release code for ftype=5, etype=2
integer*4, dimension(:), intent (inout) :: end_code ! end release code
|
|
|
Back to top |
|
 |
IanLambley
Joined: 17 Dec 2006 Posts: 506 Location: Sunderland
|
Posted: Fri Mar 20, 2009 1:51 pm Post subject: |
|
|
John,
If the subroutine only uses two elements from the passed array, then it was probably alright to use a dimension of 2 within the subroutine. In the calling statement, you only need to refer to the first element position as it is simply the address of the start of the section of the array you wish to use.
For example,
Code: |
call fix_Beam_release_code (0, etype, jk, iilist(6))
subroutine fix_Beam_release_code (ftype, etype, jk, end_code)
integer*4 ftype, etype, jk(6,2), end_code(2)
|
should work, but whether /check fouls this up, I do not know.
Regards
Ian |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8211 Location: Salford, UK
|
Posted: Fri Mar 20, 2009 2:43 pm Post subject: |
|
|
Are you using an interface in the code that calls the subroutine? |
|
Back to top |
|
 |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2615 Location: Sydney
|
Posted: Mon Mar 23, 2009 4:54 am Post subject: |
|
|
Paul,
My first attempt, which failed, did not use an interface block.
In all cases, the calling list was the same:
" call fix_Beam_release_code (0, etype, jk, iilist(6:7)) "
The first attempt which failed had the subroutine defined as a F77 style:
" subroutine fix_Beam_release_code (ftype, etype, jk, end_code)
!
integer*4 ftype, etype, jk(6,2), end_code(2) "
It appears that the supplied argument "iilist(6:7)" did not work with the definition of "end_code(2)"
By going to the implied size and using an interface block, this solved the problem.
Perhaps I could have also solved the problem with F77 style by declaring
Integer ecode(2)
Equivalence (iilist(6), ecode(1))
Then using ecode as an argument.
FTN95 appears to object to the 4th argument as iilist(6:7); an array argument.
My question is, is this array argument inconsistent with the "integer end_code(2)" when /check is used ?
I was actually trying to use /check to verify other parts of the code, but /check caused problems with this approach to sending part of the array.
I thought that using iilist(6), as Ian has suggested, would also be wrong when /check is used. However, I tested this and it worked !
I am now getting the error "Error: ALLOCATE was unable to obtain sufficient storage" with very small arrays. I am using /3gb and ftn_95_new_memory=ON, with a total of 6 allocated arrays using 4k of memory. Could there be a problem with the new memory model and /check ?
There may be an error somewhere else in the program, but /check is not giving a clear indication where it is !
John
ps: Can my allocate problem be from using the new memory model and /check ? I thought I would still get 2gb with /check but somewhere I am running out of memory/storage. When using /check, does DEALLOCATE not release the memory? I don't think it is a stack size problem, as I think ALLOCATE does not use the stack memory area.
Any comment ? |
|
Back to top |
|
 |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8211 Location: Salford, UK
|
Posted: Fri Apr 03, 2009 12:05 pm Post subject: |
|
|
Hi John
I am sorry to say that your question is too long and complex for me to handle right now. Can you run a test with the latest download (5.30) and then, if the problem persists, let me have some sample code together with a short and simple query.
Regards
Paul |
|
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
|