From: Hifi-Comp on
My original question was not clear and get sidetracked. Hence I am
trying to clarify the question:

Currently I have the following:

INTEGER,PARAMETER:: n=3

TYPE,PUBLIC:: User_Data
REAL(DBL_AD)::scale
REAL(DBL_AD)::vector(n)
END TYPE User_Data

TYPE(User_Data):: x, y(30),z(100,10)

In the real situation, I want the user of compiled code to input n
(remain the same throughout the calculation) and with almost no
changes to the original code.

Richard suggested to change the type definition as follows
TYPE,PUBLIC:: User_Data
REAL(DBL_AD)::scale
REAL(DBL_AD),ALLOCATABLE::vector(:)
END TYPE User_Data

However, I don't want to insert allocate statement for each variables
of User_Data as there are many such types in the overall program. It
seems to me I should be able to do something like

ALLOCATE(USER_DATA%VECTOR(N))

to fix the dimension of vector, and all the variables of User_Data
will then know the dimension already. Is it posslbe to achieve this?
From: steve on
On May 18, 6:51 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
> My original question was not clear and get sidetracked. Hence I am
> trying to clarify the question:
>
> Currently I have the following:
>
> INTEGER,PARAMETER:: n=3
>
> TYPE,PUBLIC:: User_Data
>         REAL(DBL_AD)::scale
>         REAL(DBL_AD)::vector(n)
> END TYPE User_Data
>
> TYPE(User_Data):: x, y(30),z(100,10)
>
> In the real situation, I want the user of compiled code to input n
> (remain the same throughout the calculation) and with almost no
> changes to the original code.
>
> Richard suggested to change the type definition as follows
> TYPE,PUBLIC:: User_Data
>         REAL(DBL_AD)::scale
>         REAL(DBL_AD),ALLOCATABLE::vector(:)
> END TYPE User_Data
>
> However, I don't want to insert allocate statement for each variables
> of User_Data as there are many such types in the overall program. It
> seems to me I should be able to do something like
>
> ALLOCATE(USER_DATA%VECTOR(N))
>
> to fix the dimension of vector, and all the variables of User_Data
> will then know the dimension already. Is it posslbe to achieve this?

No.

See Richard's previous response.

PS: You can't ALLOCATE something that does not have the
ALLOCATABLE (or POINTER) attribute.

--
steve
From: Hifi-Comp on
So you are saying there is no way in Fortran to accomplish what I
intended to do: changing the original global constant n, which used to
define the dimension of the array, into a user input one, with
minimized change to the original code.


On May 18, 9:56 pm, steve <kar...(a)comcast.net> wrote:
> On May 18, 6:51 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
>
>
>
>
>
> > My original question was not clear and get sidetracked. Hence I am
> > trying to clarify the question:
>
> > Currently I have the following:
>
> > INTEGER,PARAMETER:: n=3
>
> > TYPE,PUBLIC:: User_Data
> >         REAL(DBL_AD)::scale
> >         REAL(DBL_AD)::vector(n)
> > END TYPE User_Data
>
> > TYPE(User_Data):: x, y(30),z(100,10)
>
> > In the real situation, I want the user of compiled code to input n
> > (remain the same throughout the calculation) and with almost no
> > changes to the original code.
>
> > Richard suggested to change the type definition as follows
> > TYPE,PUBLIC:: User_Data
> >         REAL(DBL_AD)::scale
> >         REAL(DBL_AD),ALLOCATABLE::vector(:)
> > END TYPE User_Data
>
> > However, I don't want to insert allocate statement for each variables
> > of User_Data as there are many such types in the overall program. It
> > seems to me I should be able to do something like
>
> > ALLOCATE(USER_DATA%VECTOR(N))
>
> > to fix the dimension of vector, and all the variables of User_Data
> > will then know the dimension already. Is it posslbe to achieve this?
>
> No.
>
> See Richard's previous response.
>
> PS: You can't ALLOCATE something that does not have the
> ALLOCATABLE (or POINTER) attribute.
>
> --
> steve- Hide quoted text -
>
> - Show quoted text -

From: steve on
On May 18, 7:10 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote:
> So you are saying there is no way in Fortran to accomplish what I
> intended to do: changing the original global constant n, which used to
> define the dimension of the array, into a user input one, with
> minimized change to the original code.
>

Well, your top posting has forced a loss of context, but
yes that's what I'm (and others are) saying.

Other than allowing free-form source code, dynamic memory
management is perhaps the most important change to Fortran
when Fortran 90 was ratified 2 decades ago.

The only way that comes close to what you want is to massively
over-commit static allocation, and then check that a user doesn't
enter a value that exceeds the upper limit.

INTEGER,PARAMETER:: upper_limit = 1024

TYPE,PUBLIC:: User_Data
REAL(DBL_AD)::scale
REAL(DBL_AD)::vector(upper_limit)
END TYPE User_Data

TYPE(User_Data):: x, y(30),z(100,10)

read(*,*) n

if (n > upper_limit) then
stop 'Upper limit of static array allocation exceeded'
end if

--
steve
From: robin on
"Hifi-Comp" <wenbinyu.heaven(a)gmail.com> wrote in message
news:ab15b088-db79-4d5a-b07d-106d3c7e8e61(a)y12g2000vbg.googlegroups.com...

>So you are saying there is no way in Fortran to accomplish what I
>intended to do: changing the original global constant n, which used to
>define the dimension of the array, into a user input one, with
>minimized change to the original code.

Have you investigated introducing a new main program in which
the bound(s) of the array are read in, and which then passes
that array to the original main program (suitably midified).

Any subsequent reference to that array would need to have a declaration of the
form real A(*) or real A(:).

That may be adequate for a few arrays, but in general
any change from static to dynamic in Fortran will involve
significant changes.