...
<model_id>_<partition_number>_rst.nc, or
Valid example: gtsm_0001_rst.nc<model_id>_<partition_number>_<timestamp>_rst.nc
Valid example: gtsm_0001_20160407_140000_rst.nc
pre-adapter activities: Convert input
...
scalar time series (optional)
The netcdf file(s) specified in the property "input_grid_files_to_convert" will be converted to files in arcinfo/curvi format. Each netcdf file will be converted to a file with the same path and name as the netcdf file but with a different extension (.amu, .amv or .amp). If the property "input_grid_files_to_convert" is not specified, then this step does nothing.
Conversion from variable to file extension
Each netcdf file should contain only one variable with grid data. A netcdf file with multiple variables with grid data results in an error. The extension of the created file depends on the name of the variable in the netcdf file. For example the original file input/x_wind.nc is converted to input/x_wind.amu
| netcdf variable name | extension |
|---|---|
| x_wind | .amu |
| y_wind | .amv |
| air_pressure | .amp |
| precipitation | not supported by DFlowFM (for rainfall DFlowFM can use the netcdf file directly) |
| any other name | not supported by DFlowFM |
Auxiliary grid file
pre-adapter (version Delft-FEWS 2017.01.01 and upwards) converts exported scalar timeseries from xml to external forcing files (i.e. .bc and .tim files). Please note the following:
- The pre-adapter reads the .ext files mentioned in the .mdu file, and finds here the files to check for keywords
- See Delft3D adapter with NetCDF run file#Templatefilesandkeywords on how to use template files and keywords.
- The pre-adapter can handle at most two different forcing files, so if you list more in the .mdu file they will be ignored.
- The pre-adapter assumes a timestep in minutes. Originally, the .tim files could only handle minutes. The newer .bc files can use any unit, but the pre-adapter still assumes minutes. The pre-adapter does -not- interpret the Tunit as described in the .mdu file (Implementing this would be an improvement of the pre-adapter.)
- Example config files can be found elsewhere on this wiki page
pre-adapter activities: Convert input grid time series (optional)
The netcdf file(s) specified in the property "input_grid_files_to_convert" will be converted to files in arcinfo/curvi format. Each netcdf file will be converted to a file with The format (meteo_on_equidistant_grid/meteo_on_curvilinear_grid) of each of the created files depends on whether there is an auxiliary grid file present for that file. To use an auxiliary grid file for a given netcdf file, it must have the same path and name as the netcdf file , but with a different extension (.grd.amu, .amv or .amp). If an auxiliary grid file is present, then the netcdf file will be converted to a curvi file of type meteo_on_curvilinear_grid that refers to the auxiliary grid file. Otherwise it will be converted to an arcinfo file of type meteo_on_equidistant_grid. For rectangular and curvilinear grids there must always be an auxiliary grid file present, otherwise an error is given. For regular grids no auxiliary grid file is needed.
| grid type | auxiliary grid (.grd) file needed | type of created file |
|---|---|---|
| regular | no | arcinfo file of type meteo_on_equidistant_grid |
| rectangular | yes | curvi file of type meteo_on_curvilinear_grid |
| curvilinear | yes | curvi file of type meteo_on_curvilinear_grid |
Order of grid cells written
the property "input_grid_files_to_convert" is not specified, then this step does nothing.
Conversion from variable to file extension
Each netcdf file should contain only one variable with grid data. A netcdf file with multiple variables with grid data results in an error. The extension of the created file depends on the name of the variable in the netcdf file. For example the original file input/x_wind.nc is converted to input/x_wind.amu
| netcdf variable name | extension |
|---|---|
| x_wind | .amu |
| y_wind | .amv |
| air_pressure | .amp |
| precipitation | not supported by DFlowFM (for rainfall DFlowFM can use the netcdf file directly) |
| any other name | not supported by DFlowFM |
Auxiliary grid file
The format (The order of the grid cell values in the arcinfo/curvi grid file created by this adapter depend on the type of grid (regular/rectangular/curvilinear). For regular grids (arcinfo meteo_on_equidistant_grid file format or curvi /meteo_on_curvilinear_grid file format) of each of the grid cells are always ordered per row from left to right, starting with the upper row of the grid. For rectangular grids (curvi created files depends on whether there is an auxiliary grid file present for that file. To use an auxiliary grid file for a given netcdf file, it must have the same path and name as the netcdf file, but a different extension (.grd). If an auxiliary grid file is present, then the netcdf file will be converted to a curvi file of type meteo_on_curvilinear_grid file format) the grid cells are always ordered per row from left to right, starting with the upper row of the grid. For curvilinear grids (curvi that refers to the auxiliary grid file. Otherwise it will be converted to an arcinfo file of type meteo_on_curvilinear_grid file format) the grid cells are always in the same order as in the netcdf file, which depends in turn on the order of the grid cells in the corresponding grid definition in Delft-FEWS (if the file was exported from Delft-FEWS). If an equidistant_grid. For rectangular and curvilinear grids there must always be an auxiliary grid file present, otherwise an error is given. For regular grids no auxiliary grid file is needed.
| grid type | auxiliary grid (.grd) file needed | type of created file |
|---|---|---|
| regular | no | arcinfo file of type meteo_on_equidistant_grid |
| rectangular | yes | curvi file of type meteo_on_curvilinear_grid |
| curvilinear | yes | curvi file of type meteo_on_curvilinear_grid |
Order of grid cells written
The order of is used, then the grid cell coordinates in the .grd file must be in the same order as the grid cell values in the corresponding arcinfo/curvi file. The easiest way to accomplish this is to run the adapter once, then check the order of the grid cell values in the created curvi file(s), then manually make sure that the grid cell coordinates in the corresponding .grd file(s) are in the right order.
Coordinate system used
The coordinate system for the coordinates in an grid file created by this adapter depend on the type of grid (regular/rectangular/curvilinear). For regular grids (arcinfo meteo_on_equidistant_grid file created by this adapter depends on the coordinate system used in the netcdf file, which depends in turn on the coordinate system (geodatum) in the corresponding grid definition in Delft-FEWS (if the file was exported from Delft-FEWS). Need to manually make sure that this is the same coordinate system as the coordinate system used by the model.
D-Flow FM data in Delft-FEWS
3D data: sigma layer vs Z layer
At the moment there is no example yet of a z layer D-Flow FM model connected to Delft-FEWS. All documentation and examples below are related to sigma layer models. Z layers are supported by the model adapter though. An example of import and display of z layers in a Delft-3D model can be found at Delft3D adapter - 4.3 Import and display 3D data (z layers)
Export of 3D data in generalAdapter (z layers) - NETCDF-CF_ZLAYERS
format or curvi meteo_on_curvilinear_grid file format) the grid cells are always ordered per row from left to right, starting with the upper row of the grid. For rectangular grids (curvi meteo_on_curvilinear_grid file format) the grid cells are always ordered per row from left to right, starting with the upper row of the grid. For curvilinear grids (curvi meteo_on_curvilinear_grid file format) the grid cells are always in the same order as in the netcdf file, which depends in turn on the order of the grid cells in the corresponding grid definition in Delft-FEWS (if the file was exported from Delft-FEWS). If an auxiliary grid (.grd) file is used, then the grid cell coordinates in the .grd file must be in the same order as the grid cell values in the corresponding curvi file. The easiest way to accomplish this is to run the adapter once, then check the order of the grid cell values in the created curvi file(s), then manually make sure that the grid cell coordinates in the corresponding .grd file(s) are in the right order.
Coordinate system used
The coordinate system for the coordinates in an arcinfo meteo_on_equidistant_grid file created by this adapter depends on the coordinate system used in the netcdf file, which depends in turn on the coordinate system (geodatum) in the corresponding grid definition in Delft-FEWS (if the file was exported from Delft-FEWS). Need to manually make sure that this is the same coordinate system as the coordinate system used by the model.
D-Flow FM data in Delft-FEWS
3D data: sigma layer vs Z layer
At the moment there is no example yet of a z layer D-Flow FM model connected to Delft-FEWS. All documentation and examples below are related to sigma layer models. Z layers are supported by the model adapter though. An example of import and display of z layers in a Delft-3D model can be found at Delft3D adapter - 4.3 Import and display 3D data (z layers)
Export of 3D data in generalAdapter (z layers) - NETCDF-CF_ZLAYERS
Scalar time series at the same geo point Z but with different X,Y are considered to be a Z-layer. All available Z’s are used to create a Z-axis (layer axis) in the NetCdf file, and the time series values are written to the associated Z element. To export scalar time series as Z_layers in GA with NETCDF-CF_ZLAYERS, use option <exportZLayers>true</exportZLayers> in the exportNetcdfActivity (see config example below).
An example for float salinity(time=5, node=26, z=40);
Values of Z-axis are stored in meters. Per parameter only one Z-axis is allowed. Different parameters may have different Z-axis. Z-axis values are sorted in ascending order. The number of stations in the nc file equals to the number of unique X,Y that are available in the scalar time series. The location id’s/names associated with the first (lowest) Z are written to the nc file as station id’s/names. If there are parentLocations configured, then the IdMap can
Scalar time series at the same geo point Z but with different X,Y are considered to be a Z-layer. All available Z’s are used to create a Z-axis (layer axis) in the NetCdf file, and the time series values are written to the associated Z element. To export scalar time series as Z_layers in GA with NETCDF-CF_ZLAYERS, use option <exportZLayers>true</exportZLayers> in the exportNetcdfActivity (see config example below).
An example for float salinity(time=5, node=26, z=40);
Values of Z-axis are stored in meters. Per parameter only one Z-axis is allowed. Different parameters may have different Z-axis. Z-axis values are sorted in ascending order. The number of stations in the nc file equals to the number of unique X,Y that are available in the scalar time series. The location id’s/names associated with the first (lowest) Z are written to the nc file as station id’s/names. If there are parentLocations configured, then the IdMap can be used to write the parentLocations id’s to the nc file. By default the long_name attribute of the parameters is equal to the parameter id. This default behavior is overwritten with the configuration of a parameter description in Parameters.xml, which will be used as long_name in the nc file instead. In GA the default missing value for time series is -999. You can overwrite it in GA using <missVal>, for example <missVal>NaN</missVal>
...
Please note that for running DFlow-FM from Delft-FEWS only a pre-adapter is needed (a post-adapter is not needed).
External forcing files
Example of changes to the config when dealing with a D-Flow FM model with scalar boundary conditions.
| Code Block | ||
|---|---|---|
| ||
Excerpt from .mdu file related to external forcing
[external forcing]
ExtForceFileNew = mackay_bnd.ext # ExtForceFileNew DDB uses new format
ExtForceFile = mackay_pioneer.ext # *.ext
Example .ext file with reference to .bc file:
[boundary]
quantity = waterlevelbnd
locationfile = mackay_bnd.pli
forcingfile = mackay_bnd.bc
With corresponing .pli file:
mackay_bnd
1 2
1.49201410e+02 -2.10467553e+01 mackay_bnd_0001
and corresponding .bc file:
[forcing]
Name = mackay_bnd_0001
Function = timeseries
Time-interpolation = linear
Quantity = time
Unit = minutes since 2017-01-01 00:00:00
Quantity = waterlevelbnd
Unit = m
$(FLOW_TIMESERIES: waterlevelbnd/mackay_bnd_0001)
Example .ext file with .tim file:
QUANTITY=discharge_salinity_temperature_sorsin
FILENAME=mackay_pioneer.pli
FILETYPE=9
METHOD=1
OPERAND=O
AREA=1
With corresponding .pli file:
pioneer
1 2
1.49099320e+02 -2.11482830e+01
and corresponding .tim file:
$(FLOW_TIMESERIES: Q_sim_fcst/pioneer)
Example config:
<exportTimeSeriesActivity>
<exportFile>timeseries.xml</exportFile>
<timeSeriesSets>
<timeSeriesSet>
<moduleInstanceSetId>URBS_Forecast</moduleInstanceSetId>
<valueType>scalar</valueType>
<parameterId>Q.sim.fcst</parameterId>
<locationSetId>DFLOWFM_river.$CATCHMENT$_$SUBCATCHMENT$</locationSetId>
<timeSeriesType>simulated forecasting</timeSeriesType>
<timeStep unit="minute" multiplier="15"/>
<relativeViewPeriod unit="day" start="0" end="3"/>
<readWriteMode>read only</readWriteMode>
</timeSeriesSet>
<timeSeriesSet>
<moduleInstanceId>ImportROMS</moduleInstanceId>
<valueType>scalar</valueType>
<parameterId>H.tidal.fcst</parameterId>
<locationSetId>DFLOWFM_coastal.$CATCHMENT$_$SUBCATCHMENT$</locationSetId>
<timeSeriesType>external forecasting</timeSeriesType>
<timeStep unit="minute" multiplier="30"/>
<readWriteMode>read complete forecast</readWriteMode>
</timeSeriesSet>
</timeSeriesSets>
</exportTimeSeriesActivity>
|
D-Flow FM model configuration example (single domain, 2D data import)
...