I'm sorry I didn't describe my problem clearly in my last post:viewtopic.php?t=6491. Now I would like to ask some of my recent doubts to yours roms experts:
1. I used roms_master_climatology_coawst_mw.m to generate ini, clm and bdy files for one and a half months. However, when I checked my ini and clm files, I found that the values of ubar and vbar were abnormal at the land boundary, which showed up as specks of outliers at the land edge,Just like the parts I've circled in black:
Could this be a bug in roms_zint_mw.m? I was a little worried that it would cause the model to blow up.
2. On the question of model spinup, I have read some material and have a general understanding of spinup cycles of ocean models at different scales. However, I'm not sure what the criteria are for determining whether a ocean model is spinup or not. in my case, I'm running a simulation range of about lat*lon = 10°*10°, and I'm mainly concerned with sub-mesoscale processes in this area. Then, can I judge that the entire model domain has reached its own climatology by looking at the changes in the relative vorticity of the entire flow field?
3. I saw that there is a CPP option in CROCO mode called WAVE_OFFLINE, which allows uesr to input wave data directly without coupling with wave model. I wonder if ROMS_rugter COAWST can do the same thing? If so, what cpp options do I need to activate? Where can I view the standard format of wave data input into the roms?
Thanks
some problems about coawst_ini.nc,spinup period and wave input
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: some problems about coawst_ini.nc,spinup period and wave input
1- i am not sure what is causing the blips at the coast. not sure i have seen this before. is it also in u and v? i would think so.
are you nudging to ubar vbar? if not, then it is not an issue.
3 - we used to run roms forced with the output from swan. to do that, we would run swan, make a roms forc file, and then run roms. but i have not done that in a very long time, because we want to study interactions both ways. the currents can greatly effect the waves. so i am not sure that method works any more, but you could try.
on a similar note, we are working to create a data layer of the wave information, so that roms could read it in via the esmf/nuopc style coupling, but that is in development. that would be what you need, but it may not be available for awhile.
are you nudging to ubar vbar? if not, then it is not an issue.
3 - we used to run roms forced with the output from swan. to do that, we would run swan, make a roms forc file, and then run roms. but i have not done that in a very long time, because we want to study interactions both ways. the currents can greatly effect the waves. so i am not sure that method works any more, but you could try.
on a similar note, we are working to create a data layer of the wave information, so that roms could read it in via the esmf/nuopc style coupling, but that is in development. that would be what you need, but it may not be available for awhile.
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: some problems about coawst_ini.nc,spinup period and wave input
thank you jcw for rapid reply
1. I did find some abrupt u and v values in some of the clm.nc I generated when I re-examined them, but I don't know how these interpolation errors happened. One annoying problem here: when I use roms_master_climatology_coawst_mw.m to generate ini and bdy files, it always generates the climatology for the corresponding grid, and then extracts the corresponding bdy file from the clm file. It's suitabale for short running times(~1 day), but when the simulation time is longer or, time resolution is higher(At a frequency of 3-hourly or less), the script will run much slower because it takes a long time to read the corresponding data from the OPeNDAP server and interpolate variables to corresponding C-grid points.
before generating the bdy file, we must first obtain the merged_clm file of the grid, which is often not necessary when we run ROMS cases. So my question is, is there a faster and easier way to get the bdy and ini files for the specified grid area?
3. Also, I noticed in previous posts that activating the wave-related CPP option was discussed. If I want to study the effect of waves on currents, can I write wave variables such as Dwave, Hwave, etc. into my forcing file (as described in varinfo.dat) and define WAVE_VF to calculate processes such as Stokes drift and wave dissipation accordingly? Are there any other CPP options that need to be activated?
1. I did find some abrupt u and v values in some of the clm.nc I generated when I re-examined them, but I don't know how these interpolation errors happened. One annoying problem here: when I use roms_master_climatology_coawst_mw.m to generate ini and bdy files, it always generates the climatology for the corresponding grid, and then extracts the corresponding bdy file from the clm file. It's suitabale for short running times(~1 day), but when the simulation time is longer or, time resolution is higher(At a frequency of 3-hourly or less), the script will run much slower because it takes a long time to read the corresponding data from the OPeNDAP server and interpolate variables to corresponding C-grid points.
before generating the bdy file, we must first obtain the merged_clm file of the grid, which is often not necessary when we run ROMS cases. So my question is, is there a faster and easier way to get the bdy and ini files for the specified grid area?
3. Also, I noticed in previous posts that activating the wave-related CPP option was discussed. If I want to study the effect of waves on currents, can I write wave variables such as Dwave, Hwave, etc. into my forcing file (as described in varinfo.dat) and define WAVE_VF to calculate processes such as Stokes drift and wave dissipation accordingly? Are there any other CPP options that need to be activated?
Re: some problems about coawst_ini.nc,spinup period and wave input
you can modify those m files as needed. and you can certainly search around for other tools.
for the wave forcing, as i said already, we used to run swan, save the data, create a roms forc file, and then run roms. in theory it used to work, and it might now. but i dont run the modeling system that way anymore. we run it coupled. so you can give it a try, but there might be some missing pieces because i have not been developing along those lines.
-j
for the wave forcing, as i said already, we used to run swan, save the data, create a roms forc file, and then run roms. in theory it used to work, and it might now. but i dont run the modeling system that way anymore. we run it coupled. so you can give it a try, but there might be some missing pieces because i have not been developing along those lines.
-j
-
- Posts: 31
- Joined: Thu Sep 21, 2023 2:52 pm
- Location: Sun Yat-sen University
Re: some problems about coawst_ini.nc,spinup period and wave input
Thank you for your detailed answer Dr.John. I think I know what to do next.