spatially varying Jwtype in a forcing file

[d.kobashi]

Dear ROMS users/developers

I am trying to use spatially varying gridded Jwtype in ROMS.
I found a couple of days ago that in pyroms (https://github.com/kshedstrom/pyroms), there is a script, add_Jwtype_map.py, which creates a parameter, "wtype_grid" based on bathymetry.

I am curious to know how this works. On the ROMS manual, there is an cpp option called WTYPE_GRID, but the option appears not to be used in Rutgers ROMS as I could not find this option by "grep WTYPE_GRID *.F (or *.h)" in my ROMS code and even in the latest trunk (ROMS3.6 rev 687). In addition, this option seems to work only with LMD_MIXING (page 65 on the ROMS manual). How about other mixing schemes? I use COAWST which is based on ROMS 3.4, but I checked the latest trunk as well.

I wonder if someone can clarify that.

Thanks in advance.

Best regards,

DJ Kobashi, Griffith University

[arango]

No that option is not available in the Rutgers version of ROMS. This is probably a good idea. Such field can be added to the grid NetCDF file. The only routine that needs to be changed is get_grid.F plus the metadata for the new variable. See the logic for option UV_DRAG_GRID.

I put this option in the wish list...

[turuncu]

I think that it is better to add support for time varying WTYPE. The WTYPE could change by the time especially in the costal regions that includes the river (high/low discharge rate) or lagoons.

--ufuk

[arango]

That will be a little too much, I think. Where are you going to get the data for that? River runoff to the ocean is usually via estuaries and they are shallow. It will be sufficient to set a fix Jerlow water type. Having spatially varying Jerlow water type makes sense because you can correlate their values with the bathymetry. I don't recall seeing a climatology for water type. I suppose the that you may estimate that from satellite ocean color images.

As with any type of ROMS forcing, I will include an analytical function for it. So it is possible for an user to code any spatial/temporal functional. It will be tricky to code such temporal functional.

I makes more sense to associate the water type with an ecosystem and/or sediment transport model.

[kate]

To the OP (original poster), welcome to the forking of code. There is a branch which supports this field, but it isn't in all the branches (yet). As Hernan says, it's not that difficult to add. You could also check the ice branch on github and search it for WTYPE_GRID, then splice it into your code. Be sure to save your hacked code (with git of course).

I think it would be a great idea for the sediment and ecosystem models to be affecting light attenuation.

[d.kobashi]

Thanks for letting me know that wtype-grid has been included in your branch, Kate.

I modified my version of ROMS based on your sea ice model and the model is now being tested (it is at least not giving an error so far).
I agree with you and Hernan that it would be a good idea to associate water type/light attenuation with ecosystem and sediment models to investigate for example, river-borne sediment plume etc. I am also currently investigating water visibility influenced by various physical processes based on in-situ data (offshore water intrusions, wave-induced suspension, mixing etc.), which is related to this matter. I may run ROMS to investigate the subject.

Thanks,

DJ Kobashi, Griffith University