[ghemical-devel] about symtrz.f

[Daniel Leidert]

Am Mittwoch, den 06.08.2008, 13:41 +0300 schrieb Tommi Hassinen:

> I haven't looked yet at the configure-scripts-related parts of the
> patchfile ; this might take a few days before I can arrange it.

No problem. Just ask, if you have a question.

> But about these fortran files. I'm not a great fortran expert myself,
> and in the past I have been very careful in changing anything there. I
> have also retained the old code (in comments) and tried to explain why
> the change is needed.
> 
> There is really something hazy in symtrz.f ; g77 and gfortran wont
> compile this line:
> 
>       DATA TOLER,IFRA /  0.1, '????'/
> 
> because it involves assignment of a string value '????' into an
> integer-type variable.

This assignment is not a problem. Only the assignment between NAMES and
IFRA (character) and JX/NAMO (integers) creates a problem.

>  Also f2c gives a warning about it but still accepts it. I don't have
> any idea what the subroutine is about and actually *what* it is doing.
> However, I don't think this is just a typo because NAMES exists three
> times there:
> 
>       NAMES=IFRA
>       IF(J1.EQ.1) NAMES=JX(1,1)
>       DO 2 I=1,NORBS
>       INDEX(I)=I
>  2    NAMO(I)=NAMES
> 
> also right after initializing NAMES=IFRA the next code line will
> modify the value: IF(J1.EQ.1) NAMES=JX(1,1)
> 
> Now if we change the code by assuming it's just a typo and change it
> NAME=IFRA the result is that the original value
> NAMES will be left without any proper initialization.

Forget my typo idea. It was silly.

> OK then, how to initialize NAMES if we can't put there the string
> value? I looked at C code produced by f2c and tried to get an answer
> there:
> 
>  static doublereal toler = .1;
>  static struct {
>    char e_1[4];
>    integer e_2;
>  } equiv_167 = { "????", 0 };
>  #define ifra (*(integer *)&equiv_167)
> 
> The f2c program just makes a structure { "????", 0 } that represents IFRA.
> Here is the definition of names-variable:
> 
>     static integer names, ifound;
> 
> This code makes the assignment:
> 
>     names = ifra;
> 
> I haven't tried to look what actually happens at runtime, but from the source it looks to me like names will get the value 0.
> 
> Therefore I decided to change
> 
>       NAMES=IFRA
> 
> to
> 
>       NAMES=0
> 
> This is accepted by both g77 and gfortran (at least this version:)

Hm. But instead to comment all the lines, simply do a:

INTEGER NAMES
DATA TOLER,IFRA / 0.1, 0 /

IFRA seems to be a local variable. This is the solution I attach as
symtrz_f_1.patch.

However, there could be a different solution. From reading the source I
get the impression, that just a few other variables need to be defined
as characters too, e.g. NAMO and JX. See the other subroutines in
symtrz.f. For this case, I attached symtrz_f_2.patch.

With both patches, gfortran is satisfied and compiles.

> $ gfortran --version
> GNU Fortran 95 (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

That's probably too old. I'm running Sid and my gfortran complains about
your code too.

> I also ran all test files under test/ directory with the old f2c code
> and the modified code compiled with the fortran compilers and found no
> relevant changes ; but I have no idea how many times (if any) the code
> in symtrz.f is actually executed...
> 
> Any ideas how to catch the initial value of NAMES at runtime? By
> modifying the C source code to print it out and exit()??? But is the
> value relevant at all? Perhaps it is (code generated by f2c will have
> the same values in variables etc but final access to arrays is shifted
> by -1).
> 
> What about those changes in esp.f file ; what is the reason for changes there?

Because gfortran complains with:

  Error: The STATUS specified in OPEN statement at (1) is 'NEW' and no 
  FILE specifier is present

The OPEN statement just specifies a unit, but no filename. STATUS
therefor is not correct here ("NEW" means: the file must not exist - so
this doesn't make sense when using just a logical unit, but not a file).
IMHO the proposed patch is safe.

Regards, Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: esp_f.patch
Type: text/x-patch
Size: 706 bytes
Desc: not available
Url : http://www.bioinformatics.org/pipermail/ghemical-devel/attachments/20080806/6b3ba2e7/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symtrz_f_1.patch
Type: text/x-patch
Size: 1456 bytes
Desc: not available
Url : http://www.bioinformatics.org/pipermail/ghemical-devel/attachments/20080806/6b3ba2e7/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symtrz_f_2.patch
Type: text/x-patch
Size: 1463 bytes
Desc: not available
Url : http://www.bioinformatics.org/pipermail/ghemical-devel/attachments/20080806/6b3ba2e7/attachment-0002.bin