Monday, October 25, 2010

Bulk forcing of ROMS

ROMS-ites,

I have a question with regard to applying surface forcing to ROMS, which I hope one of you can help me with. I want to run an Indian Ocean domain forced with the GFDL-CORE 2 data set. I would rather not explicitly prescribe the SST and SSS in my model, so I intend to use this data set to apply bulk forcing across the domain (which CORE in its native state appears to accommodate well). However, I would like to weakly relax/nudge the derived SST and SSS values back to Levitus so I can restrict my tracer evolution somewhat. As yet, I don't seem to be able to find a way to do this. It seems that if I explicitly define the surface forcing through the make_forcing algorithm then I can activate the QCORRECTION and SFLX_CORR keys. However, defining bulk forcing negates this option.

Can anyone help me with this? Are there other, possibly better, alternate approaches?

Thanks

Ben

2 comments:

  1. Hi Ben

    get_vbc.F is the part of the code which pertains to your question. By reading through it you will see the various CPP options one has in providing NetCDF surface forcing fields so that the code can derive the surface boundary conditions it needs. I stand to be corrected, but as far as I can tell from looking through the code (perhaps you can read through get_vbc.F yourself and double check) it is possible to derive the surface heat and salt flux using the bulk formulation as well as relax the surface heat and salt fluxes derived to a prescribed surface salinity and temperature field. I am not 100% sure if this is really necessary particularly when it comes to temperature... using the bulk formulation for the turbulent heat flux does mean that SST is damped towards the prescribed surface air temperature field which acts to constrain temperature. Perhaps it is more useful for salinity than temperature?

    I have not tried it myself but if you create a roms_frc.nc file with the SST and salt field you would like to relax to and a roms_blk.nc file with all the CORE atmospheric fields required to derive bulk forcing, I dont see why one can't choose CPP options such that the surface heat and salt fluxes are derived using the bulk formula and then these fluxes are relaxed to the prescribed SST and surface salinity fields. But I am not sure why you would want to use the bulk approach if you are going to relax?

    Also thought that I would let you know that Nicolette and I plan on posting a "How to run ROMS on the CHPC (iQudu and SUN)" blog soon, perhaps you will be able to add some points on running a nested configuration on the CHPC.

    Hope this feedback helps!

    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    Here is my understanding of what each function does which you might find useful when looking through the code (please correct any miss understanding)....

    get_vbc.F
    This is the routine which reads various forcing fields from NetCDF files and derives the vertical boundary conditions for momentum and tracers.

    get_smflux.F
    reads wind stress values to force ROMS directly from the NetCDF file.

    get_stflux.F
    reads tracer flux (temperature or salinity) values to force ROMS directly from the NetCDF file.

    get_bulk.F
    reads values of atmospheric parameters needed to derive fluxes using the bulk formula from NetCDF file.

    get_sst.F
    reads values from forcing NetCDF file of SST and SST surface net heat flux sensitivity used to correct the temperature fluxes.

    get_sss.F
    reads values from forcing NetCDF file of sea surface salinity used to correct the salinity fluxes.

    get_srflux.F
    reads values for the short wave radiation flux from forcing NetCDF file

    bulk_flux
    computes the surface wind stress and surface net heat and salinity fluxes from the provided atmospheric parameters using the bulk parametrization. It gives you smflux and stflx variables like get_smflux.F and get_stflux.F (only derived using bulk formulation instead of being read directly from a NetCDF file)
    %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

    ReplyDelete
  2. Thanks, Nat. I'm looking through this now. I have decided not to restore, but as CORE 2 has no predetermined sw and lw upward components (unlike NCEP2), I need to find out how to bulk calculate these from SST and albedo anyway.

    Cheers

    ReplyDelete