Restart Time Not Found - D-Flow Flexible Mesh - Delft3D
intro story D-Flow FM
D-Flow Flexible Mesh
D-Flow Flexible Mesh (D-Flow FM) is the new software engine for hydrodynamical simulations on unstructured grids in 1D-2D-3D. Together with the familiar curvilinear meshes from Delft3D 4, the unstructured grid can consist of triangles, pentagons (etc.) and 1D channel networks, all in one single mesh. It combines proven technology from the hydrodynamic engines of Delft3D 4 and SOBEK 2 and adds flexible administration, resulting in:
An overview of the current developments can be found here.
The D-Flow FM - team would be delighted if you would participate in discussions on the generation of meshes, the specification of boundary conditions, the running of computations, and all kinds of other relevant topics. Feel free to share your smart questions and/or brilliant solutions!
Restart Time Not Found
I cannot attach the map file here because it is too large, but I am including the MDF and the .fil output for my model.
One thing that I thought might be related to the problem is that I seem to get a "drift" of times in my output when I view it with Quick Plot. If you look at the attached image you can see that the time displayed in quickplot is four seconds off from the beginning of the day, which is what should have been recorded. But I get this same time drift in the results of models that I am able to restart, so I'm not sure if it's related or not. I cannot start from this time, as it is not a multiple of my timestep.
Please let me know if anyone has any ideas about the cause of this problem.
*** Deltares, FLOW2D3D Version 5.00.10.1986, Nov 17 2012, 18:03:20
*** runid : peepB05
*** date,time : 2014-03-06, 11:07:23
*** MESSAGE 0 bed load fraction(s) found in sediment file: peepB.sed
*** MESSAGE Executable for 32-bits platform.
*** MESSAGE Double precision computation using reals of kind 8
*** Start of restart messages
Restarting from trim-peepB04.dat and trim-peepB04.def
*** ERROR Restart time not found on restart file trim-peepB04.dat
*** End of restart messages
*** ERROR Flow exited abnormally
Check the map file, there is an item called ITMAPC,
if ((tstart-ITMAPC*dt of your map file) > 0.5*dt of your map file) then Delft3D would through out this error: ERROR Restart time not found on restart file trim-peepB04.dat.
Can you check if it is true?
The possible solution is: use the input time interval setting as the map file output, i.e., Flmap = 1.8936000e+006 7200 8.236800e+006 and then use the last trim file as a restart file.
Thank you for your reply, and sorry it took so long to get back to you. If I am understanding your statement correctly, then this is not the problem I am having. You can see in the numbers below that the only ITMAPC that the statement (Tstart-ITMAPC*DT>0.5*DT) is true for is the very first one. But the very first timestep is the only timestep that I can successfully use to restart my model.
>>Tstart = 1.8936000e+006
The map-file is in single precision. It seems that you are facing the limitations of the restricted accuracy. You can check whether this is indeed the problem by producing a map-file to restart from based on a very short simulation period, close to the reference date. I expect that to work fine.
Can you report here on this forum whether that test works? Thanks in advance.
A tip that might help:
All times used are related to the reference date. If your reference date is far in the past these problems will occur. By moving the reference date as close to the simulation start date as possible, the problem might be solved.
If this does not help: can you isolate this problem in a testcase as small as possible and post its input files here on the forum? Thanks in advance again.
This sounds like it must be the case. The simulation that I am attempting to start now is peepB05, meaning that it is the fifth in a series, so I have inadvertently performed your test three times already, and didn't have problems restarting until I reached this specific date.
The date that I cannot restart beyond is August 8th, 2016, but my reference date is January 1st, 2013. Since all of my simulations involve long periods of time, I had been stopping them periodically to make backups. I also had a restart because of a power surge in the building.
Is there a) any workaround that would let me start from a date that is this far beyond the reference date?
b) any way for me to start a new simulation so that it can be restarted long after the reference date?
I haven't seen any activity on this post, but I'm giving it a bump because I'm still curious to know if anyone can think of a workaround for my problem.
I think that Adri's solution is the correct one, because I can't restart after 03-Aug-2016 in any of the simulations in this series of models. The one thing that makes me doubt, though, is that I've been able to restart other models after two to three times as much hydrodynamic time had passed so I'm not really sure what could be wrong here. But I am working under the assumption that the problem is with the single precision map files.
I'm thinking that one possible workaround might be to use the Matlab interface to write a Map file with a new date, and I could use that Map file for input to a new model when I restart. I would have to change the dates on my boundary conditions to align with the new reference date, but I can do that if necessary. But while I see that Quick Plot has a feature that allows me to write a new map file, I don't seem to have direct access to that function using Matlab. I would like to find a way to alter the data that I read in with vs_let.m and then alter the date and write a new map for input.
An very interesting topic. Let me summarize the problem here again. In the model input file, there is a refdate and a date/time for output in the map file. This map file is used a restart file for the next run. In the map file, it stores the refdate and every output time step. After a few rounds, In case the time step is too small, and simulation time is long, the time info stored in the map file is cutted due to the precision. Only single precision data is stored in the map file.
We had a discussion this morning. There are possible solutions, such as, you mentioned to modify the refdate info in the map file, but then you have to modify all the time point as well. Or we can leave the map file as it is now but update the code. Adri came up with an idea: we might be able to update the code in the way that if the restart file is from a map file, the ref date in the map file is read and also we know the new ref date through reading the mdf file, thus we can reconstruct the time stamp in the map file based on the new ref date at the first timestep of model running.
We registered this problem in our issue tracking system and put it on our todo list. However, you might be aware of, our todo list is very long and you cannot expect this will be implement in a short period.
There is another opportunity for you as well, if you would be able to update the code, we might guide you to do that and then commit it to the code repository, which will be reused by users from all around the world.
I hope I explained it clearly,
Thank you for your explanation, it is quite clear.
My programming skills in Fortran and C++ are very old and were never that good in the first place, so I don't think it would be a good idea for me to try updating the source code myself, except as a last resort.
I am interested in the first solution though - the one that involves updating the refdate and the output timestep in a map file. Is it possible to use the Matlab interface to access and alter the output time in the map file? If this is possible then I could use Quick Plot to output a map file that has only the last timestep in it, then alter the map timestep so that it is closer to the refdate. That would allow me to restart my model using the final timestep as the initial condition for the next simulation. If this is possible I could easily sort out the correct times in post processing.
I am also curious as to why this problem happened in this simulation, but not in others. I have restarted other simulations after more hydrodynamic time than this one without any problems. Is there something in my model setup that could avoid this problem altogether? Is it platform dependent? computer dependent?
There are several single precision issues related to a simulation date far away from the reference date. In one of them, also the size of the time step is involved (when counting the number of timesteps). Other simulations may not face these problems when they have a significantly bigger time step.
I don't know how to change refdate/times in an existing map file, but will ask some colleagues.
Thanks for following up on this. I had a conversation with Bert about this, and he put me on the right track towards changing the reference time in the map file. Basically, I need to update the reference time (ITDATE), then compensate for the update in the map times (ITMAPC and ITMAPS). And any time series files need to be adjusted to compensate as well.
I'm attaching a Matlab function that I wrote to accomplish this, in case someone else finds it useful. This file currently does account for the time series files, but does not account for time varying MORFAC in a .mft file.
I've tested it a bit, but not fully, so it should be used with caution until I do a more complete test.