Skip to content

tws netCDF format

Maren Kaluza requested to merge tws_netCDF_format into develop

In this feature branch the tws input was changed from ascii files to netCDF format. It is still averaged over the domain. This issue will be addressed in the next feature branch together with et.

Before, there had to be a subroutine where the tws data was appended with dummy data in case there were domains without tws. Essentially, the issue was there with the et data, as well, but didn't cause any problem if et data was read first, meaning, if the first domains to be read were all the et domains. The reason is the following:

  • only if a domain has et, the subroutine to read et is called. It appends the global variable L1_et
  • however later when accessing the data, s1 and e1 from level1 for the given domain is used. It is assumed that L1_et has the same shape as any other L1 data.

With this branch there is a new datatype used for tws, and if we can agree on that I will implement it for the other opti data, as well. It is called optidata and it stores

  • the observed L1 data
  • the mask for that L1 data
  • the directory where the observed data is stored
  • the timestep for which we want to create the simulated data
  • the writeout counter for the simulated data, meaning the current timestep with respect to the simulated data (before, there was a variable writeout_counter that was used for all simulated data and if there was more than one there was a collision)

L1_tws is then an array of this type with nDomain dimensions. It is domain specific and there is no append strategy anymore. Another advantage is, that there are no unnecessary fill values anymore, if the shape of the arrays time X s1:e1 do not fit together. As far as I looked through the code it was never accessed as one whole array anyway.

We could discuss if the letter two attributes (timestepInput, writeOutCounter) should be part of that datatype. This is a minor change that I could reverse if wanted.

The disadvantage: in mhm_eval the whole datatype L1_tws is loaded where also the observed data is stored, which is not used in mhm_eval. If Fortran compiles reasonable there should not be an issue with copied data, though.

The advantages: data, that belongs together is packed together. This could reduce errors in further implementations. Also with this type we could easily extend the code in a way that we have a different timeStepInput for each domain even if it is all tws data.

Another possibility would be to have an own datatype for meta data for the simulated data with these two variables. It could be easily changed and is not the main part of this merge request anyway.

Merge request reports