<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>FM model Bathymetry and computation domain</title>
  <link rel="self" href="https://dlt-acc.firelay.cloud/c/message_boards/find_thread?p_l_id=4041874&amp;threadId=4393174" />
  <subtitle>FM model Bathymetry and computation domain</subtitle>
  <id>https://dlt-acc.firelay.cloud/c/message_boards/find_thread?p_l_id=4041874&amp;threadId=4393174</id>
  <updated>2026-05-12T17:47:33Z</updated>
  <dc:date>2026-05-12T17:47:33Z</dc:date>
  <entry>
    <title>RE: FM model Bathymetry and computation domain</title>
    <link rel="alternate" href="https://dlt-acc.firelay.cloud/c/message_boards/find_message?p_l_id=4041874&amp;messageId=4393302" />
    <author>
      <name>Arthur van Dam</name>
    </author>
    <id>https://dlt-acc.firelay.cloud/c/message_boards/find_message?p_l_id=4041874&amp;messageId=4393302</id>
    <updated>2017-01-05T13:56:24Z</updated>
    <published>2017-01-05T13:55:48Z</published>
    <summary type="html">&lt;div class="quote-title"&gt;Erik de Goede:&lt;/div&gt;&lt;div class="quote"&gt;&lt;div class="quote-content"&gt;&lt;br /&gt;&lt;ul&gt;&lt;li&gt;&lt;br /&gt;[..] For Delft3D FM this is completely different: the file is in NetCDF format and only bathymetry values for computational points are stored. So, the &amp;#34;-999&amp;#34; values are not an issue for Delft3D FM. They are absent!&lt;/li&gt;&lt;/ul&gt;&lt;br /&gt;&lt;/div&gt;&lt;/div&gt;&lt;br /&gt;Actually, it is slightly different. Bathymetry values of -999 are indeed less frequent in Delft3D FM, because you don&amp;#39;t need to have any computational points outside region of interest. Still, if you create a new grid, it will have no bathymetry values yet on the computational points, so these z values &lt;em&gt;are&lt;/em&gt; written as missing values -999 into the &lt;span style="font-family: Courier New"&gt;_net.nc&lt;/span&gt; file. Later, in the spatial editor in DeltaShell you can replace these by interpolated bathymetry data.&lt;br /&gt;&lt;strong&gt;NOTE:&lt;/strong&gt; if some of your bathymetry values still contain missing values -999 when starting a simulation, Delft3D FM will replace the bed levels of those grid cells that have no bathymetry on any of its corner points to the value of parameter &lt;span style="font-family: Courier New"&gt;BedLevUni&lt;/span&gt; (in DeltaShell via &amp;#34;Physical Parameters &amp;gt; Uniform bed level&amp;#34;).</summary>
    <dc:creator>Arthur van Dam</dc:creator>
    <dc:date>2017-01-05T13:55:48Z</dc:date>
  </entry>
  <entry>
    <title>RE: FM model Bathymetry and computation domain</title>
    <link rel="alternate" href="https://dlt-acc.firelay.cloud/c/message_boards/find_message?p_l_id=4041874&amp;messageId=4393296" />
    <author>
      <name>Erik de Goede</name>
    </author>
    <id>https://dlt-acc.firelay.cloud/c/message_boards/find_message?p_l_id=4041874&amp;messageId=4393296</id>
    <updated>2017-01-05T08:49:15Z</updated>
    <published>2017-01-05T08:49:15Z</published>
    <summary type="html">Dear Abdulla Mohamed,&lt;br /&gt;&lt;br /&gt;*) For Delft3D-FLOW the bathymetry file is in ASCII format and the data is stored for the whole MMAX*NMAX domain. Consequently, a lot of &amp;#34;-999&amp;#34; appear in non-computational points. For Delft3D FM this is completely different: the file is in NetCDF format and only bathymetry values for computational points are stored. So, the &amp;#34;-999&amp;#34; values are not an issue for Delft3D FM. They are absent!&lt;br /&gt;*)  In Delft3D FM there is no enclosure file yet. So, you cannot &amp;#39;abuse&amp;#39; the enclosure file to reduce the computational domain.&lt;br /&gt;*) The standard procedure is to apply dry points, both in Delft3D 4 and Delft3D FM. So, you can extent your model domain to areas on land. For example for flooding studies. By inserting dry points, these points become non-computational (and do not require any computation time and are not visible in plots anymore). The land boundary file has no effect on this.&lt;br /&gt;&lt;br /&gt;With kind regards,&lt;br /&gt;&lt;br /&gt;Erik de Goede&lt;br /&gt;Deltares</summary>
    <dc:creator>Erik de Goede</dc:creator>
    <dc:date>2017-01-05T08:49:15Z</dc:date>
  </entry>
  <entry>
    <title>FM model Bathymetry and computation domain</title>
    <link rel="alternate" href="https://dlt-acc.firelay.cloud/c/message_boards/find_message?p_l_id=4041874&amp;messageId=4393173" />
    <author>
      <name>Abdulla Mohamed</name>
    </author>
    <id>https://dlt-acc.firelay.cloud/c/message_boards/find_message?p_l_id=4041874&amp;messageId=4393173</id>
    <updated>2017-01-05T13:02:42Z</updated>
    <published>2016-11-01T16:21:12Z</published>
    <summary type="html">hello everyone, &lt;br /&gt;I recently converted a delft3D model into a delft3D-FM model and am trying to simulate it in the new GUI.&lt;br /&gt;In delft3D &amp;#34;non-values&amp;#34; for bathymetry are defined as -999. I am wondering if this is true in the case of the FM model as well. &lt;br /&gt;Is FM model going to ignore bathymetry points with -999 during the interpolation process?&lt;br /&gt;If I am not mistaken, in delft3D the grid enclosure file defined the flow computation domain for the model. &lt;br /&gt;Is there an equivalent in the FM to define the flow computation domain for the model? &lt;br /&gt;The FM grid I am working with extends over land, and I am wondering how to tell the FM model not to go beyond a certain boundary for computations as it is land. &lt;br /&gt;Is this accomplished in FM by the land boundary file?&lt;br /&gt;&lt;br /&gt;Any help on this will be much appreciated.&lt;br /&gt;&lt;br /&gt;Thanks in advance.&lt;br /&gt;&lt;br /&gt;Cheers, &lt;br /&gt;Abdulla.</summary>
    <dc:creator>Abdulla Mohamed</dc:creator>
    <dc:date>2016-11-01T16:21:12Z</dc:date>
  </entry>
</feed>
