error code 7828

[kolber__Michael]

The web page for this code has been removed.  I am wondering if their is a work around for this error?

Thanks.

Michael

[Lorri_M_Intel]

Is this the error you received?

7828: The part-name to the right of a part-ref with nonzero rank has the ALLOCATABLE attribute (6.1.2).

What does your code look like; without that, it's all just wild guesses.

                   --Lorri

[kolber__Michael]

That is the error that I am getting.  The actual application is proprietary. Have created code that does the same thing using different variable names and data, so that you can understand the problem.

      Type XYZ_TYPE
          Character(len=:), allocatable ::  Name
          Integer*4 Number
      End Type
      Type (XYZ_TYPE), allocatable, dimension(:) :: XYZ
  
  
XYZ = (/XYZ_TYPE("Coupon",1), &
          XYZ_TYPE("Robert",32), &
          XYZ_TYPE("Roberta",5), &
          XYZ_TYPE("Zachery",2), &
          XYZ_TYPE("Mark Phillips",4), &
          XYZ_TYPE("John Smith",6)/)

     
index = Find_string(isize,sName,xyz%Name)

The error is on the %Name in the call to find_string.

[andrew_4619]

you pass xyz%name but xyz is an array so xyz%name is an array of allocatable strings which may or may not be allocated and in general will have variable lengths. I think it is saying you cannot pass that as an arg due to fortran language constraints

[Le_Callet__Morgan_M]

Dear all, we are finallyupgrding our compiler and i am trying to understend why the following code does not complie anymore as it used to compile and work using Visual Fortran Compiler 18.0.5.274 [Intel(R) 64]. 

Did it work by luck ?

Thanks and best regards

program Console2

    implicit none

    ! Variables
        TYPE FORTRAN_DYNAMIC_structure
            REAL(8),  ALLOCATABLE:: somedata(:)
        END TYPE FORTRAN_DYNAMIC_structure    
        TYPE FORTRAN_DYNAMIC_DATA
            TYPE(FORTRAN_DYNAMIC_structure):: m_dgeneric(5)
        END TYPE FORTRAN_DYNAMIC_DATA
        TYPE(FORTRAN_DYNAMIC_DATA):: mydata
        real(8) :: gen(5)
        integer :: i,j,ne
    ! Body of Console2
    ne = 4
 
        DO J=1,5
            IF(ALLOCATED(mydata%m_dgeneric(J)%somedata)) THEN
                DEALLOCATE(mydata%m_dgeneric(J)%somedata)
            END IF
            ALLOCATE(mydata%m_dgeneric(J)%somedata(NE))
            gen(j)= 1.0*j
        END DO 
        do i  = 1 , ne
        mydata%m_dgeneric%somedata(I)=gen
        enddo
    end program Console2

[FortranFan]

---

@Le_Callet__Morgan_M wrote:

Dear all, we are finallyupgrding our compiler and i am trying to understend why the following code does not complie anymore as it used to compile and work using Visual Fortran Compiler 18.0.5.274 [Intel(R) 64]. 

Did it work by luck ?

Thanks and best regards

program Console2

    implicit none

    ! Variables
        TYPE FORTRAN_DYNAMIC_structure
            REAL(8),  ALLOCATABLE:: somedata(:)
        END TYPE FORTRAN_DYNAMIC_structure    
        TYPE FORTRAN_DYNAMIC_DATA
            TYPE(FORTRAN_DYNAMIC_structure):: m_dgeneric(5)
        END TYPE FORTRAN_DYNAMIC_DATA
        TYPE(FORTRAN_DYNAMIC_DATA):: mydata
        real(8) :: gen(5)
        integer :: i,j,ne
    ! Body of Console2
    ne = 4
 
        DO J=1,5
            IF(ALLOCATED(mydata%m_dgeneric(J)%somedata)) THEN
                DEALLOCATE(mydata%m_dgeneric(J)%somedata)
            END IF
            ALLOCATE(mydata%m_dgeneric(J)%somedata(NE))
            gen(j)= 1.0*j
        END DO 
        do i  = 1 , ne
        mydata%m_dgeneric%somedata(I)=gen
        enddo
    end program Console2

---

@Le_Callet__Morgan_M ,

Re: "Did it work by luck ?" the answer will be yes, very much so based on the evidence you have presented.

It appears your code in the offending section was intended to be so - please confirm:

        do i  = 1 , ne
           do J = 1, 5
              mydata%m_dgeneric(J)%somedata(I)=gen(J)
           end do
        end do

but for which you appeared to have considered a compact instruction per Fortran's array-oriented semantics and syntax for the inner loop:

mydata%m_dgeneric%somedata(I)=gen

 Well, that is not supported by the language standard with components of ALLOCATABLE attribute that follow a part-ref with a rank greater than zero in an object reference to a derived type.  You will find it makes sense per the various facilities offered by the standard including allocation upon assignment.

It's unfortunate if you found an older version of the compiler to support your nonconforming code.  This might perhaps point you toward testing your code with two or more compilers,.  Thankfully gfortran does not require a paid license and you may have soon be able to try LFortran also.  Note for Fortran language-specific matters, you may want to follow Fortran Discourse also at https://fortran-lang.discourse.group/ which might help prevent similar situations in the future.

In the meantime, refactoring your code to conform might be a safer path forward.

[Le_Callet__Morgan_M]

@FortranFan thanks that was the intention.  I will look out the options. And yes we are refactoring the code but it is proven interesting as the previois compiler has issues debuging and what we think it was doing does not always match what we refactor. Thanks all.

[mecej4 · Accepted solution]

Line 26 appears to be in violation of Constraint C919 (Fortran 2018 standard):

C919 (R911) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a
part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute.

[Le_Callet__Morgan_M]

@mecej4  many thanks. Is this  a "new" requirements and pre 2018 was the results of this code compiler specific ?

[mecej4]

One would have to read through the relevant sections of earlier Fortran standards to answer your question, but note that compilers often do better at catching errors as newer compiler versions come out. The Lahey Fortran 95 compiler (2004) issues a similar warning with your code:

" jwd2141i-s "mlecallet.f90", line 26, column 9: Component 'mydata' to right of part references with nonzero rank must not have allocatable attribute."

[Le_Callet__Morgan_M]

Many thanks.