Very rare problem with LANDMARK

[marianfrias]

Hello everyone.
I'm stuck with a very weird problem. As you can see attached, wrf changes my landmark, which affects some other variables (like T2) and that makes my simulation a shit. This happens in real.exe, the geo and met's are ok.As you can see from the south till Nova Scotia everything is ok, but from Nova Scotia to the North the Landmark goes crazy. This problem is already affecting my lakes as you can see in the geo/met grid.
Thank you very much.
Kind regards

 

[kwerner]

Hi,
1) Can you let me know which version of WRF and which version of WPS you are using?
2) What type of input data are you using?
3)For the 2 plots you posted, exactly which files correspond to those plots?
4) Can you please attach your namelist.wps file, and your namelist.input file?
Thanks!

 

[marianfrias]

Hi kwerner, Thank you very much for your replay I'm very thankful.
I'm using 3.9 both WPS and WRF. I'm using the historical data from CMIP5-CLM4, which in fact are already done as intermediate files, you can see them attached, with the pdf datastream where the people explain how to work with this kind of data, basically is substitute them for the FILES coming usually from ungrib. (and do a couple of things in METGRID.TBL)
I will attach again the two photos because I have already moved along with the problem but it is not solved yet. As you can see, the LANDMASK in geo and met are okey, and till here everything seems to work fine, but in real.exe everything get fucked up. The LANDMASK thinks that SEAICE is already land, but the SEAICE evolves in the wrfout but not LANDMASK (is a static field I guess) but this is a problem, because some variables in wrfout work well, while others take the seaice as a static field too because it appears at LANDMASK as land, so they may take that part of ice as land and that have no sense. As appear in the picture, the LANDMASK in wrfinput has changed from the one of the metgrid, putting the seaice as part of the land. The problem is that SEAICE changes with time but no LANDMASK and obviusly that land is land and ice is ice, and the variables should be wrong then. I don't know what to do I have been stack for two weeks with this shit.
Those are my namelist:
&share
wrf_core = 'ARW',
max_dom = 2,
start_date = '1979-01-01_00:00:00', '1979-01-01_00:00:00',
end_date = '1979-01-08_00:00:00', '1979-01-08_00:00:00',
interval_seconds = 21600,
io_form_geogrid = 2,
/

&geogrid
parent_id = 1, 1,
parent_grid_ratio = 1, 3,
i_parent_start = 1, 40,
j_parent_start = 1, 28,
e_we = 130, 223, !!! 24 cores #carlos rule
e_sn = 133, 271, ! 28 cores
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!
! The default datasets used to produce the HGT_M, GREENFRAC,
! and LU_INDEX/LANDUSEF fields have changed in WPS v3.8. The HGT_M field
! is now interpolated from 30-arc-second USGS GMTED2010, the GREENFRAC
! field is interpolated from MODIS FPAR, and the LU_INDEX/LANDUSEF fields
! are interpolated from 21-class MODIS.
!
! To match the output given by the default namelist.wps in WPS v3.7.1,
! the following setting for geog_data_res may be used:
!
! geog_data_res = 'gtopo_10m+usgs_10m+nesdis_greenfrac+10m','gtopo_2m+usgs_2m+nesdis_greenfrac+2m',
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT NOTE !!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
geog_data_res = 'usgs_lakes+10m+default', 'usgs_lakes+5m+default',
dx = 30000,
dy = 30000,
map_proj = 'lambert',
ref_lat = 52
ref_lon = -70,
truelat1 = 60,
truelat2 = 50,
stand_lon = -70,
geog_data_path = '/home/alvarosf/scratch/wrf39/geog/'
/

&ungrib
out_format = 'WPS',
prefix = 'FILE',
/

&metgrid
fg_name = 'CCSM4_CMIP5_MOAR_BC_20THC',
constants_name = ,
io_form_metgrid = 2,
/

and input:

