Hi there, I am running a JULES-ES suite (u-dj895) in JASMIN with INFERNO (fire dynamic model). INFERNO requires prescribed data for flash rate and population density for the ignition method I am using. However, there is a third term that does not affect the model with its absence but can be prescribed. The variable name is wealt_index. For this, it is suggested that the prescribed human development index (HDI) data be used. I am trying to prescribe this, but my model have failed in all my attempts (forrtl: severe (174): SIGSEGV, segmentation fault occurred). I have two datasets, one covering the period 2001-2021 and the other for 2001-2022. I have already try adding each of them, but I don’t find too much instruction. In ./app/jules/opt/rose-app-fire.conf, I changed changed n_datasets from 6 to 7, and add the following after the jules_prescribed_dataset(6):
My model runs from 2001 to 2021, for the longer dataset I used july instead of january to set every year data trying to imitate the population density data set.
I’ve had a look at the log files from your latest run of the suite and notice that instead of segmentation faults you’re now getting errors that say ‘register_input_file: Each input file must provide data for the entire run’. This is probably because data_start and data_end are the wrong way round under [namelist:jules_prescribed_dataset(7)] in the current version of rose-app-fire.conf. (It’s easy to miss; it took me a long time to spot it.)
Hi David,
I have made multiple attempts, and some of them popped up the error you mentioned, but most of them “forrtl: severe (174): SIGSEGV, segmentation fault occurred”. I am unsure if the order was wrong because, as you see in the screenshot of the original questions, data_end was in 2021, and data_star was in 2001; is that right?. Now, I also follow the prescribed population density dataset example, using the “ENDYR_PRESCRIBED” and “STRY”. I must say that I am a bit insecure about these years. In my mind, they should be 2022 and 2001, respectively. The original suite runs from 1800, and the population density has data from 1800. But I short the run Defined RESTART_HIST=true and RESTART_HIST_YEAR=2001 on ./rose-suite.conf
and in .model_scenario_info_isimip3a.dat it days finish in 2022 for the historical mode. Before adding the prescribed HDI, the model ran all right, producing output from 2001 to 2022 and starting in 2001.
I think the error relates to the dataset’s time variable or how I construct it. In my last unsuccessful attempt, I had the error “forrtl: severe (174): SIGSEGV, segmentation fault occurred” error. I added the variables “lat_bnds” and “lon_bnds”, copying the population density dataset.
I’ve been digging a little deeper into the suite configuration to see whether I can understand what is going on with the various year variables.
The year variables in model_scenario_info_isimip3a.dat appear to be used for two purposes in suite.rc. One is to specify the start and end times of the simulation (although I’m not sure exactly how this works in all cases). The other is to set the variables STYR, ENDYR, and ENDYR_PRESCRIBE, which are used in rose-app.conf and rose-app-fire.conf to specify data_start and data_end for the driving and prescribed data. This is the wrong thing to do when the simulation period is different from the time period covered by the driving or prescribed data.
According to the documentation at https://jules-lsm.github.io/latest/namelists/drive.nml.html and https://jules-lsm.github.io/latest/namelists/prescribed_data.nml.html, data_start and data_end should specify the start and end times of the files of driving and prescribed data, irrespective of the start and end times of the simulation. Thus if a file of prescribed data begins in 1800, the year in its data_start should be 1800, even if the simulation begins in 2001. In this case it’s probably simplest to use a hardwired year in data_start.
I’m not sure why this should lead to segmentation faults, however.
Hi David,
I made it as you said and used data_start=‘2000-01-01 00:00:00’ and data_end=‘2022-07-31 00:00:00’; I used data_start=‘2000-07-01 00:00:00’ before, but an error warning that I needed to start in January, so I changed it. After that, the error is the same forrtl: severe “(174): SIGSEGV, segmentation fault occurred”.
Hi!,
Just for the record, the model is running now. Yesterday, in my first attempt, I used the same prescribed data 5 (population density) as prescribed data 7 (the wealth_index), but I hard-wrote the data_start=‘1801-01-01 00:00’ and data_end=‘2021-07-31 00:00’. This did not work, so I copied the date format of prescribed data 5 using STYR and ENDYR, and It was running further than the usual error step. Then, I stopped it and rewrote my dataset over a copy of the prescribed data 5. Because my HDI data started in 2000, all data before that date is the population density data. Not the best, but it is running!
Take care. I believe that JULES ignores the values of the time coordinates in the driving data and prescribed data files. It assumes that the data starts at whatever date you specify with data_start. Thus if you specify data_start as ‘${STYR}-01-01 00:00:00’ where STYR=2001, JULES will assume the first record of the data file is from 2001 even if the time coordinate says that it’s from 1801.
If you can, check that JULES has used the driving and prescribed data from the right years (you might be able to tell from some variables in the output). Meanwhile I’m trying to get confirmation that JULES works in the way I think it does from somebody who has used it more than I.
Did you find out any information about how JULES processes the prescribed data? I was pleased to see that the last suite ran successfully, and I know it used the data (although I wonder if it was the correct data) because the results differed from the experiment with wealth_index=0. However, I am now running a more precise HDI dataset prescribing the wealth_index in other suite (u-dk870), and even though the suite acknowledges it (as I can see the task on Cylc), the results are the same as when wealth_index=0.
As far as I can tell from looking at the code, JULES ignores the time coordinate values in the driving and prescribed data files and instead relies on data_start/data_end/data_period in the namelists to tell it what times the data apply to. Other people whom I have spoken to are not convinced, however, and I may have missed something. I’m therefore conducting an experiment to see whether JULES behaves in the way that I think it does. I should have the results by the end of today. I’ll let you know then.
My experiment confirms my suspicion. JULES treats driving and prescribed data files as though they started at time data_start, ended at time data_end, and were spaced in time by data_period. Any time coordinate values that there might be in the file are ignored. It’s permissible for data_start to be before main_run_start and for data_end to be after main_run_end (as specified in namelist group jules_time). In this case JULES uses just the appropriate timespan from the middle of the driving or prescribed data.
It’s possible therefore that your earlier run used prescribed data from the wrong times. You will have to check the times in the namelist files.
Let me know if this doesn’t clear up you latest problem.
Hi David, thank you. I hard-wrote the 1801-01-01 as data_star, which runs, but I have had problems deciding on the data_end. Should it be on the first/last day of the final year, maybe the first day of the following year? I have annual data. In this conversation, I gave examples of dates I tried for the data_end, which never worked. My dataset finished has yearly data from 1801 to 2001, and it is set to mid-year in July in the dataset.
I have good news. It seems that the model read but ignored my prescribed dataset because I didn’t include units and long_name in the HDI variable.
HDI:units = “dimensionless indicator” ;
HDI:long_name = “Human Development Index (HDI)”
I spotted that in the data and then added it, and the results so far (still running) seem consistent with what is expected and different from those when the variable is not prescribed.
Hopefully, that resolves the issue. However, I still found it helpful to better understand the time setting for the prescribed data.
I haven’t tested it experimentally, but I believe that if you have annual prescribed data for the years 1801, 1802, …, 2001 and the interpolation method (interp) is nf, then you can specify data_end as 2002-01-01 00:00:00. You can then run simulations with main_run_end up to and including 2002-01-01 00:00:00.
