Pre-cursor simulations¶
Precursor or driver simulations are used to provide realistic turbulent inflow boundary conditions for another simulation, typically referred to as the 'target' simulation. The options for running precursor and driven simulations are specified under the &DRIVER header in namoptions.xxx. This provides two model functionalities:
1) To run a precursor simulation where instantaneous y-z planes at a specified index in the x-direction (iplane) are written every dtdriver seconds to output files (named *driver*).
2) To run a driven simulation where the inlet y-z plane (at i=ib-1 and i=ib) is determined by reading the *driver* files of a precursor simulation that has already been run.
Running precursor simulations¶
Precursor simulations are indicated by first setting idriver = 1 in namoptions.xxx. The set-up of the precursor simulation is then up to the users discretion. The other variables to specify are:
tdriverstart- specifies the number of seconds after which the *driver* files will start being written. If the precursor simulation is not a warm start then it is recommended to allow a sufficient amount of time for the flow field to develop to the desired state before starting to write to the *driver* files.dtdriverspecifies the timestep in seconds at which the y-z planes are written to the *driver* files. It is important to set this to be small (ideallydtdriver = dt) in order to reduce the requirement to interpolate these fields in the resulting driven simulation. However, depending on the case, this can be made larger with the advantage being a reduction in size of the *driver* files that are produced.iplaneis the index in the x-direction that you want to save the instantaneous y-z planes. For many cases the expected value isiplane = ieso that the outlet of the precursor simulation is saved.driverstoreis the number of timesteps that the user wants to write to the *driver* files. The total simulation time should therefore be equal or greater totdriverstart + (driverstore-1)*dtdriverseconds to ensure that the writing process completes. The driven simulation based off this precursor will be limited to a maximum run time of(driverstore-1)*dtdriverseconds (unless multiple precursors are run using warm starts).
Outputs:
- A file for each prognostic variable (e.g.
u0,v0,w0,thl0(ifltempeq = .true.) etc.) for each processor.The file names follow 'var"driver\_"nproc"."$expnr' where $var indicates the variable (NOTE: h is potential temperature under this convention). These files will hold the corresponding instantaneous y-z planes over the specified time period and are to be used to drive a driven simulation.
Running driven simulations¶
It is necessary to first have run a simulation following the above instructions. Driven simulations are initiated by setting idriver = 2. The following are guidelines for setting up the driven simulation:
- The driven simulation must have the same
jtot,ysize,kmaxandzgrid.inp.xxxas its corresponding precursor simulation. - The driven simulation must use the same number of cores as the precursor simulation.
- It is not necessary to apply a forcing to the driven simulation due to the enforced inlet-outlet boundary conditions.
BCxm = 3is the current index to enforce the required inlet-outlet boundary conditions. Boundary conditions in the x-direction for other prognostic variables will be overwritten by this and therefore do not need to be set.- The *driver* files from the precursor simulation must be copied from its output directory to the experiments directory of the driven simulation. For example, if the precursor is 001 and the driven simulation is 002 and you are working from the top uDALES directory:
cp outputs/001/*driver* experiments/002/. driverstoremust be equal to or less than the number of timesteps saved in the *driver* files (equivalent value ofdriverstorein the precursor simulation).driverjobnrmust equal the job number of the corresponding precursor simulation. Following the above example:driverjobnr = 001.runtimemust equal(driverstore-1)*dtdriverseconds or less wheredtdriveris from the precursor simulation. If this time limit is exceeded the simulation will be stopped as there will be no more data available to determine the inlet.- NOTE: It is important that buildings are not positioned too close to the downwind edge of the domain. The vortices and wakes downwind in the nearfield of the buildings can cause errors alongside the convective outflow boundary condition. The necessary distance is case specific. If this distance is too small a typical error will be that high velocities are found at the domain edge and these lead to slow simulations and dt tending to nought.