You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Second: I am probably missing something obvious, but I am having difficulty understanding the rainfall input data format. From the read the docs, the rainfall data is "the rainfall rate at each rainfall input time step in mm/hr". Is it therefore a single column of data where the length of that column is equal to the number of time steps defined by max_run_duration in seconds divided by max_time_step? In the test run on Boscastle paleoDEM_v1_72hr_rain_u.txt has 864 rows, which is 72hrs in seconds divided by 300 seconds. However, paleoDEM_v1_72hr_rain_u.txt also has 28 columns, why?
Furthermore, I tried to run a 10 day simulation. I chose a max_time_step of 1000 seconds, and a max_run_duration of 240hrs. This means that my rainfall data should have 864 rows and one column. HAIL-CAESAR ended with a segmentation fault at some point after 2.5 days of model time. I increased the length of my rainfall input to 1000 rows, and the segmentation fault occurred at some point after 3 days. Therefore I am now guessing that the number of rows within the rainfall data file is not given by the max_time_step, but the actual time step the model uses based on the CFL condition?
The text was updated successfully, but these errors were encountered:
I think I found part of the answer to my own question:
rain_data_time_step:
The timestep of the rainfall inputs. Note: even if you set this to something other than 60 (for hourly rainfall), the units are always mm/hr. I.e. this is the instantaneous rainfall rate at each timestep.
(This often happens to me after I write the question and click send, sorry)
Try looking at the wiki for tab parameters on the Caesar Lisflood pages.
On 25 May 2020, at 08:55, John Armitage <[email protected]> wrote:
I think I found part of the answer to my own question:
rain_data_time_step:
The timestep of the rainfall inputs. Note: even if you set this to something other than 60 (for hourly rainfall), the units are always mm/hr. I.e. this is the instantaneous rainfall rate at each timestep.
(This often happens to me after I write the question and click send, sorry)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#33 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACXM2LLVF6YBM5ASOUBDDDDRTIP45ANCNFSM4NJJWHTA>.
First: could I say that this code is great!
Second: I am probably missing something obvious, but I am having difficulty understanding the rainfall input data format. From the read the docs, the rainfall data is "the rainfall rate at each rainfall input time step in mm/hr". Is it therefore a single column of data where the length of that column is equal to the number of time steps defined by
max_run_duration
in seconds divided bymax_time_step
? In the test run on BoscastlepaleoDEM_v1_72hr_rain_u.txt
has 864 rows, which is 72hrs in seconds divided by 300 seconds. However,paleoDEM_v1_72hr_rain_u.txt
also has 28 columns, why?Furthermore, I tried to run a 10 day simulation. I chose a
max_time_step
of 1000 seconds, and amax_run_duration
of 240hrs. This means that my rainfall data should have 864 rows and one column. HAIL-CAESAR ended with a segmentation fault at some point after 2.5 days of model time. I increased the length of my rainfall input to 1000 rows, and the segmentation fault occurred at some point after 3 days. Therefore I am now guessing that the number of rows within the rainfall data file is not given by themax_time_step
, but the actual time step the model uses based on the CFL condition?The text was updated successfully, but these errors were encountered: