Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Setting runs with sf_ocean_physics (options 1 and 2) for domain with land and sea

Mr @kwerner can you recommend some material about my doubt above stated?
Essentially I would like to run experiments with a domain partially marine and terrestrial.
So I desire to specify different stratification over sea. But I cant find others references to solve the above issue.
I will be glad for any hint at this topic.

Best regards
 
Doulgas_secchi said:
Mr @kwerner can you recommend some material about my doubt above stated?
Essentially I would like to run experiments with a domain partially marine and terrestrial.
So I desire to specify different stratification over sea. But I cant find others references to solve the above issue.
I will be glad for any hint at this topic.

Best regards
Click to expand...
Variables specifically for the 3d ocean initialization with a single profile. Set
the ocean physics option to #2. Specify a number of levels. For each of those levels,
provide a depth (m) below the surface. At each depth provide a temperature (K) and
a salinity (ppt). The default is not to use the 3d ocean. Even when the 3d ocean is
activated, the user must specify a reasonable ocean. Currently, this is the only way
available to run the 3d ocean option.

&physics
sf_ocean_physics = activate ocean model (0=no, 1=1d mixed layer; 2=3D PWP, no bathymetry)

&domains
ocean_levels = 30,
ocean_z ; vertical profile of layer depths for ocean (in meters), e.g.:
= 5., 15., 25., 35., 45., 55.,
65., 75., 85., 95., 105., 115.,
125., 135., 145., 155., 165., 175.,
185., 195., 210., 230., 250., 270.,
290., 310., 330., 350., 370., 390.
ocean_t ; vertical profile of ocean temps, e.g.:
= 302.3493, 302.3493, 302.3493, 302.1055, 301.9763, 301.6818,
301.2220, 300.7531, 300.1200, 299.4778, 298.7443, 297.9194,
297.0883, 296.1443, 295.1941, 294.1979, 293.1558, 292.1136,
291.0714, 290.0293, 288.7377, 287.1967, 285.6557, 284.8503,
284.0450, 283.4316, 283.0102, 282.5888, 282.1674, 281.7461
ocean_s ; vertical profile of salinity, e.g.:
= 34.0127, 34.0127, 34.0127, 34.3217, 34.2624, 34.2632,
34.3240, 34.3824, 34.3980, 34.4113, 34.4220, 34.4303,
34.6173, 34.6409, 34.6535, 34.6550, 34.6565, 34.6527,
34.6490, 34.6446, 34.6396, 34.6347, 34.6297, 34.6247,
34.6490, 34.6446, 34.6396, 34.6347, 34.6297, 34.6247
Click to expand...

sf_ocean_physics = 0 ! activate ocean model (0=no, 1=1d mixed layer; 2=3D PWP, no bathymetry)
oml_hml0 = 50 ! oml model can be initialized with a constant depth everywhere (m)
< 0, oml is initialized with real-time ocean mixed depth
= 0, oml is initialized with climatological ocean mixed depth
oml_gamma = 0.14 ! oml deep water lapse rate (K m-1)
oml_relaxation_time = 0. ! Relaxation time (in second) of mixed layer ocean model back to original values
(an example value is 259200 sec. (3 days))
omdt = 1. ! 3D PWP time step (min). It can be set to be the same as WRF time step
in corresponding nested grids, but omdt should be no less than 1.0 minute.
ocean_levels = 30 ! number of vertical levels in 3DPWP. Note that the depth of each ocean
Click to expand...

Not sure if this will help you. Also can you attach your namelist.input for you specific wrf case you are interested in.
 
@Whatheway yes I was able to run WRF with those options. But the results become unstable for the sf_ocean_physics = 2 after a couple of hours.
But as mentioned in this post "problems running WRF with sf_ocean_physics option 2", sf_ocean_physics is seen to solve the ocean model for the entire domain. Do you know if that is true?
My domain is half land and half ocean, my doubt is if the ocean physics options can resolve only the ocean.

1681398964483.png
 
Doulgas_secchi said:
@Whatheway yes I was able to run WRF with those options. But the results become unstable for the sf_ocean_physics = 2 after a couple of hours.
But as mentioned in this post "problems running WRF with sf_ocean_physics option 2", sf_ocean_physics is seen to solve the ocean model for the entire domain. Do you know if that is true?
My domain is half land and half ocean, my doubt is if the ocean physics options can resolve only the ocean.

View attachment 9113
Click to expand...
Can you attach as a zip file all your rsl.out files and rsl.error files? I think I may have an idea but I want to check it first. I don't want to give you bad information.
 
Whatheway said:
Can you attach as a zip file all your rsl.out files and rsl.error files? I think I may have an idea but I want to check it first. I don't want to give you bad information.
Click to expand...
Also the namelist.input please
 
Sure @Whatheway, here a sample, the others files shows the same content.
The input for vertical profile I get from a global model.
 

Attachments

  • duvida_forum_oc3d.zip
    6 KB · Views: 8
Doulgas_secchi said:
Sure @Whatheway, here a sample, the others files shows the same content.
The input for vertical profile I get from a global model.
Click to expand...
From your name list I see that you are using 7 processors. This might be the problem because it is a prime number and doesn't make nice square grids. See below.

I would suggest trying an even number that meets the criteria in the recommended processors.

As for the namelist I don't see anything that screams wrong but I am not an expert in everything the namelist has.

The admins @kwerner and @Ming Chen or @jordanschnell know them better.

