Reading spectra from Dfs2s: x0 and y0 defaults to zero
stkistner opened this issue · 6 comments
Description
x0 and y0 defaults to zero when reading Dfs2 files.
To Reproduce
Steps to reproduce the behavior:
filein = r'mikeio\tests\testdata\single_row.dfs2'
x0_current = mikeio.Dfs2(filein).read().geometry._x0
x0_actual = mikeio.Dfs2(filein,type='spectral').read().geometry._x0
print(x0_current)
print(x0_actual)
>>> 0.0
>>> -139.0500030517578
Expected behavior
In 9 out of 10 cases the x0 and y0 origins aren't necessary in Dfs2 files, but it is used in some cases e.g. vertical boundaries:
https://faq.dhigroup.com/default.asp?module=MIKE+3&ID=532
I see this traces back to the read_x0y0=False
parameter in mikeio.dfs._dfs2._read_dfs2_header
, which is only set to True when reading spectral datasets. Is there any logical way around this?
System information
- MIKE IO version: 1.5.1
AFAIK a Dfs2 file has no metadata which tells you that this file should be interpreted as a vertical slice. So I guess the pragmatic solution is to use the same approach as the spectral data, and supply that information when you open the file, e.g. Dfs2(...,type='vertical')
Thanks. I'll try and implemented something pragmatic.
@stkistner I am curious - could you describe the need a bit more? Is there an engine that needs this information? In that case I think we should consider to re-open :-)
@stkistner I am curious - could you describe the need a bit more? Is there an engine that needs this information? In that case I think we should consider to re-open :-)
I think it's best described in the FAQ for MIKE.
When using dfs2 files for boundary conditions, the x-axis defines the spatial extension in the horizontal plane and the y-axis is interpreted as the extension in the vertical given relative to a level defined by the y-axis origin. The z-level for the rows in a dfs2 file is found by
z(j) = origin(y) – dy*(NY – j)
where dy is the grid-spacing in y-axis direction, NY is the grid size -1 and Origin(y) is the level for the upper row (j=NY).
It's a niche case, but I have used this type of functionality to create vertical boundaries from HYCOM or CMEMS.
Another example was when trying to convert a Dfs2 that was incorrectly read in as a non-spectral Dfs2 to a spectral Dfs2. But without the x0 or y0 data available anywhere it's not possible. The solution was to throw an Exception telling the user to use the type='spectral'
@jsmariegaard on another related note:
I have a Dfs2 from a model with a UTM projection. The Geographical info of the spectrum includes the northing of the projection, e.g. see below:
When read with mikeio, this is added to the direction-axis of the spectral data: