Investigate bilinear interpolation using s1 at velocity points

[arjanverkerk]

The previous investigation used bilinear on the whole cell, where corners where calculated from contributing neighbouring calculation cells. Big drawback was that the face value of the calculation cell was never arrived at, not even in the middle of the face (as is the case with constant and delaunay methods).

The next idea is therefore to divide a mesh face into four quadrants and use the (upwind) s1 values on velocity points (on the edges), the face value and a computed corner value as the inputs for bilinear interpolation.

      V         V  
      │         │  
      │         │  
─V────C────V────C────V─
      │    ·    │  
      │    ·    │  
      V····M····V  
      │    ·    │  
      │    ·    │  
─V────C────V────C────V─
      │         │  
      │         │  
      V         V  

The corners for the bilinear interpolation are C, V, V and M:

C is a computed value (we can start with the average of the velocity point values) V are the (upwind) velocity point values M is the face value

This is done on each quadrant of a calculation cell. Some additional choices have to be made near refinements, of course.

Edit: 2022-03-02 Added "(upwind)" in two places.

[RemieJanssen]

I am making several adjusted versions of Arjan's bilinear interpolation. They all use bilinear interpolation on the four corner squares of each calculation cell. This requires calculating the values for the V and C parts of Arjan's diagram above. Which can be done in several ways:

• remie-bilinear_with_corners Calculates C values as in Arjan's version, and V values as the average of the adjacent C values.
• remie-bilin_corners_T_as_mean Calculates C values as a mean of the adjacent faces (without the exception for T-intersections as in Arjan's code), and V values as the average of adjacent C nodes.
• remie-interpolate_middles_between_faces Calculates V values as average of the two adjacent faces (calculation cells). At T-intersections and for the V-values for small faces on the 'long side' of T-intersections, these values must be overwritten with averages of adjacent nodes in the end to achieve continuous interpolation. The C-values are simply averages of the adjacent faces.

In all cases, the interpolated value in the middle of the cell is equal to the original cell value. The first version is alright, but is skewed towards the value of the large cell at T-intersections with one impermeable boundary. In the second version, this is alleviated slightly by taking the average of all adjacent faces.

In that version, however, values of cells 'bleed' between adjacent cells:

      V    1    V    2    V
      │         │         │
      │         │         │
─V────C────V────C────V────C────V─
      │         │         │    
      │         │         │    
      V    3    V    4    V
      │         │         │
      │         │         │
─V────C────V────C────V────C────V─
      │         │         │  
      │         │         │
      V    5    V    6    V

The value of V in the middle is the average of the two C's in the middle. These C-values are the averages of cells 1,2,3,4 and of 3,4,5,6. This means that, indirectly, the middle V value depends on the values of the cells 1,2,5, and 6. In the third version (remie-interpolate_middles_between_faces), the V value in the middle is the average of the cell values of cells 3 and 4. (Unless there are impermeable boundaries.)

[RemieJanssen]

~Still to do:~ A version that uses the sau values of the result file as the V-values wherever possible.

The sau values represent water levels at velocity points. According to Martijn, they are only available when the velocity point is not blocked (I forgot whether that is only due to schematization, or also when the au value is zero?). Martijn seemed to remember Arjan saying that we need them because calculating the water levels at these points (like for the corners) is slow. This may be true, but the implementation in remie-interpolate_middles_between_faces seems to run in reasonable time.

A better reason for using sau values could be interpolation in sloping areas. Using the sau values from the results files, we can take slopes into account during interpolation, which isn't (easily) possible otherwise using only the data from the results files.

Implementation

First set all middle values of all cells using the sau values: simply set middle values of adjacent faces at their intersection to the sau value (if linked and if sau available, otherwise set to face value). Note that this fails for the larger cells at T-intersections, so middle values at T-intersections must be set afterwards. Corner values may then be calculated as the mean of the two adjacent middle values. Except, again, at the large cells of T-intersections, where we would like to take the sau values of the adjacent small cells into account. Hence, for these corners we again set the values separately. Afterwards, we take the same approach as before: label the corners of each intersection, and then set the values at the intersections to the mean of the corners with the same label.

Notes

This implementation overestimates the amount of water. This is due to the sau values being equal to the higher water level at each interface. Perhaps, changing the sau values output by 3Di would be useful, especially in sloping areas.

The implementation currently always uses the sau values of the last timestep. If you want to use a different timestep, also change the -1 index in calculate.py for the sau array.

Perhaps the interface values can be set depending on the au values: average of face/sau values weighted by the au values. If fully connected (au>?), then set the average weighted 50:50, if not connected at all (au<?) set to average weighted 100:0 on both sides.

[RemieJanssen]

For a small report about the properties of these interpolation methods, see https://nelenschuurmans-my.sharepoint.com/:w:/r/personal/remie_janssen_nelen-schuurmans_nl/Documents/Bilinear_after_subdivision.docx?d=w63360be0e7a74c9ea458bea5d2be422e&csf=1&web=1&e=iHytj8

[Patrick-Nijman]

@lexvand Waarom is dit weer naar New Issues gegaan? Ik had eigenlijk gehoopt dat Arjan dit af kon maken. Is het enige open issue in de Epic. Kan dit eventueel gesloten worden of als losse issue verder opgepakt worden?

[lexvand]

Not sure what the status of this project is. Closing this issue as it seems like it has been investigated. Any leftover work should be put in a new issue.