&time_control
run_days = 7,
run_hours = 0,
run_minutes = 0,
run_seconds = 0,
start_year = 1979, 1979,
start_month = 01, 01,
start_day = 01, 01,
start_hour = 0, 0,
start_minute = 0, 0,
start_second = 0, 0,
end_year = 1979, 1979,
end_month = 01, 01,
end_day = 08, 08,
end_hour = 00, 00,
end_minute = 0, 0,
end_second = 0, 0,
interval_seconds = 21600,
input_from_file = .true.,.true.,
history_interval = 360, 360,
frames_per_outfile = 1000, 1000,
restart = .F.,
restart_interval = 263520,
io_form_history = 2,
io_form_restart = 2,
io_form_input = 2,
io_form_boundary = 2,
debug_level = 0,
auxinput4_inname = 'wrflowinp_d<domain>',
auxinput4_interval = 360, 360,
io_form_auxinput4 = 2,
auxhist3_outname = 'wrfxtrm_d<domain>_<date>',
! auxhist4_outname = 'wrfrain_d<domain>_<date>',
! auxhist5_outname = 'wrf24hc_d<domain>_<date>',
ignore_iofields_warning = .FALSE.,
io_form_auxhist3 = 2,
! io_form_auxhist4 = 2,
! io_form_auxhist5 = 2,
output_diagnostics = 1,
auxhist3_interval = 1440, 1440,
! auxhist4_interval = 60,
! auxhist5_interval = 1440,
frames_per_auxhist3 = 1000, 1000,
! frames_per_auxhist4 = 1000,
! frames_per_auxhist5 = 1000,
! iofields_filename = 'iofields.txt',
/

&domains
time_step = 180,
time_step_fract_num = 0,
time_step_fract_den = 1,
max_dom = 2,
e_we = 130, 223,
e_sn = 133, 271,
e_vert = 27, 27
p_top_requested = 11000,
num_metgrid_levels = 27,
num_metgrid_soil_levels = 4,
dx = 30000, 10000,
dy = 30000, 10000,
grid_id = 1, 2,
parent_id = 1, 1,
i_parent_start = 1, 40,
j_parent_start = 1, 28,
parent_grid_ratio = 1, 3,
parent_time_step_ratio = 1, 3,
feedback = 0,
smooth_option = 0,
/

&physics
mp_physics = 6, 6,
ra_lw_physics = 3, 3,
ra_sw_physics = 3, 3,
radt = 30, 30,
sf_sfclay_physics = 1, 1,
sf_surface_physics = 5, 5,
bl_pbl_physics = 1, 1,
bldt = 0, 0,
cu_physics = 3, 3,
cudt = 5, 5,
isfflx = 1,
ifsnow = 1,
icloud = 1,
surface_input_source = 3,
num_soil_layers = 10,
sf_urban_physics = 0, 0, 0,
num_land_cat = 28,
sst_skin = 1,
sst_update = 1,
tmn_update = 1,
usemonalb = .true.,
paerlev = 29,
levsiz = 59,
cam_abs_dim1 = 4,
cam_abs_dim2 = 27,
bucket_mm = 100.0,
bucket_J = 1.e9,
/

&fdda
/

&dynamics
w_damping = 1,
diff_opt = 1, 1,
km_opt = 4, 4,
diff_6th_opt = 0, 0,
diff_6th_factor = 0.12, 0.12,
base_temp = 290.0,
damp_opt = 3,
zdamp = 11000.0, 11000.0,
dampcoef = 0.003, 0.003,
khdif = 0, 0,
kvdif = 0, 0,
non_hydrostatic = .true., .true.,
moist_adv_opt = 1, 1, 1,
scalar_adv_opt = 1, 1, 1,
gwd_opt = 1,
max_rot_angle_gwd = 100,
/

&bdy_control
spec_bdy_width = 10,
spec_exp = 0.33
spec_zone = 1,
relax_zone = 9,
specified = .true., .false.,
nested = .false., .true.,
/

&grib2
/

&namelist_quilt
nio_tasks_per_group = 0,
nio_groups = 1,
/

Thank you very very much, really thanks, i will invite you a beer for sure.
Best wishes

 

[kwerner]

Thanks for sending all of that. If you set "surface_input_source = 1" instead of 3 in the namelist.input, does that make a difference after running real.exe?

 

[marianfrias]

Thank you very much for being here helping me rly thanks.
Yes i have already tried and I got the same result than i get with 3

 

[kwerner]

Hi,
I just want to let you know I haven't forgotten about this. I was able to repeat the same thing using your met_em* file and my own met_em* file for a different date, with your domain. I believe this may have something to do with sea ice (perhaps it's being handled as land points), but I'm not certain. I've sent a message to our real.exe expert and will let you know what they say/advise. Thank you for your patience.

 

[kwerner]

Hi,
As I suspected, this is due to seaice. The WRF model wants to have the LANDMASK field be something that you can stand on, because then the LSM is active there. Any place that has seaice would be valid for the LSM to operate. The real program includes seaice as part of the modified land mask that is sent on to WRF. There is a namelist option you can set before running the real program, called "seaice_threshold" to say "if this is a water point and skin temperature is colder than some value, then make this grid cell an ice point" This is the description in the Registry:

