nick_szapiro@ou_edu
New Member
For a limited-area rectangular grid type, how are velocities and transport treated near the regional boundaries?
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Transport in regional domain
- Thread starter nick_szapiro@ou_edu
- Start date
-
- Tags
- cice consortium
Nick,To start, boundary conditions are controlled by setting restore_ice=.true. in the forcing_nml. If restore_ice=.false., then no boundary conditions will be applied. Boundary conditions are handled in ice_restoring.F90, subroutine ice_HaloRestore. You'll see there are 'hooks' or sections of code where aicen, vicen, vsnon, and tracers are relaxed to their resepctive restoring values (aicen_rest, vicen_rest, etc...). If you use restore_ic='defined', it will call set_restore_var, where code will apply some specified values. Otherwise, the code is currently setup to get restoring values from the outermost i,j locaitons. If you want to apply values from external files, or some other specified values, you will need to add a method to do so here. David
nick_szapiro@ou_edu
New Member
Hi David,Thank you for the reply.In ice_HaloRestore, I think that state variables like uvel, vvel, and strength have no corresonding *_rest values.
If this is correct, are these not needed?Cheers,
Nick
If this is correct, are these not needed?Cheers,
Nick
Hi Nick,I added a uvel_rest and vvel_rest to the code. That can be done at the beginning where others are added. e.g.: real (kind=dbl_kind), dimension (:,:,:), allocatable :: &
uvel_rest, & ! dah: added ice u velocity
vvel_rest ! dah: ice v velocity
Then you can allocate and read them in code where the others are read-in. Whether you need them or not is an interesting question. I have had discussions with folks saying that the forcing on the ice is most dominant, and the velocity you prescribe doesn't have much effect. However, I have found that the boundary velocity does have an effect for for my runs, though I admint I am using the (old) default EVP subcycles=120. Many studies have shown that to be very inadequate. (e.g., J.F. Lemiex et al., 2012, J. Comp. Physics, http://dx.doi.org/10.1016/j.jcp.2012.05.024. Hope that helps. Thanks,
David
uvel_rest, & ! dah: added ice u velocity
vvel_rest ! dah: ice v velocity
Then you can allocate and read them in code where the others are read-in. Whether you need them or not is an interesting question. I have had discussions with folks saying that the forcing on the ice is most dominant, and the velocity you prescribe doesn't have much effect. However, I have found that the boundary velocity does have an effect for for my runs, though I admint I am using the (old) default EVP subcycles=120. Many studies have shown that to be very inadequate. (e.g., J.F. Lemiex et al., 2012, J. Comp. Physics, http://dx.doi.org/10.1016/j.jcp.2012.05.024. Hope that helps. Thanks,
David
eclare@lanl_gov
Member
David, thanks for responding to this. You are correct, that the external forcing is likely more important. In fact, the initial velocity and stresses shouldn't matter at all, because the numerical solver should converge to a time-independent (VP) solution. But especially for smaller numbers of subcycles with EVP, which only approximates VP, it doesn't, and so the initial values at the start of the subcycling can matter for the details of the simulation. My experience is that it shouldn't matter for the "climate" (statistics) of the simulation, but that would be good to test for your particular domain, Nick.