Difference between revisions of "Mass Flux (ND24/25/26)"

From Geos-chem
Jump to: navigation, search
(initial draft for Mass Flux general information)
 
(corrected vertical flux information)
Line 5: Line 5:
 
The eastward flux (EW) is positive if it goes east, and is the flux into the western 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:
+
The updown flux (UP) is positive if it goes down, and is the flux at the top of the box.
# It is the flux '''at the top''' of the box if you are using GEOS-3 met fields (i.e., positive if down).
+
# 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.
+
  
  
Line 32: Line 19:
 
== Related bug fix ==
 
== 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.
 
(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-??
+
This has been corrected in v7-04-12 or 13.
  
 
(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:
 
(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:

Revision as of 16:28, 12 December 2008

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 down, and is the flux at the top of the box.


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-12 or 13.

(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)