time series issue with ifort built MF6

[ougx]

Describe the bug
The ifort built MF6 does not correctly assign values in the time series data file. In the attached example, the SFR inflows for time 8 and 10 were incorrectly assigned when running a ifort built MF6. However, gfortran built MF6 does not have this problem.
step1.zip

[wpbonelli]

thanks for reporting @ougx just to confirm, you are seeing this with the latest release, develop branch, or both?

[ougx]

Both

[wpbonelli]

I also see EXT-INFLOW-IN, EXT-OUTFLOW-OUT, TOTAL_IN, and TOTAL_OUT of 7 and 9 at t=8 and 10 respectively on mac 13.6.2 ifort 2021.10, building from develop

[ougx]

It turned out to be the mixed new line characters used in the flow file. Strange that ifort could not handle this.

[wpbonelli]

We should probably document this as a limitation of the Intel-built distributions (I do not see it mentioned in mf6io) and test whether ifx has the same issue

[emorway-usgs]

If this is something that's likely to be an issue for others who don't pick up on the fact that their externally-prepared input has mixed new-line characters, it might be worth keeping this open so it can get worked on. If you have an example set of model input that recreates the issue (i.e., includes an input file with the mixed new-line characters), it might worth zipping that up and attaching here (for debugging purposes later).

[wpbonelli]

@emorway-usgs see the zipfile in the original post. the ts_timestep.sfr_flow file mixes CR+LF with just CR

[ougx]

FYI, the file can actually be read correctly by ifort using free format * below.

program readfile
double precision :: time, flow
integer          :: i, ifile


open(newunit=ifile, file='ts_timestep.sfr_flow')
do i=1, 7
  read(ifile, *)
end do
do i=0,14
  read(ifile, *) time, flow
  print*, time, flow
end do
end

[wpbonelli]

As @emorway-usgs suggests this could stay open until documented or fixed

[langevin-usgs]

We have a special line reader in mf6 that allows us to read lines with unlimited length. Apparently, it needs some additional work to handle mixed line returns. Very strange that the behavior is compiler dependent.

[vivekbedekar]

I have added code to trap this error in the get_line subroutine. Will run autotest and then check in the code.