FAMOUS

vflux_drift_xdbua.README
========================
(WARNING: this doc written a significant while after the mod. Sorry. Every effort has been made to remember the how and why, but some things may have become obscure)
r.s.smith@reading.ac.uk 25/09/12

This document attempts to describe the functioning of the salinity drift “correction” term in FAMOUS. Rigid lid ocean models such as the one in FAMOUS use virtual salt fluxes at the surface to parameterise water fluxes, as they cannot change their volume. The salt fluxes are calculated by multiplying the water flux applied by a salinity value. Assuming that the global water flux from the atmosphere model through the surface of the ocean is balanced, balance of the resultant the virtual salt fluxes can only be guaranteed if a globally constant reference salinity is used to convert water to salt. This is non-ideal, since local salinity changes are, in reality, proportional to the salinity of the water already present (adding freshwater to freshwater should not produce a salinity change, whereas adding freshwater to salty should). FAMOUS uses local salinity values to convert water fluxes to salt; early runs of the model found that, over the centennial timescales that FAMOUS is run on, there was considerable drift in the average salinity of the ocean that was not reflected in the water budget of the atmosphere model.

A correction term to match the global average salinity drift to the water budget of the atmosphere model was thus implemented. In brief: water fluxes and virtual salt fluxes are accumulated every timestep on every open ocean point. Once a year, these are integrated, and a single salinity tendency term is calculated that will bring the salt budget into line with the water budget (using a global reference salinity). This tendency is then added to every ocean point over the next year. Tendencies are also calculated for TCO2 and Alkalinity as the freshwater budget of the atmosphere can significantly affect their concentrations.

in detail
=========

An unconventional feature of the use of memory space in the UM should perhaps be noted first. The correction terms need to be in the model dump, so that the model can be stopped and restarted without affecting the salinity drift. For ease of implementation, this has been done by allocating a full 2D field in D1 memory, the new prognostic

(2,0,401) VFLUX CONSERVATION CORR.

despite the fact that the correction term is globally uniform. 401 is actually used to hold several numbers useful to the correction scheme. Each latitude line is identical (to prevent issues should the model be decomposed onto a different number of processors when it restarts). Index n, on each line, contains that year’s tracer correction term for tracer n. In the UM, 1=temperature, 2=salt, 3=TCO2, 4=Alkalinity (see UMUI for continuation of the series up to NT). Index NT+1 is used to store the total amount of time over which this year’s forcing terms have been accumulated, so that their averages can be simply calculated.

A further point: the accumulation of the surface water and salt forcings is only done on open ocean points - isolated inland seas in FAMOUS generally have highly unbalanced water budgets and have large salinity tendencies, becoming either progressively saltier or fresher until their salinities are capped. These poorly-modelled areas dominate the global salinity drift, but since they have no exchange with the rest of the global ocean, they can safely be neglected from our calculation. This is done via the new prognostic

(2,0,400) VFLUX CONSERVATION CORR. MASK

which holds a modified version of the land-sea mask, with the isolated inland seas blanked out. NB: although the Mediterranean appears to be isolated on the FAMOUS grid, exchange with the Atlantic is parameterised through a diffusive term in FAMOUS, so it is included in the correction calculation.

The scheme is controlled by the value of the L_VFLUX_CORR logical in the NLSTCOCN namelist, usually via the handedit vfdrift_pp.sh. This handedit also contains a STASH macro for the following fields, required for the calculation:

(2,30,280) WATER_FLUX*SALINITY/DENSITY m Gs**−1
(2,30,292) OLD- DO NOT USE: VIRT A-S FLUX CO2
(2,30,293) OLD- DO NOT USE: VIRT A-S FLUX ALK
(2,32,228) d/dt HICE THERMODYN
(2,32,229) d/dt GBM SNOWDEPTH THERMODYN

In the model, subroutine VFLUX_CORR is called every timestep from OCN_FOR_STEP. The surface freshwater forcing (metres/s) is calculated as:

water = ( (P-E)+(river)+(flux adjustment)-(change in snowdepth)*(snow density)-(change in icedepth)*(ice density) ) / RHO_WATER_SI

by gathering the following fields:

(2,0,165) PLE:PRECIP-EVAP INTO OCEAN KG/M2/S
(2,0,166) RIVER OUTFLOW INTO OCEAN KG/M2/S
(2,0,186) P-E FLUX CORRECTION KG/M2/S

(2,32,228) d/dt HICE THERMODYN m s-1
(2,32,229) d/dt GBM SNOWDEPTH THERMODYN m s-1

The virtual salinity flux (um_psu.metres/s - um_psu=(PSU-35)/1000.) that results from these water terms, as used in the model is calculated as:

s_acc = (surface SSS forcing)*1e-9 - (ice forcing of SSS)*(depth of surface layer)

by gathering

(2,0,144) RATE OF SALINITY CHANGE (ICE) PSU/S
(2,30,280) WATER_FLUX*SALINITY/DENSITY m Gs**−1

The dilution of TCO2 and Alk implied by surface water fluxes is taken from (2,30,292) and (2,30,293), multipled by the depth of surface layer.

The discrepancy in salinity (um_psu.metres) for each open-ocean surface box is then:

(s_acc-(water*REF_SAL))*c2ddts

with similar terms for TCO2 and Alk. REF_SAL=0.035, REF_ALK=2363., REF_TCO2=2075. The discrepancies are accumulated in the new prognostics

(2,0,402) ACC. SALINITY VFLUX
(2,0,403) ACC. ALK VFLUX
(2,0,404) ACC. TCO2 VFLUX

with the value of c2ddts added to the NT+1′th box of each latitude line in (2,0,401) as noted above.

On January 1st, area integrals of the tracer discrepancy terms are calculated, which are then divided by the total volume of the ocean and the accumulation time to form a tendency (eg um_psu/s) for each tracer which is stored in the N’th box of (2,0,401), and also written to stdout. The corrections are then added to the tracer concentrations in subroutine TRACER.

Page last modified on September 27, 2012, at 04:06 PM by robin