Hello to all,
I'm trying to use the ext_frc_specifier field in order to force a burden of SO2 in the upper troposphere.
What I did is I created a netcdf file, taking the atm/cam/chem/trop_mozart/emis/extfrc.SO2.1.9x2.5_c101206.nc file as a basis. I added the dates of interest for us, with the corresponding SO2 loads at these times.
I'm then running CESM with the FSDWSF compset (WACCM with sulphur chemistry and CARMA sulphate), at a f19_f19 resolution.
The run seems to behave correctly over the 3 days of the simulation, but eventually ends with an error upon the reading of the SO2 forcing file:
incr_flnm: incstr returned -1
while trying to decrement
/[...]/inputdata/atm/forc_SO2.nc
(shr_sys_abort) WARNING: calling shr_mpi_abort() and stopping
(This is not an address error, as the file is correctly fetched in the beginning of the run.)
As I understand it, there is a fault trying to go backwards in time (?) upon that file. I reckon this happens when trying to create the restart files.
I have mainly two questions:
1) How does this "decrement" routine behave? It seems like it seeks for another file, whereas as I set up the thing, the whole input SO2 information is stored under the same netcdf file. Is there a filenames_list to use (as with met data) in which case I could split up my SO2 data date-by-date? Or is it that the date the decrement routine is looking for is not in my netcdf forcing file?
2) How often is the ext_frc_specifier for SO2 checked by the model? I wish to have a daily update (I wrote the SO2 burdens day by day), however I'm really not sure this is the case practically in my current set-up: having run a 3-day simulation, my cesm.log shows occurrence of calls to the SO2.nc file only at the very beginning of the run (and in the end, when trying to "decrement", which, as said above, causes to terminate). My guess would have been that the file be called at each new day of the simulation. Is there some namelist variable I need to set correctly for that to happen?
Thanks in advance for any help.
Cheers,
Thibaut.
I'm trying to use the ext_frc_specifier field in order to force a burden of SO2 in the upper troposphere.
What I did is I created a netcdf file, taking the atm/cam/chem/trop_mozart/emis/extfrc.SO2.1.9x2.5_c101206.nc file as a basis. I added the dates of interest for us, with the corresponding SO2 loads at these times.
I'm then running CESM with the FSDWSF compset (WACCM with sulphur chemistry and CARMA sulphate), at a f19_f19 resolution.
The run seems to behave correctly over the 3 days of the simulation, but eventually ends with an error upon the reading of the SO2 forcing file:
incr_flnm: incstr returned -1
while trying to decrement
/[...]/inputdata/atm/forc_SO2.nc
(shr_sys_abort) WARNING: calling shr_mpi_abort() and stopping
(This is not an address error, as the file is correctly fetched in the beginning of the run.)
As I understand it, there is a fault trying to go backwards in time (?) upon that file. I reckon this happens when trying to create the restart files.
I have mainly two questions:
1) How does this "decrement" routine behave? It seems like it seeks for another file, whereas as I set up the thing, the whole input SO2 information is stored under the same netcdf file. Is there a filenames_list to use (as with met data) in which case I could split up my SO2 data date-by-date? Or is it that the date the decrement routine is looking for is not in my netcdf forcing file?
2) How often is the ext_frc_specifier for SO2 checked by the model? I wish to have a daily update (I wrote the SO2 burdens day by day), however I'm really not sure this is the case practically in my current set-up: having run a 3-day simulation, my cesm.log shows occurrence of calls to the SO2.nc file only at the very beginning of the run (and in the end, when trying to "decrement", which, as said above, causes to terminate). My guess would have been that the file be called at each new day of the simulation. Is there some namelist variable I need to set correctly for that to happen?
Thanks in advance for any help.
Cheers,
Thibaut.