[pp_ser] Addition of used statement to IMPLICIT NONE is not sufficient

[clementval]

If the program has no IMPLICIT NONEstatement, pp_ser abort and does not process the file

[andyspiros]

pp_ser needs to import some modules, besides adding some code to your fortran subprogram. When parsing your function/subroutine, when it finds a directive, it will mark the point where it can import the modules, and this point is the IMPLICIT NONE. If this line is not found, it cannot know where to put the use statement. This is why it is mandatory.

I think in COSMO code the IMPLICIT NONE is mandatory anyway, so there should be no problem.

I would not say it is a bug. It can be an enhancement, maybe, because currently it is explicitly mandatory to put it and if you do in theory it works (unless you can prove it wrong...).

[clementval]

Sure but there is some cases where this is not present and the "point" should be different ... for exemple after PROGRAM or something like that

[andyspiros]

I don't know fortran very well. Shouldn't the IMPLICIT NONE be present in programs too? Can you make a concrete example?

[clementval]

So for example, this short program is totally valid in Fortran but pp_ser.pyis unable to handle it.

PROGRAM dummy
  INTEGER :: i = 10

  !$ser init directory='.' prefix='Dummy'
  !$ser mode write
  !$ser data myi=i

END PROGRAM dummy

[andyspiros]

Agreed, but that breaks the rules of COSMO. If you put an IMPLICIT NONE before the definition of the integer it should work correctly, right?

[clementval]

Yeah but shouldn't serialbox be more than just a tool for COSMO ?

[andyspiros]

The point obviously is that we don't have a fortran parser in pp_ser and we do something which requires a lot of assumptions. These assumptions are ok in COSMO code because of the stricter rules followed there, but we don't have anything as generic as the full fortran, which is an ugly and bad monster.

Yes, serialbox should be more than COSMO-specific. But this means facing a huge problem and put a lot of investment there. The current status is, it works provided you follow some rules. This is why I would not classify the above example as a bug, because it breaks these rules.

And yes, these rules should at least be very explicit and documented, which is a bug for sure...

[clementval]

Ok sure ... so let's keep this point as an enhancement

[andyspiros]

My personally important remark is that I totally agree with you. The fact that you cannot write standard compliant fortran and expect ppser to work is horrible. But you are doing some work in parsing fortran, aren't you? Maybe you will come out with a good solution which involves a true fortran parser or something :-)

[clementval]

Exactly, that's why I suggest to keep this issue for later ... but at least we have it somewhere

[clementval]

I'll solve this issue because it cause me some trouble right now.

Simple example that shows the problem

MODULE m_ser

  CONTAINS

  SUBROUTINE serialize(a)
    REAL(KIND=8), DIMENSION(:,:,:) :: a

    !$ser init directory='.' prefix='SerialboxTest'
    !$ser savepoint sp1
    !$ser mode write
    !$ser data ser_a=a

  END SUBROUTINE serialize

  SUBROUTINE dummy(a)

    IMPLICIT NONE

    REAL(KIND=8), DIMENSION(:,:,:) :: a

    !$ser init directory='.' prefix='SerialboxTest'
    !$ser savepoint sp2
    !$ser mode write
    !$ser data ser_a=a

  END SUBROUTINE dummy

END MODULE m_ser

In this case, the use statement is added only in the dummy subroutine. The resulting code is not compilable.

[andyspiros]

Now this will show my total ignorance of fortran, but couldn't you put a IMPLICIT NONE in the serialize subroutine?

[clementval]

@andyspiros Yes you could. But in some cases you don't want it ... especially if you wanna have implicitly typed variable and in my case, the IMPLICIT NONE is removed by the source-to-source compiler that I use. So when I have a workflow like this:

fortran file --> source-to-source --> fortran --> pp_ser --> fortran

I can be screwed. So I'm implementing better way to insert the USE statements.

[havogt]

@clementval This should be closed?