Minor correction request

Question

Minor correction request

Closed this issue 2 years ago · 4 comments

Superb job of conversion, and I look forward to using this package.

I noticed that when using Gfortran to build, we have to use -std=legacy. Is this for getting the compiler to accept instances of work arrays of mismatched types (integer array is expected, but double precision array is passed)? With the NAG compiler, if the -dusty compiler option is not used, such mismatched arguments cause the compilation to fail.

Another issue of a similar type is related to numerous instances in the various *.inc files and example driver source files, where the pattern is (this one is from lsoda.f90):

`real(kind=dp) , dimension(nrowpd,neq) :: pd

integer :: nrowpd`

When the NAG compiler processes this file, it emits the error message

Error: lsoda.f90, line 237: Implicit type for NROWPD
       detected at NROWPD@,
Error: lsoda.f90, line 238: Symbol NROWPD has already been implicitly typed
       detected at NROWPD@<end-of-statement>

According to Fortran 2018 section 10.1.11.6,

A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association.

This rule requires that the type declaration of nrowpd must occur before the use of nrowpd in a specification expression. NAG Fortran enforced this rule. Intel Fortran does not.

It took me a few minutes to correct all instances of incorrect ordering. Please consider making the same edits in this Github. Thanks.

Answer 1 · 2022-10-07T23:35:42.000Z

Had just noticed the order issue when using --std=f95 with gfortran to get a measure of how many newer features were present when I was considering your earlier comments about newer feature usage. We should be able to correct that shortly. The issues with type mismatch are what paused the changes, as it would be risky to make such a low-level change. It is not just a matter of creating a type with real and integer components or duplicating the work directories; because as you mentioned you have seen yourself, values are passed back, sometimes through multiple calls, etc. Was looking to put a unit test in before making such a change to help verify the changes and have not had time. That is why the --legacy switch is required; and why further steps like parallelizing some of the more heavily used procedures has not proceeded. Some of that is described or at least eluded to in the README.md file. Was also trying to gather up some of the original developer documentation. The other project handles the optimization problem by allowing for integrating other linear algebra libraries alreay optimized, and does some other things it would be nice to integrate. Wondering if the divergence is already too significant or if the projects could be easy merged, but have not actually looked yet.

…

On 10/07/2022 10:09 AM mecej4g ***@***.***> wrote: Superb job of conversion, and I look forward to using this package. I noticed that when using Gfortran to build, we have to use -std=legacy. Is this for getting the compiler to accept instances of work arrays of mismatched types (integer array is expected, but double precision array is passed)? With the NAG compiler, if the -dusty compiler option is not used, such mismatched arguments cause the compilation to fail. Another issue of a similar type is related to numerous instances in the various *.inc files and example driver source files, where the pattern is (this one is from lsoda.f90): real(kind=dp) , dimension(nrowpd,neq) :: pd integer :: nrowpd When the NAG compiler processes this file, it emits the error message Error: lsoda.f90, line 237: Implicit type for NROWPD detected at NROWPD@, Error: lsoda.f90, line 238: Symbol NROWPD has already been implicitly typed detected at NROWPD@<end-of-statement> According to Fortran 2018 section 10.1.11.6, A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. This rule requires that the type declaration of nrowpd must occur before the use of nrowpd in a specification expression. NAG fortran enforced this rule. Intel Fortran does not. It took me a few minutes to correct all instances of incorrect ordering. Please consider making the same edits in this Github. — Reply to this email directly, view it on GitHub #7 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AHDWN3IR7Q2X4NDO2IQJIOLWCAVLFANCNFSM6AAAAAAQ7UE45A . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 2 · 2022-10-08T01:13:23.000Z

Everything should now have the declaration order standard. Lines were just moved not changed, so a straight-forward change. Let us know if the NAG compiler agrees.

Answer 3 · 2022-10-08T10:36:28.000Z

The files with the declarations order fixed are accepted by the compiler.

The NAG compiler objects to another pattern, which I noticed earlier but did not report.

In a few of the *.inc files, you have

real(kind=dp) :: dp

The identifier dp stands for two different entities in a single declaration statement -- as a kind value for a real type, and as a local variable. The NAG compiler rejects that, saying (I give one example):

Error: M_da1/dsolbt.inc, line 51: Implicit type for DP
detected at DP@
Error: M_da1/dsolbt.inc, line 51: Symbol DP has already been implicitly typed
detected at DP@

A simple fix would be to change the name of the local variable to, say, dpd.

Answer 4 · 2022-10-08T11:45:16.000Z

Interesting I could not get ifort or gfortran to detect that, with many debug flags on. I changed dsolbt.inc.