# Boundary conditions for scalar variables

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

#### flaounas

##### New member
Good afternoon,

In the recent past I have created a set of scalar variables to calculate the potential vorticity budget within the simulation domain. To do so I've created new scalar variables in the registry and a dedicated module in /physics. All scalars are successfully treated by the model they are well advected, updated and written in the output files (wcd.copernicus.org/articles/2/255/2021/). For a follow-up study I need to use nested domains and I have encountered some issues. Could you please help me out with the following two questions:

1) My first question goes to the registry flags, I've seen that several scalars have the dimension flags "ikjftb", e.g. "state real qv ikjftb ....". I understand "ikj" but not really the "ftb". I failed to find relevant information in the tutorials and technical description. Mimicking the moist variables, I have also inserted my own scalars with the same flags as the "moist" variables :
state real i_pvco ikjftb scalar 1 - \
i0rhusdf=(bdy_interp:dt) "TRPVCO" "PVCO" "PVU"

2) My second question goes to the use of boundary conditions for my scalars in the nested domain (I actually use a preset moving nest). Actually, I would like to treat the scalars independently within each domain, i.e. (i) values are not communicated between parent and nested domains and (ii) the nested domain has "normal" values at the edges (first and last grid points) as the parent domain does.

I tried several registry setups for my scalars by using different combinations of the "i0rhusdf=(bdy_interp:dt)" flags. Each combination had "u" and/or "d" and/or "f=(bdy_interp:dt)" and/or "s" removed. At best I am getting my scalars to have zeros at the edges of the nested domain which affects calculation of advection. Any advice would be more than welcome!

Tthank you,
Kind regards,
Emmanouil Flaounas

Emmanouil,
These are good questions.
1. b = a Boundary variable exists, t = a manually generated other Time level array is constructed, f = this is an member of a Four-d array
You can keep all of these as part of the description.

2. Take a look in the share/interp_fcn.F file, at a SIMPLE feedback subroutine (such as copy_fcnm). Write a subroutine that does what you want: the outer most row and column of the nested grid (all of the "n" variables) is consistent with the coarse grid (all of the "c" variables). Once you get close (or get stuck!), we'll meet back up again for the next step - calling your routine from the Registry for your new PV budget variables.

Emmanouil,

I am trying to understand your question a bit more.

If you set the namelist option feedback = 0, then the child domain does not send any information back to the parent domain. However, with the default registry switches ("f"), the parent domain forces the nested domain's boundaries at each coarse grid time step.

The fields that you are computing are similar to physics terms (in that they are computed at each (i,j), but they resemble passive scalars since they are advected, correct? Once a value of one of your scalars is advected out of the fine grid, it does not appear on the parent domain, correct?

Approximately how many of these 3d fields do you have per domain?

Dear Dave,

Yes, exactly, my scalars play no role in the resolved dynamics. They are functioning as tracers which are updated at every model time step. The simplest scalars are the "theta tracers". There is one such theta tracer for each parametrisation temperature tendency. Here follows a short description of what I have done and then I quickly reach to the problem (in the following, I put numbers to ease answering).

1) I introduce to the Registry.EM_COMMON about 20 new scalars here is an example of one of them :
state real i_thlw ikjftb scalar 1 - \
i0rhusdf=(bdy_interp:dt) "TRTHLW" "THLW" "K"

2) These scalars start the simulation with zero values. In "solve_em", right after the call to "first_rk_step_part1", I make simple calculations at every grid point to update the tracers, e.g.:
scalar(i,k,j,P_i_thlw) = scalar(i,k,j,P_i_thlw) + grid%dt * grid%rthblten(i,k,j)

3) The scalars get then advected by the model without any intervention from my part.

4) Up to here all good. Results look great for single domain simulations and model outputs were valuable for our cyclone studies.

5) Ok here is the part that I find difficult to deal with. Now I run the model for a follow-up study with one moving nested domain that follows a cyclone centre with preset moves. In our experiment setup we would like the parent domain to force no values at the edges of the nested domain. This is done to consider the tracers as direct result of the followed cyclone (i.e. they are not influenced by processes that take place out of the cyclone, within the parent domain).

6) In my test runs, I set feedback=0 in the namelist.input (after all in our study we do not take into account the parent domain outputs) and include few lines in solve_em (right after updating my scalars) to make sure that at every model time step my scalars have zero values in the parent domain:

IF ( (.not. grid%nested) ) then
scalar(i,k,j,P_i_thlw) = 0
endif

6) In my sensitivity tests, I also removed the registry switches "f=(bdy_interp:dt)", "u" and "d" for several tracers to check what I get. It seems however that the edges of the nested domain are always set to zero, i.e. following the values in the parent domain. Here I attach a picture of how one of the tracers looks like about a day after the initial conditions. The zeros at the edges of the domain are quite visible, as well as the effect of advecting these zeros at the sothwest part of the domain.

7) The ideal scenario is now to have "normal values" at the edges of the nested domain.