Megan v3.2 TXT2IOAPI time step error

Hi, all, I met a time error as the figure shows when I convert csv to nc, it’s ok for LAI, EF (figure #1) etc. but not for cantype (figure #2), the TFLAG in nc is not right (figure #3)



I used IOAP3.1, before run TXT2IOAPI, I edited Line160 in cnvt_cantyp.F from CALL NEXTIME(0 , ITIME, TSTEP3D ) to CALL NEXTIME( IDATE , ITIME, TSTEP3D ) because it has ‘Segmentation fault’, suggested from here Issue with Megan-v2.0 - #3 by jiang_j1

any suggestion for the probelm? thank you in advance

Can you share your cantype csv and GRIDDESC?

sure, here it is
CT3.EUP.csv (820.4 KB)
GRIDDESC (2).txt (176 Bytes)

I’m sorry to say I cannot find anything wrong with those files when I run MEGAN3.2’s TXT2IOAPI code. Here is my resulting CT3 file. Maybe there is something wrong with your NEXTIME call?

Here is my cnvt_cantype.F code.
cnvt_cantype.txt (6.1 KB)

1 Like

See https://cjcoats.github.io/ioapi/NEXTIME.html
Here’s some of the code from nextime.F:

      SUBROUTINE NEXTIME  ( JDATE , JTIME, DTIME )
        IMPLICIT  NONE

C.......   ARGUMENTS:

        INTEGER, INTENT(INOUT) :: JDATE           !  date (encoded YYYYDDD)
        INTEGER, INTENT(INOUT) :: JTIME           !  time (encoded  HHMMSS)
        INTEGER, INTENT(IN   ) :: DTIME           !  time increment (encoded HHMMSS)

The first two arguments of NEXTIME() are declared INTENT(INOUT): they will be changed by the subroutine call.

This call NEXTIME(0,ITIME,TSTEP3D)is illegal: it is attempting to change the value of the constant zero.

I do wish the MEGAN authors would read the documentation. And that they would follow the recommended-since-2003

    USE M3UTILIO

which would have caught this error at compile-time.

2 Likes

These aren’t meant to be times anyway so I’m not sure why they’re using that instead of another dimension name. Just one of the kludges that pops up when people try fitting a square peg into an ioapi shaped hole.