Thoughts on ROMS design as it pertains to coupling

Suggest improvements/optimizations to the ROMS code.

Moderators: arango, robertson

Post Reply
Message
Author
dschaffer

Thoughts on ROMS design as it pertains to coupling

#1 Unread post by dschaffer »

I'm working on the coupled WRF/ROMS model and am trying to modify ROMS so that it fits easily in the coupled system. In doing so, a few important design issues come up that I thought you both should think about for down the road.

Coupled WRF/ROMS can be run in two modes; sequential and concurrent. In concurrent, some of the processors execute WRF and the others execute ROMS. The way ROMS is setup right now works fine for that. However, in sequential mode, I run into difficulty. Here, all processors execute ROMS then all processors execute WRF then ROMS then WRF, etc. In this mode, we need to have an INIT, RUN and FINALIZE interface
for each model. That way, the coupler driver program can be written as follows:

Code: Select all

      CALL init_ROMS
      CALL init_WRF
      DO i=1,Nsteps
        CALL run_ROMS
        CALL run_WRF
      END DO
      CALL finalize_ROMS
      CALL finalize_WRF
John and I are making that modification now for WRF and I am thinking about how to do that for ROMS as well. One issue is how many steps each model should run for. I will argue that a good design is for the master program to simply tell each model how many model seconds to run for. Then each model will use its DT to figure out how many time steps that corresponds to. In the models, I would think that number depends on the nest level as well since the different grids impose different CFL conditions. At the moment, (at least my version of) MPI-ROMS simply gets the number of times steps from the ocean.in file. Now the master program looks like the following:

Code: Select all

      CALL init_ROMS
      CALL init_WRF
      run_interval=1.0*secods_per_hour
      hours_to_run=6.0*seconds_per_hour
      Nsteps=hours_to_run/run_interval
      DO i=1,Nsteps
        CALL run_ROMS (run_interval)
        CALL run_WRF (run_interval)
      END DO
      CALL finalize_ROMS
      CALL finalize_WRF
Another issue is when each model exchanges boundary conditions with the model. This is messier. Currently Chris Moore has hacked in a coupling interval into the namelists for both WRF and ROMS. But that means the coupling interval has to be specified in each model's namelist and the master program. A simple but somewhat inelegant solution is to pass the coupling interval as an argument into the run routines. Let's do this for the concurrent case:

Code: Select all

      coupling_interval=1.0*seconds_per_hour
      run_interval=6.0*seconds_per_hour
      IF (I_AM_A_ROMS_PROCESSOR) THEN
        CALL init_ROMS
        CALL run_ROMS (run_interval, coupling_interval)
        CALL finalize_ROMS
      ELSE
        CALL init_WRF
        CALL run_WRF (run_interval, coupling_interval)
        CALL finalize_WRF
      END IF
Ideally, both models would be redesigned a bit so that the coupling occurs outside of the model entirely. This is what we did at NASA with our coupled atmosphere/ocean model. This requires exposing opaque model state objects to the master program. In this case, the master program would look like the following for the sequential case:

Code: Select all

      CALL init_ROMS (ROMS_STATE)
      CALL init_WRF (WRF_STATE)
      CALL init_couple_WRF_to_ROMS (ROMS_STATE, WRF_STATE, WRF_TO_ROMS_STATE)
      CALL init_couple_ROMS_to_WRF(ROMS_STATE, WRF_STATE, ROMS_TO_WRF_STATE)
      run_interval=1.0*seconds_per_hour
      hours_to_run=6.0*seconds_per_hour
      Nsteps=hours_to_run/run_interval
      DO i=1,Nsteps
        CALL run_ROMS (ROMS_STATE, run_interval)
        CALL couple_ROMS_to_WRF (ROMS_STATE, WRF_STATE, ROMS_TO_WRF_STATE)
        CALL run_WRF (WRF_STATE, run_interval)
        CALL couple_WRF_to_ROMS (WRF_STATE, ROMS_STATE, WRF_TO_ROMS_STATE)
      END DO
This approach has the attractive feature that only the master program and the couplers have to be know anything about coupling intervals with other models.

Here is how it looks for concurrent mode:

Code: Select all

      IF (I_AM_A_ROMS_PROCESSOR) THEN
        CALL init_ROMS (ROMS_STATE)
      ELSE
        CALL init_WRF(WRF_STATE)
      END IF
      CALL init_couple_WRF_to_ROMS (ROMS_STATE, WRF_STATE, WRF_TO_ROMS_STATE)
      CALL init_couple_ROMS_to_WRF (ROMS_STATE, WRF_STATE, ROMS_TO_WRF_STATE)
      run_interval=1.0*seconds_per_hour
      hours_to_run=6.0*seconds_per_hour
      Nsteps=hours_to_run/run_interval
      DO i=1,Nsteps
        IF (I_AM_A_ROMS_PROCESSOR) THEN
          CALL run_ROMS (ROMS_STATE, RUN_INTERVAL)
        ELSE
          CALL run_WRF (WRF_STATE, RUN_INTERVAL)
        END IF
        CALL couple_ROMS_to_WRF (ROMS_STATE, WRF_STATE, ROMS_TO_WRF_STATE)
        CALL couple_WRF_to_ROMS (WRF_STATE, ROMS_STATE, WRF_TO_ROMS_STATE)
      END DO
Dan Schaffer

tony1230
Posts: 87
Joined: Wed Mar 31, 2010 3:29 pm
Location: SKLEC,ECNU,Shanghai,China

Re: Thoughts on ROMS design as it pertains to coupling

#2 Unread post by tony1230 »

Hi dschaffer
Can the coupled WRF/ROMS model work now?
Im usually have the WRF run first and then ROMS.
Im really want a trying on.

Post Reply