forum.mmm.ucar.edu

How many processors should I use to run WRF?

To choose an appropriate number of processors, you will need to consider the decomposition of the processes in relation to the size of the domains. For processing, your domain will be divided up into tiles, and the number of tiles depends on the total number of processors you use - 1 tile per...
forum.mmm.ucar.edu forum.mmm.ucar.edu


Decomposition will be determined based on the 2 closest factors for the total number of processors. So if you chose 16 processors, the decomposition would be 4x4, which is nice and even and creates a square grid. Choosing something like 11 processors would likely cause problems as the decomposition would be 1x11 since that is a prime number. We want to stay as close to squares as is possible, but that can be deviated from somewhat
Click to expand...
 
Thank you for that recommendation. But I tried to run again with 8 processors and the same problem occurred.
I will wait the response from the admins.
 
No worry @Whatheway. I was able to run sf_ocean_physics = 1(mixed layer model), the results are reasonable.
I will wait any response from the admins or other user to try option 2 later.
Thank you for the help
 
@Doulgas_secchi
Are you able to try more processors with this case? For e.g., try using 36 to see if that makes any difference. If it doesn't make a difference, please package up your new rsl* files into a single *.tar file (make sure to include all the rsl files), along with your latest namelist.input file, if you've made any modifications. Thanks!
 
Thank you @kwerner ,
I tried with 16 processors, our cluster only have 32 processors.
Bu the same error occurred.
I attached the output files, and a screenshot for temperature field.

I also tried with more processors but for some reason our cluster even run it.
I need to check this with IT team.
 

Attachments

  • ocean_2.tar.gz
    8.9 KB · Views: 4
  • Screenshot from 2023-04-17 18-28-01.png
    Screenshot from 2023-04-17 18-28-01.png
    132.4 KB · Views: 5
Thanks for sending that, and apologies for the delay. You mentioned that you're able to run with ocean physics option 1. When you use that option, is everything else identical? i.e., you can use the same input files, namelist, etc., but only modifying that one line in the namelist (sf_ocean_physics)?

It does seem that, when using more processors, it is at least computing longer than before, though the dates are different, so it's hard to say whether that actually indicates improvement. I do notice one odd thing in your namelist - you have p_top_requested = 5625.6, which is very specific, and I've never seen that. What happens if you use the default of 5000? Or if that causes an issue, what if you used something more even - like 5500 (without a decimal, for e.g.)?

Regarding the masking issue that was mentioned in the other post you referenced, I'm not sure how that was done. You could try to contact that user - click on their name and then click on "start a conversation."
 
No worries, thank you for your reply @kwerner.

Yes everything is identical when I run with ocean_physics = 1.
I was running different periods with that option, so when tried to run with option 2 again the files that I send are from another run, sorry for that.

About the p_top_requested, I cant remember well, but I think that value came from the DomainWizzard, but I will check that.
I send a direct message to the user some weeks ago, and I am waiting for his the response.


Thank you
 
Thanks for that information. Are you able to test this using a different p_top_requested, as I've mentioned above?
 
I was able to run the model with ocean_physics =2 using a &domain setting which I take as a example from the documentation:

Code: 
ocean_levels                        = 30,
 ocean_z                             ; vertical profile of layer depths for ocean (in meters), e.g.:
                                     =       5.,       15.,       25.,       35.,       45.,       55.,
                                            65.,       75.,       85.,       95.,      105.,      115.,
                                           125.,      135.,      145.,      155.,      165.,      175.,
                                           185.,      195.,      210.,      230.,      250.,      270.,
                                           290.,      310.,      330.,      350.,      370.,      390.
 ocean_t                             ; vertical profile of ocean temps, e.g.:
                                     = 302.3493,  302.3493,  302.3493,  302.1055,  301.9763,  301.6818,
                                       301.2220,  300.7531,  300.1200,  299.4778,  298.7443,  297.9194,
                                       297.0883,  296.1443,  295.1941,  294.1979,  293.1558,  292.1136,
                                       291.0714,  290.0293,  288.7377,  287.1967,  285.6557,  284.8503,
                                       284.0450,  283.4316,  283.0102,  282.5888,  282.1674,  281.7461
 ocean_s                             ; vertical profile of salinity, e.g.:
                                     =  34.0127,   34.0127,   34.0127,   34.3217,   34.2624,   34.2632,
                                        34.3240,   34.3824,   34.3980,   34.4113,   34.4220,   34.4303,
                                        34.6173,   34.6409,   34.6535,   34.6550,   34.6565,   34.6527,
                                        34.6490,   34.6446,   34.6396,   34.6347,   34.6297,   34.6247,
                                        34.6490,   34.6446,   34.6396,   34.6347,   34.6297,   34.6247

So I think that the problem was with the proper way to prescribe the vertical profile. I will do some tests to include a profile more suitable to my region of study.
I will show the output for TSK field using the ocean_physics =1 and =2:

ocean_physics = 1

Screenshot from 2023-05-02 10-39-30.png
ocean_physics = 2

Screenshot from 2023-05-02 10-37-44.png

The withe line is for inland and the red line for the ocean. The ocean_physics=2 start from the initial SST and speedup to the value prescribed at the profile.
But both have a little variation compared with the land diurnal cycle (less than a 1 degree celsius). For ocean_physics = 0 TSK over ocean is keep static, so my final doubt is if I can consider that options 1 and 2 are resolving only at ocean.
 
You must log in or register to reply here.
Top