Mass Flux (ND24/25/26)

From Geos-chem
Revision as of 21:25, 4 April 2008 by Plesager (Talk | contribs) (initial draft for Mass Flux general information)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Sign and direction convention

The northward flux (NS) is positive if it goes north, and is the flux into the southern edge of the box

The eastward flux (EW) is positive if it goes east, and is the flux into the western edge of the box

The updown flux (UP) is positive if it goes into the box. But we have two cases:

  1. It is the flux at the top of the box if you are using GEOS-3 met fields (i.e., positive if down).
  2. For GEOS-4, GCAP, and GEOS-5, it is the flux into the box at the bottom of the box (i.e., positive if up).

Note: IDL budget codes must account for that difference.


Non zero Up/Down flux in the 1st layer

For GEOS-4, GCAP, and GEOS-5, the up-down flux is correct but its repartition is somewhat curious. The computational scheme assumes that there is no flux at the top of the atmosphere and then proceeds toward the surface, balancing one box at a time to get up-down flux at the bottom of the box. I mention this because of the curious implication when you arrived at the surface : there is some flux into the bottom of the first box!

The math and vertical balances are correct, and the fluxes are just a convenient representation. What is correct and matters is the net transport in a box or one layer: this is the correct way to use the flux information.

The point is that IDL codes like ctm_ox_budget just use a 0 flux at the bottom of the surface boxes. With GEOS4 and GCAP, they should consider the non-zero value returns by GEOS-Chem.


Error in NS flux estimate

When trying to rigorously balance one box, I found that the North-South flux is not 100% accurate. This is simply due to the box surface area and latitude. In GEOS-Chem, the mass gain in one box is proportional to:

( south_unit_flux - north_unit_flux ) * geometry( box ), [A]

where geometry depends on box surface and latitude. But we only save south*geometry(box). So when we try to balance the saved fluxes, the mass gain becomes:

south_unit_flux * geometry( box )  -  north_unit_flux * geometry( box above ), [B]

which can significantly differ from [A]. I got almost 2% in one time step for one box. In opposite hemispheres, the difference between the two calculations will tend to be opposite. One can imagine that errors will more or less cancel each other when balancing very large region. Because box surface does not depend on longitude, there is no similar problem with east-west flux.


Related bug fix

(1) For GEOS-3, two bugs have been found in August 2007. One is the initialization of the flux that was not correctly reset to zero when dealing with a new tracer. The other is that the UP/DOWN flux between the first and second layers was not accounted for. This has been corrected in v7-04-??

(2) For GEOS-4, GCAP, and GEOS-5, one line of code must be uncommented. It modifies flux diagnostic for boxes in the top two layers. It is line 797 of tpcore_fvdas_mod.f90. It says:

MASSFLUP(I,J,K,IQ) = MASSFLUP(I,J,K,IQ) + DTC(I,J,K,IQ)/dt

in the loop for K=1 when ND26>0. This has been corrected in v8-01-01.

--phs 17:25, 4 April 2008 (EDT)