Dear All,
I am trying to run a code written in fixed form. There are four main cases and one COMMON.H code for connecting all of them together. I am trying to run at least one of the codes. However, I have received many errors saying "The function result on the lhs of the assignment at (1) must have the pointer attribute". I tried to google it but there were not enough links. Can you give me some hints, please?
(I am new to Fortran)
Also, I like to rewrite the codes in free form Fortran by changing the structure of the codes. Do you have some suggestions?

Regards,

Farzad

On Monday, May 29, 2023 at 12:33:02 PM UTC+2, Farzad Tatar wrote:
> Dear All,
> I am trying to run a code written in fixed form. There are four main cases and one COMMON.H code for connecting all of them together. I am trying to run at least one of the codes. However, I have received many errors saying "The function result on the lhs of the assignment at (1) must have the pointer attribute". I tried to google it but there were not enough links. Can you give me some hints, please?
> (I am new to Fortran)
> Also, I like to rewrite the codes in free form Fortran by changing the structure of the codes. Do you have some suggestions?
>
> Regards,
>
> Farzad

You should show code that exhibits the problem you encountered. The description leaves too much to be guessed.

As for fixed form versus free form, there are many online resources that can help you with that. Here is a page that might be useful: https://fortranwiki.org/fortran/show/Tools. This is one result of a Google search "fortran convert fixed format to free format".

Regards,

Arjen

On Monday, May 29, 2023 at 3:33:02 AM UTC-7, Farzad Tatar wrote:
> Dear All,
> I am trying to run a code written in fixed form. There are four main cases and one COMMON.H code for connecting all of them together. I am trying to run at least one of the codes. However, I have received many errors saying "The function result on the lhs of the assignment at (1) must have the pointer attribute". I tried to google it but there were not enough links. Can you give me some hints, please?
> (I am new to Fortran)

The biggest mistake that causes this problem is forgetting to dimension arrays.

A function reference looks much like an array reference, except not being declared an array.

> Also, I like to rewrite the codes in free form Fortran by changing the structure of the codes. Do you have some suggestions?

On Tuesday, May 30, 2023 at 11:32:09 AM UTC+2, gah4 wrote:
> On Monday, May 29, 2023 at 3:33:02 AM UTC-7, Farzad Tatar wrote:
Thank you for the information. Regarding the code converters, they all have issues with conversions. They delete many parts of the fixed form code (maybe ignore some lines).

Thank you for the other explanations anyway.

Best regards,

Farzad

Hi All,
Just to make it useful for future users- if there would be anyone who still uses this version- regarding the error, I compiled it with Fortran Powerstation4 and it worked. I think that gfortran requires a new format or more information when defining arrays. Since I am temporarily using and modifying the already written code, I decided to postpone updating the code to a later time. Anyways, thank you all again for your helpful information.

Regards,

Farzad

On Monday, May 29, 2023 at 3:33:02 AM UTC-7, Farzad Tatar wrote:

(snip)

> Also, I like to rewrite the codes in free form Fortran by changing
> the structure of the codes. Do you have some suggestions?
Fixed form is still legal in the most recent standard that I know about.

Also, everything should work exactly the same way.

The main complication with fixed to free form conversion, is that
blanks are not significant in fixed form. You can smash things
together, or space them out with extra space.

But since almost no-one does that, it should be possible to
convert mostly ignoring that.

There are some programs written by other programs that are
generated without any blanks, though.

> Fixed form is still legal in the most recent standard that I know about.
>
> Also, everything should work exactly the same way.
>
> The main complication with fixed to free form conversion, is that
> blanks are not significant in fixed form. You can smash things
> together, or space them out with extra space.
>
> But since almost no-one does that, it should be possible to
> convert mostly ignoring that.
>
> There are some programs written by other programs that are
> generated without any blanks, though.

Thank you for the explanation. I am dealing with fixed form because the finite element code for the problems is written in this way--and I want to add something to it. Therefore, seeking to accelerate the process and skipping writing a generic FE code, I asked this question. Anyway, I am dealing with the algorithm behind the code, which is more important than coding itself --as an engineer.

Cheers,

Farzad Tatar

Il giorno giovedì 6 luglio 2023 alle 16:13:16 UTC+2 Farzad Tatar ha scritto:
> > Fixed form is still legal in the most recent standard that I know about..
> >
> > Also, everything should work exactly the same way.
> >
> > The main complication with fixed to free form conversion, is that
> > blanks are not significant in fixed form. You can smash things
> > together, or space them out with extra space.
> >
> > But since almost no-one does that, it should be possible to
> > convert mostly ignoring that.
> >
> > There are some programs written by other programs that are
> > generated without any blanks, though.
> Thank you for the explanation. I am dealing with fixed form because the finite element code for the problems is written in this way--and I want to add something to it. Therefore, seeking to accelerate the process and skipping writing a generic FE code, I asked this question. Anyway, I am dealing with the algorithm behind the code, which is more important than coding itself --as an engineer.
>
> Cheers,
>
> Farzad Tatar
And you can write in a way that your source is compatible with fixed and free form.

Comment a line with a "!" on the first column.
As a continuation character use an "&" on the sixth column (on the continued line as in fixed form) and put a "&" after the 73th column in the first part of the continued line (like in the free form), it will be taken as a comment in fixed form unless you are using a compiler option that increase the length of a line beyond the 73th column (or it was the 72th column, I cannot remember).

> And you can write in a way that your source is compatible with fixed and free form.
>
> Comment a line with a "!" on the first column.
> As a continuation character use an "&" on the sixth column (on the continued line as in fixed form) and put a "&" after the 73th column in the first part of the continued line (like in the free form), it will be taken as a comment in fixed form unless you are using a compiler option that increase the length of a line beyond the 73th column (or it was the 72th column, I cannot remember).

Thank you for the hints. However, the code was 6500, and doing all of these will take time. Also, the code is written in an Implicit way. I am using the code without new problems. However, it took some weeks for me to capture the intrinsic function and the whole structure of the program. I will rewrite it in a more updated version, but I need to do it by hand because the converter scripts clear parts of the code that should be cleared. I will appreciate it if you had a better solution. 

On Thursday, July 6, 2023 at 8:18:51 AM UTC-7, Farzad Tatar wrote:
> > And you can write in a way that your source is compatible with fixed and free form.
> > Comment a line with a "!" on the first column.
> > As a continuation character use an "&" on the sixth column (on the continued line as in fixed form)
> > and put a "&" after the 73th column in the first part of the continued line (like in the free form),
> > it will be taken as a comment in fixed form unless you are using a compiler option that increase
> > the length of a line beyond the 73th column (or it was the 72th column, I cannot remember).

> Thank you for the hints. However, the code was 6500, and doing all of these will take time.

It should be very easy to write a program to do the above.

As I noted, though, that only works if the program uses blanks in a way that satisfies free form.

Youcan'twriteeverythingtogetherwithoutblanks!

An dyo uca n'tad dthe minot therpla ces.

There are conversion programs designed to work with such code, but they are always
behind in the version of the standard that they support.

But pretty much no-one writes programs that way!

Well.

Some years ago, I was working with the MORTRAN 2 processor. It is written in standard
Fortran 66, with minimal extensions. That is, that you can assign and compare data read
in A format. (Yes, the standard doesn't allow for that.)

As well as I remember it, the program itself, and its output, has no extra blanks.
And even a comment something like:

"This program was written by another program. It is not meant to be understood by humans."

(Probably all upper case, though.)

On 7/6/2023 9:40 AM, Edmondo Giovannozzi wrote:
> Il giorno giovedì 6 luglio 2023 alle 16:13:16 UTC+2 Farzad Tatar ha scritto:
>>> Fixed form is still legal in the most recent standard that I know about.
>>>
>>> Also, everything should work exactly the same way.
>>>
>>> The main complication with fixed to free form conversion, is that
>>> blanks are not significant in fixed form. You can smash things
>>> together, or space them out with extra space.
>>>
>>> But since almost no-one does that, it should be possible to
>>> convert mostly ignoring that.
>>>
>>> There are some programs written by other programs that are
>>> generated without any blanks, though.
>> Thank you for the explanation. I am dealing with fixed form because the finite element code for the problems is written in this way--and I want to add something to it. Therefore, seeking to accelerate the process and skipping writing a generic FE code, I asked this question. Anyway, I am dealing with the algorithm behind the code, which is more important than coding itself --as an engineer.
>>
>> Cheers,
>>
>> Farzad Tatar
> And you can write in a way that your source is compatible with fixed and free form.
>
> Comment a line with a "!" on the first column.
> As a continuation character use an "&" on the sixth column (on the continued line as in fixed form) and put a "&" after the 73th column in the first part of the continued line (like in the free form), it will be taken as a comment in fixed form unless you are using a compiler option that increase the length of a line beyond the 73th column (or it was the 72th column, I cannot remember).
>
Some systems use position 73-80 for line numbers so any content would be
wiped out.

On Monday, June 26, 2023 at 4:08:16 AM UTC-7, Farzad Tatar wrote:

(snip)

> Thank you for the information. Regarding the code converters, they all have
> issues with conversions. They delete many parts of the fixed form code
> (maybe ignore some lines).
Can you say which ones those are?

There is an early one designed, I believe, for Fortran 77.
It doesn't know about any statements added later.

Because of the possibility of blanks added or subtracted, it tries to
match up to actual statements. I am not sure what it does with
others, but it might delete them.

As well as I know, at least through Fortran 2018, all statements
are allowed in fixed form. There are some suggesting removing
this ability in later versions.