Forum_general

General

At this page you can post questions or start discussions on general topics related to Delft3D Flexible Mesh.

Please select a proper category below (if possible), to post your message or reply to an existing post. Please add tags to your posts to simplify searching.

 

** PLEASE TAG YOUR POST! **

 

 

 

 


Message Boards

Restart files as Initial conditions: How to deal with Time series boundary

BH
Bogdan Hlevca, modified 4 Years ago.

Restart files as Initial conditions: How to deal with Time series boundary

Youngling Posts: 13 Join Date: 4/25/16 Recent Posts
Hello,

I am quite happy with the current stat of the dflow-fm project I am working on, but as I advance into it I find some things that are unclear or not enough explained in the User Manual.

In short, I am limited on High Performance Cluster to 48 hours of compute time and given that I have a large mesh in 3D mode it will certainly go over that limit (currently running 2D scenarios).

I experimented with restart files and I think I understand how they work, but I am not sure what happens with the boundary conditions whey they are time series. With harmonic boundary conditions all is clear as it does not really matter that you start at a different point in time as long you align the phase.

However, when you have time series as boundary conditions the problem complicates as I am not sure how dflow-fm will interact with the boundary condition files when given a Start Time that is not the Reference Date.

For example if:
* Reference date (GUI) and RefDate (MDU) is the reference point that coincides with the start of the time series boundary conditions
* Start Time (GUI) and RefDate + TStart* Tunit (MDU) is the date-time where the computation starts, so that your results print that date-time from that point.

Question:
What I am not sure about is if dflow-fm will calculate the difference between Start Time - Reference Date (or Tstart*Tunit in MDU ) and skip the time series entries from the boundary condition files with a number of items equivalent with (Start time - Reference Date)/ (User Time step) or the equivalent in the MDU file (Tstart*Tunit)/DtUser


I am hoping that dflowfm does that, otherwise I will have for each restart to new create boundary condition files by cutting from the old ones the period of time that has been already simulated.

Please let me know if my assumption is correct. I could probably run a test and put some observers and compare with the boundary conditions.

On another note I noticed a BUG in GUI. I am running everything in Linux, but I configure some things in the GUI. I noticed a bug in version 1.0.3.33070. After importing a restart file into the Initial Conditions tree it cannot be deleted anymore. The delete floating menu is grayed out.

Thanks,
Bogdan

PS. I had an older community account for delft3d and I was unable to add the delft3dfm community to it. I had to create a new one to be able to post here. Is there any way I can merge these two accounts? Thanks
BH
Bogdan Hlevca, modified 4 Years ago.

RE: Restart files as Initial conditions: How to deal with Time series boun

Youngling Posts: 13 Join Date: 4/25/16 Recent Posts
I tried to run a simulation with a restart file used as Initial Conditions. It did not work.

Although dflowfm seems very busy and apparently performs some calculations as it takes a lot of computing power, it does not put data in any for the HIS, MAP or RST files beside the initial output information that was created at startup.

I configured the MDU file so that Tstart is 6 days after the RefDate and RestartFile=restart_file_timestamp_rst.nc . In addition there is a restart.meta which has ZipPath pointing to a zip file that inside has the same restart_file_timestamp_rst.nc

I see here some redundancies the MDU file and the restart.meta pointing to the same type of information but I am not user which one is used by dflowfm on Linux

After writing the above text I did a few more tests:

1) I commented out the restart file leaving the Tstart the same 6 days (in sec ) offset from the RefDate
=> The program is still stuch and outputs nothing.

2) I set Tstart to 0 and put back the RestartFile .
=> dflowfm starts outputing data right away

3) I set Tstart to a small value and put back the RestartFile .
=> dflowfm starts outputing data after a short interval

According to the 3 tests my understanding is that the main problem was the offset in Tstart. I may be wrong but I believe that dflowfm does not actually jump over the offset between RefDate to Tstart, but i actually calculates and ONLY starts outputting data after reaching the Tstart offset.

If this is true the following consequences also apply:
1) manipulating Tstart and Restart file will not help me reduce computational time. Instead, unfortunately we have to manipulate the boundary conditions time series so that they start at the same date-time corresponding to RefTim.

2) Tstart (Time Start in GUI) is less useful as it is just a small convenience function that can help with small time offsets and harmonic boundary conditions. Boundary conditions as time series do not benefit from Tstart and just changing RefDate and new sets of boundary conditions will be appropriate for a restart. Imagine how simple it would be to restart the computation with the same boundary conditions form a different point in time by just specifying a different Tstart and a RestartFile.

3) I suggest that when Tstart should be used in conjunction with RestartFile for helping with boundary conditions in time series format. dflowfm could jump a number of items in the time series (Water levels, flows, wind , etc) and start computation after jumping instead doing the whole calculations from RefTime and only recording data after Tstart interval. It is a waste of time and computing resources in the case of this type of scenarios.

Please let me know if my assumptions are right and if there are any other ways of dealing better with time series as boundary conditions.

Thanks
Bogdan
BH
Bogdan Hlevca, modified 4 Years ago.

RE: Restart files as Initial conditions: How to deal with Time series boun (Answer)

Youngling Posts: 13 Join Date: 4/25/16 Recent Posts
I tried one more test in which I put cross sections for tributaries at the boundary

1) I ran a test with RefDate=Aug01 and another one RefDate=Aug08
2) Both had Tstart=0 and both had the same boundary conditions starting Aug01
3) The tributary outputs captured were different and matching the respective values form the boundary conditions

=> dflowfm actually calculated the offset for the boundary condition file and skipped the unnecessary part. Therefore no manipulation of boundary condition files is necessary.

It would be nice if someone would document this in the manual, it would have saved me a day of work and perhaps many other days for other people.

Bogdan
MK
Michal Kleczek, modified 4 Years ago.

RE: Restart files as Initial conditions: How to deal with Time series boun

Padawan Posts: 53 Join Date: 10/23/14 Recent Posts
Dear Bogdan,

Thank you for joining the new forum. Sorry for the long delay between your question and our response.
Indeed Dflowfm skips the Boundary Conditions that are outside of simulation scope. In the attachment you may take a look into the plot that perhaps will help you clarify the simulation time-set flow. It will be added to the User Manual.
In the Delft3D Flexible Mesh we use module that is responsible for reading external files. Dflowfm sends current time to the EC-module, which verifies if there is appropriate boundary condition to apply. If yes Ec-module sends back the proper information to the computational core; if not Dflowfm continues.

When using the Restart files in the past we were overwriting the Tstart. After some feedback from users we no longer modify Tstart. This implies that when you run a simulation with different Restart File, Tstart stays as originally specified in the mdu file.

Overall:
- you do not need to manipulate boundary conditions
- you can shorten your simulation by playing with Tstart and/or RefDate if using Restart file
- we will add extra information to User Manual, so the model specification becomes more straightforward to users

If you have any more questions/suggestions please let us know.
Of course, I recommend update to the newer version of the Dflowfm since we are continuously working on updates and upgrades.

Kind regards,
Michal