rconfig   real    seaice_threshold        namelist,physics	1            100       h    "seaice_threshold"  "tsk below which which water points are set to sea ice for slab scheme"   "K"

 

[marianfrias]

Hi,
Sorry for take so long in answer ww have been very busy at university making plans for future against the situation of the world.
I tried that but it didn't work, i don't know why ,maybe because im using LSM of CLM4 and in the wrf manual it's said that seaice threshold doesn,t work for this lsm, could that be?
Thank you very much

 

[kwerner]

Yes, I'm sure that's why that option doesn't work. Unfortunately, if you are needing to use CLM4, then you won't have that option available, and I don't know that there is a way around the sea-ice problem.

 

[marianfrias]

Hi kwener.

I'm writing again because i'm rly desperate, i don't know what to do with this problem.
The real problem is the landsmask not evolving with time as seaice does, i have tried the seaice trheshold option with other lsm but it doesn't solve my problem, that variable convert ocean point in seaice, but that's not what I want. I need the landmask evolving, someone in the world should have done a simulation in a domain with seaice, do you know someone?
Please help me, i'm lost.
Thank you very much

 

[kwerner]

Hi,
I'm a bit confused by your statement. This is what I understand:

1) The seaice_threshold variable works okay with other LSMs (besides CLM).
2) When using seaice_threshold, grid points that are ocean and no longer seaice due to melting have now become water points, instead of land points.

If those are true, then are you saying that you want the actual land points (after melting) to change to water? Or are you perhaps saying that the landuse type (LU_INDEX) changes in those grids (from land to water), but the LANDMASK doesn't change?

 

[marianfrias]

Hi kwerner, first of all i want to thank you for all the support you are providing me, really appreciate that, as soon as all of this end I will find you to invite you to one hundred beers, you deserve it.

Yes seaice threshold works for a non clm LSM and it put my water points as seaice, so in landmask it changes into land points which is ok. But when I run wrf.exe the LANDMASK doesn't change, I start my simulation in january and the landmask says that in july the seaice points existing in january are still there which is not true, because the seaice variable works well and melt the ice in summer.

As you said, I need the seaice points return to water once they melt, the problem is that for most of the variables this works, but not for everyone, I attached one week of my simulation, you can observe variables as SEAICE,ALBEDO or ISLTYP working accord to the melting of the seaice, as most of my variables does. But if you take a look to the LANDMASK, SNOALB, SSTSK and LU_INDEX (which concerns me, because it looks important) they don't change, as I said this is just a week but enough for the seaice to change a little bit, as much as to observe it, but this variables that I told you doesn't change even in summer.

So i suppose that LU_INDEX or LANDMASK rules over some other variables, so I guess that if LANDMASK or lu_index would be evolving as seaice does my problem would be solve. But I don't know what more can I do I have tried everything.

Thank you very much, really thanks from my heart.
A hug.
Marian

Pd:I'm not allowed to send you the wrfout, it says file too large, so i attached photos of the variables at the beginning and ending of this week simulation,as i told you, seaice or isltyp change, but not landmask or lu_index. this evolution can be observed at Hudson bay.

 

[kwerner]

Hi,
So if you are using a non-CLM option, and you turn on seaice_threshold, are you still receiving unreasonable values for variables later in your run?

 

[marianfrias]

That's it.
I've tried right now again, but the problem appears to be the same, the LU_INDEX and LANDMASK are still static, don't evolve.
Have you solve the problem with seaice_threshold on your computer?
Thank you very much

 

[marianfrias]

Hi kwerner.
I got it!
Finally i Fixed the problem, the problem may be in the internal code of wrf, I solved this using the polar WRF modification, which changes some internal subroutines to fix this.
Just want to thank you very much for all your effort, really appreciate your help and your ideas, thanks to you now i understand better the wrf program, so I really want to thank you.
A big hug.
Thank you so much.
Marian

 

[kwerner]

Marian,
That is fantastic news! Do you mind attaching the modified code you used (if it's just 1, or a few files) so that another user may be able to see what was modified, if they were to run into the problem in the future? If it's too much trouble, no worries!

 

[marianfrias]

Helloooo.
Of course, this is the modified WRF version from http://polarmet.osu.edu/PWRF/(very good people) which I attach.
This contains the subroutines needed for fix this problem. It's just replace the subroutines as The README inside the tar says and follow the instructions. Be careful because you need exactly the same version of WRF to run this, at least I think so I had problems with other version except 3.9.1.
Thank you kwener.
See you.
A hug.
Marian