Mass Flux (ND24/25/26): Difference between revisions
(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 | The updown flux (UP) is positive if it goes down, and is the flux at the top of the box. | ||
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)