Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Problem to pass complex array between subroutine and main program


Hi everybody,
I'm using Compaq Fortran 6.1 and I am experiencing a big (for me)
problem.
I've got a subroutine which correctly compute a complex array but,
when the control returns to the main program, the subroutine doesn't
return the right value. In other words the array returned isn't filled
by the calculated values.

Does anyone experinced a problem like this and how to correct it?

Thanks a lot,
Decsar

On 3 mei, 11:46, marcomarc@gmail.com wrote:

> Hi everybody,
> I'm using Compaq Fortran 6.1 and I am experiencing a big (for me)
> problem.
> I've got a subroutine which correctly compute a complex array but,
> when the control returns to the main program, the subroutine doesn't
> return the right value. In other words the array returned isn't filled
> by the calculated values.

> Does anyone experinced a problem like this and how to correct it?

> Thanks a lot,
> Decsar

Can you show us some source code:
- Declaration of the array in the calling program
- The way you define the interface to that subroutine
- The call to the subroutine
- The declarations in the subroutine

Most likely, the interface to the subroutine is not or incompletely
known at compile time. That may cause a host of problems.

Is your subroutine in a module? Most likely putting it in a module
and then using that module will solve the problem.

Regards,

Arjen

On 3 Mag, 11:49, Arjen Markus <arjen.mar@wldelft.nl> wrote:

I can't post the original program because it's very complicated. I've
write a similar code which produce the same problem (which I've used
to find the solution).
I'm almost a newbie and probably the solution is very simple.

Decsar

        program prova
        implicit none

        integer :: cc
        double complex :: a(2,2)

        cc=2

        call pro(a,cc)

        end program prova

        subroutine pro(aa,ccc)
        implicit none

         integer ::ccc
         double complex, allocatable :: aa(:,:)

                allocate(aa(ccc,ccc))

                         aa(1,1)=11
                         aa(2,1)=21
                         aa(1,2)=12
                         aa(2,2)=22

        end subroutine pro

On 3 mei, 13:41, marcomarc@gmail.com wrote:

Well, this is sufficient :)

1. In the main program the argument you pass as "aa" is not
allocatable,
   whereas in the subroutine it is.
2. Allocatable arguments are not allowed by the standard, they are by
   some compilers and there is a "technical report" about the
restrictions on
   allocatable arrays (that is: official enhancements are possible).

If you want to comply to the standard, try:

module mymod
         implicit none
contains
         subroutine pro(aa,ccc)

         integer ::ccc
         double complex, pointer :: aa(:,:)

         allocate(aa(ccc,ccc))

         aa(1,1)=11
         aa(2,1)=21
         aa(1,2)=12
         aa(2,2)=22

         end subroutine pro
end module
program prova
         use mymod
         implicit none

         integer :: cc
         double complex, pointer :: a(:,:)

         cc=2

         call pro(a,cc)

end program prova

Note: double complex is not standard either, you might need to
use plain complex variables or use complex(kind=...) to be really
compliant.

The idea behind using a module is that the compiler then knows
exactly how to call your routine "pro". There are many situations
where this is required, and using modules takes care of them
without you having to know these situations.

Regards,

Arjen

<marcomarc@gmail.com> wrote in message

news:1178192516.431311.130950@u30g2000hsc.googlegroups.com...

Your program requires an explicit interface between pro and its caller. The
usual ways to do this are either to put pro into a USEd module or to make
pro an internal procedure. As a module procedure it would be as in the
example below.

HTH

Mike Metcalf

module example
contains
subroutine pro(aa,ccc)
implicit none

integer ::ccc
double complex, allocatable :: aa(:,:)

allocate(aa(ccc,ccc))

aa(1,1)=11
aa(2,1)=21
aa(1,2)=12
aa(2,2)=22

end subroutine pro
end module example

program prova
implicit none

integer :: cc
double complex :: a(2,2)

cc=2

call pro(a,cc)
end program prova

On 3 Mag, 13:50, Arjen Markus <arjen.mar@wldelft.nl> wrote:

Thanks a lot. I'll follow your advices and I'll change my code
according them.
Decsar

"Michael Metcalf" <michaelmetc@compuserve.com> wrote in message

news:l9k_h.10452$f17.6115@trndny05...

Whoops, missed the use statement!
Regards,

Mike Metcalf

On May 3, 7:50 am, Arjen Markus <arjen.mar@wldelft.nl> wrote:

<snip>

> 2. Allocatable arguments are not allowed by the standard, they are by
>    some compilers and there is a "technical report" about the
> restrictions on
>    allocatable arrays (that is: official enhancements are possible).

> If you want to comply to the standard, try:

<example using pointer elided>

Allocatable procedure arguments are part of Fortran 2003 and are
supported by most Fortran 95 compilers, and I suggest using one of
them, such as Intel Visual Fortran, g95, or gfortran.

Arjen Markus <arjen.mar@wldelft.nl> wrote:
> On 3 mei, 13:41, marcomarc@gmail.com wrote:
> > I can't post the original program because it's very complicated. I've
> > write a similar code which produce the same problem (which I've used
> > to find the solution).

As Arjen says, what you posted (the second time) is sufficient. For
future reference, you almost never can get useful answers to questions
like that without posting code which illustrates it. Descriptions of the
code are not good enough; it takes actual code.

> 1. In the main program the argument you pass as "aa" is not
> allocatable,
>    whereas in the subroutine it is.
> 2. Allocatable arguments are not allowed by the standard, they are by
>    some compilers and there is a "technical report" about the
> restrictions on
>    allocatable arrays (that is: official enhancements are possible).

Most compilers implement the TR by now, though I think there are one or
two exceptions. What might not be clear in the above comments though is
that even if you have a compiler that implements the TR, the comment
numbered 1 still applies. You can't do that; it doesn't even make sense.
If the array is of fixed size in the main program then it is already
"allocated" (though since it isn't allocatable, the standard doesn't use
that terminology). It makes no sense to also allocate it in the
subroutine.

I agree with Arjen's comments quoted above (and his other comments,
which I did not quote). I just thought that aspect needed clarification.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc