FAMOUS

(back up to Science Work Robin)

FAMOUS: updates as I scribbled them

March 09, 2012, at 10:02 AM

(text search for BUG to flag up the bug warnings)

Nov 2011

I’ve briefly written up the (minor) changes to xfxwb, and the top-level friction variation (xfhcc) for Geoscientific Model Development:

XFXWB and XFHCC update paper

so it’s now available to all as a discussion paper.

Also following on from Till’s analysis, it seems that the diagnostics for d(tracer)/dt due to advection are rather misleading/wrong in FAMOUS - they’re a bit muddy in all UM4.5 code actually. There’s code for diagnosing both U.grad(T) and div(UT) in there, with the default giving U.grad(T), for some reason - the source field is actually updated using div(UT), so U.grad(T) will not show how the model field has really evolved. HadCM3 had a rather blunt override mod to put div(UT) into the diagnostic again which was not carried across to the newer UM4.5 advection mods used in FAMOUS. It’s pretty straightforward to edit the advect.f file to show div(UT) in FAMOUS, or ask me for a “fixed” mod you can use.

Sep 2011

Till Kuhlbrodt has been looking at the Southern Ocean under climate change across a range of models, and noted that xfxwb FAMOUS was alone in not showing a strengthening of the SO westerlies under CO2 forcing. A quick bit of analysis shows that the (zonal, at least) wind changes everywhere in FAMOUS are generally inconsistent with CO2-forced HadCM3, and seem to all be linked to the unrealistic top layer. Introducing just the simple top-level friction into xfxwb seems to solve this: CO2-forced changes in the vertical wind structure look much more like other models, and surface wind changes poleward of 40degrees, especially in the Southern Ocean, look like HadCM3. (Sub)Tropical wind changes are still inconsistent (but smaller), and there are knock-on effects on the control climate in this model: the seasonal cycle of temperatures in the northern hemisphere is improved, the ACC is slowed even more than before, the AMOC weakens by a few Sv and deepens. I’m conflicted whether to make this a standard version, or stick to the original plan and wait for all the bells and whistles of xfhcy to be tuned and released.

Aug 2011

There’s some significant FAMOUS development going on (alebit slowly), so I’ll go back to trying to keep these pages up-to-date with things as they occurr. I guess there’s four things that ought to be flagged up:

this is a bug-fixed version of the model described in the GMD (2008) paper - see FAMOUS Standard Versions. Some runs have been done for the EMICmip contribution to AR5, and this is actually the version that was used in the Hawkins et al AMOC hysteresis paper and my long glacial transient runs - an update to the GMD paper is in the works.
this is a new release candidate for the long awaited MOSES2.2 (closed carbo cycle, dynamic vegetation) version of FAMOUS - see FAMOUS Standard Versions. The biggest new science over previous versions is the top-level friction detailed below. Tuning ensembles have been run by Jonny Williams@Bristol, so a useful release should be forthcoming in the near future
round about Christmas 2010 I decided to have a proper look at the stability issues that plagued FAMOUS when running colder-than-modern climates. There are more details below, but it all seems to link in with the 1sweep/2sweep timestepping mystery, the winter cold bias and pretty much everything that’s wrong with FAMOUS (well, almost), and it’s trivial to fix. There’s a hack fix for current release versions (stratcap.mod) that just improves stability, and a better, science fix (rayleigh_fric.mod) that improves the climate as well, but requires the climate to be retuned. stratcap.mod is included in xfxwb, rayleigh_fric.mod in xfhcy
my new project involves improving the coupling between the UM and the Glimmer-CISM icesheet model - previous work has relied on the simple, annual PDD scheme and an outdated version of Glimmer. We will require the multilayer snow scheme from JULES (now technically incorporated into FAMOUS) and to code up subgridscale hypsometry, along with modifications to the Glimmer-UM interface. Hopefully this can all be done within the CESM framework being developed for Glimmer-CISM at Los Alamos. Watch this space.

June/July ‘09

The occasional FAMOUS Pacific MOC I mentioned in the last update seems to be a symptom of an unfortunate, and puzzling, model sensitivity. It seems that pretty much all the recent work at Bristol has been done using the warm-bias “2 sweep” version of FAMOUS mentioned in CurrentWorkTimestepping, and that this version, as well as having a different surface temperature pattern, seems to have a very sensitive MOC, with increases in Pacific overturning being compensated by decreases in the Atlantic. I’ve investigated this further using Eemian climate runs, 1 sweep and 2 sweep (with appropriate sea-ice albedoes for each), with different areas of land icesheet present/removed. 1 sweep FAMOUS simulates mostly local responses to the changes in land surface, 2 sweeps produces large changes in ocean heat transport that cause large, non-local responses. Whilst it’s difficult to know which is right, the 1 sweep results are more in line with other model studies and what we expect from the system. The increased MOC sensitivity of all versions of 2 sweep FAMOUS, not just the warm-biassed ones, thus rather puts the kibosh on using 2 sweeps as a useful model tuning parameter.
This leaves the issue of how to solve the problem that motivated Bristol to start using 2 sweeps in the first place - instability of LGM/cold climates. I’ve had some success in reducing the frequency of model crashes by increasing the “filtering safety factor” from its default 1% up to 10%, the value apparently used in the operational model. Difference plots for surface temp after 100 year runs of these two versions, DJF and JJA can be seen below. Whilst there are significant differences in any given year, especially in the NHem in DJF, there doesn’t seem to be a consistent bias introduced by using the higher filtering factor, at least not for temperature in the way that 2 sweeps did.

Surface Temp difference plots: 10% filtering (HIGH) - 1% (LOW, standard)

DJF

Attach:djf_diffs.png Δ

top left - 10 yr average; top right - zonal averages for individual years; bottom panels - 4 individual years

JJA

Attach:jja_diffs.png Δ

top - 5 yr average; bottom panels - 4 individual years

MOSES2/TRIFFID update: initial attempts at improving the pre-industrial natural vegetation simulation through tuning the PFT’s growing parameters seems to have had surprisingly little effect. Other parameters will be looked at now, although so far all M2 work has been done with a 2 sweeps version of FAMOUS (see above), so the basic climate will have to be checked through now with 1 sweep instead.

May ‘09

MOSES2/TRIFFID info. Looks like we might finally have an acceptable FAMOUS+M2 setup, with non-appalling vegetation when TRIFFID’s switched on. The key seems to be using “aggregate tile” mode (set NTILE=1 in the namelists), which means that the surface tiles are averaged together before calculating coupling fluxes with the atmosphere, rather than calculating separate fluxes for each tile. This seems to help the shortwave biases (strictly, M2 corrects surface biases in M1 that seem to have been compensating for other errors) that result from using M2 without retuning the cloud params or unrealistically raising surface albedoes. This is probably be to aggregate mode increasing the surface evaporation, allowing more low cloud formation over land - I haven’t fully investigated the details. It also appears that I had unsuitable timesteps set for TRIFFID before also, which exacerbated the problems with interactive vegetation before. More details will appear on the MOSES2 section below.
I can now combine the M2 improvements with changes to the ocean and ice that seem to bring other improvements. This will involve fixing/unifying various bits of code that only seem happy on different platforms - and is also dependent on the status of the QUEST cluster and HECToR. I’ve got some specific tips on TRIFFID tuning as well from Manoj - A useable FAMOUS+MOSES2 (optional TRIFFID) with a better climate than current MOSES1 release FAMOUS (and better veg than the HadCM3LC used for that study in Nature) is actually looking like it might happen.
Julia Tindall, Peter Hopcroft and I are also investigating the details of the Pacific MOC that sometimes turns up in FAMOUS, but appears not to in similar HadCM3 runs. It’s not necessarily wrong, but needs explaining carefully, I feel.
FAMOUS on HECToR isn’t the happiest bunny in the world. Looks like there’s a memory leak in the atmospheric dynamics - possibly connected to the filtering - that can result in long runs running out of memory (my runs with 2 dynamic sweeps per step last around 30 years), and the MOSES2 code seems very unhappy, at least under the pathscale compiler. Without M2, you can workaround the memory problem with more frequent submissions.

Mar. ‘09

I’ve started putting up a few extra bits of climate analysis relevant to the latest MOSES1 releases of FAMOUS at xdbub_extra.
This MOSES2.2 climate really isn’t as bad as I thought, once you start comparing it to obs. At least, it’s not much worse, and often much better than the MOSES1 FAMOUSes. Grassing over the bare soil (and Needleleaf Trees!) brings the JJA northern hemisphere land warm bias pretty much back to what it was in MOSES1 FAMOUS, so it’s probably just a matter of tuning the veg in an acceptable manner. Careful tuning will be a little irrelevant if turning TRIFFID on wipes it all out, so I’m trying a run with interactive veg to see how that evolves.
Apparently the HadOCC diagnostic for zooplankton production isn’t that at all - it’s been hacked shows export calcite flux. Thanks to Vivian Scott@Edinburgh for pointing out the problem. It’s a trivial mod/line in biology.f edit to switch it back - search for “hijack”
Including TRIFFID actually helps the MOSES2 climate in general. Compared to MOSES1 FAMOUS there’s a still a large high latitude warm bias in winter, but this brings FAMOUS more into line with HadCM3 and reality. The MOSES2+TRIFFID summer warm bias over N.Africa and mid-Asia is a little worse than M1, but it’s not as bad as any of my other M2 runs (see above). The winter cold bias mid-Asia is a little worse in the TRIFFID run than the other runs though. Overall, looking at seasonal zonal mean surface temp plots, I’d say M2+TRIFFID looks better than M1 FAMOUS.
This is all with fixed 1860 CO2. The TRIFFID run has spun up to have less C3 and Needleleaf Trees, and less Broadleaf in mid-Asia and the Amazon, but more in other regions. Most of the PFT reduction is taken up by an increase in the bare soil fraction, most evident at northern mid-latitudes. Global average LAI is less for all PFTs, although the seasonality in the LAI index is a bit bigger in the TRIFFID run.

Feb. ‘09

I’ve been looking at the MOSES2.2 problems again. Having spun it up properly it seems that including a sensible seasonal variation of LAI and canopy height did more to help the land surface warm bias than I thought it did. The other thing that helps is making comparisions with climatological data - some of the warm biases occur in places where MOSES1 FAMOUS was too cold. So, compared to HadCRUT, the only areas where MOSES2 FAMOUS are worse than MOSES1 are northern, mid/high latitude land during JJA - particularly Russia and Alaska - where there’s a significant warm bias. Despite the soil params being the same as MOSES1, there’s lack of soil moisture and an increase in runoff in these areas. Crudely trying to force 99% less runoff globally helps soil moisture and temperatures in these areas a little, and doesn’t have much effect elsewhere - I suspect there are global differences between M1 and M2.2 that only really affect surface temperature in certain areas (i.e. Russia and Alaska). Despite M1 and M2.2 both having soil routines labelled as 5A, there are significant looking code differences in how drainage is handled. Given the limited effect of reducing the runoff I’ve started to look at vegetation: in the spirit of bizarre GCM experiments I’ve grassed over all the bare soil areas of the world to see what that does.
All my paleo ice-sheets/topographies have been derived from 1 degree resolution datasets. The gravity wave drag parameterisation at UM4.5 seems to be tuned to use subgridscale parameters derived at 10 minute resolution though, so I thought I should check whether this makes a significant difference. It doesn’t look like it does. So that’s handy.

Jan. ‘09

I’ve been looking up the whole “two dynamic sweeps per timestep” thing. It does definitely up the midlatitude EKE and increase the atmospheric heat transport - not entirely surprising, but it’s nice to know there’s some physics going on, rather than bad numerics. North Atlantic stormtrack strength is way up as well - if anything it’s too high, compared to the ERA data I’ve got. So far, so good.
My part of the FAMOUS wiki has been getting increasingly untidy for a while, and I still harbour hopes that people may occasionally come here to find useful information. Thus, I am pulling it apart and starting again in a more organised fashion. Please bear with me. My now-usual ramblings will continue to appear under “Updates”, with older entries filed away from the front page. Useful information from the updates will then appear in a more systematic way filed under the headings below. The old muddle can be accessed here if you need to.

Dec. ‘08

update on the self_shade issue: doesn’t look like running with the old self_shade mod but without HadOCC (e.g. xcpsb) has any significant effect on the climate. One test run did show a small coupling shock at going from the broken→fixed parameterisation, but there was very little difference once the climate had settled down.
an interesting development in timestepping. Ron Kahana at Bristol has been running with two dynamic sweeps per timesteps in the atmosphere to help with stability. I’ve done some tests, and it turns out that this significantly affects the mean climate, cooling the tropics and warming the poles. It’s not really clear yet why. If used with the re-tuned ice albedoes of xcpsb and later, this gives you a rather large warm bias over the Arctic, compared to xcpsb/xdbua. Used with the original ice albedo values though, two sweeps seems to bring surface temperatures closer to those in HadCM3, and also improves northern hemisphere seasonality.
I’m continuing tests with lower isopycnal diffusion in the ocean, along with free-drifting ice. These two seem to help the Southern Ocean warm bias and increase AABW. The grand plan now is to (manually) tune the sea-ice again using these, along with the snow_on_ice bugfix (see July), and 2 dynamic sweeps in the atmosphere for a hopefully even better FAMOUS.
yes, it’s another BUG WARNING. MOSES1 FAMOUSes, up to and including xcpsa and xdbub, appear to have their grid box mean surface sensible heat and moisture fluxes swapped for ocean and coastal points at the end of SFFLUX5A.F. Surface climate affects appear to be pretty small, patches of cooling of around a degree in the northern hemisphere in winter. I’ve a new version of the coastal tiling mod ctile_09_new_param, that will be included in future releases, but I’m not planning to backdate it. As for the ancil bug below (see November), this isn’t an issue in MOSES2.

Nov. ‘08

another BUG WARNING, although hopefully this won’t affect anybody at all. It seems that the ancil system in UM4.5 does not correctly update land ancils during a run. I’m guessing no-one is affected by this, as no-one’s complained about it yet - I’ve only found it from trying to do long transient paleo runs. The model doesn’t necessarily crash, but it’s pretty clear that things have gone wrong. This only affects MOSES1 - MOSES2 FAMOUS has this issue fixed. I have a mod for MOSES1 now - let me know if you’d like it.
many small things are being tested, probably none will make it into a release: wider Drake Passage, deeper Drake Passage, lower ocean isopycnal diffusivity, free-drifting ice…
Am pretty sure that the piston velocity thing below isn’t the main problem in the free CO2 crashes - it just causes the climate to segfault rather than run on, madly, for a few years. Can’t prove it, but a few things point to simple numerical instability in the tracer transport scheme which deals with the CO2 in the atmosphere. All seems OK in runs with better spun-up climates, so the caveat remains - don’t try to do spin-ups with free atmospheric CO2. Transients and the like may need smaller atmospheric timesteps to cope with this issue.
BUG WARNING: if your model is compiled with the self_shade.mod but HadOCC is turned off - this applies to release xcps[abc]. This mod deals with absoption of solar radiation at the top of the ocean, and we’ve found that it assumes that HadOCC is enabled. It’s not yet clear what the impact is of using the code with HadOCC off. There might also conceivably be implications for the stability of the model. My personal guess is that it’s not a big deal, but I’ll provide more information as we get it.
if anyone’s using any of the proto-MOSES2 jobs with TRIFFID off, they need an extra ancil to do seasonal leaf/canopy changes. This will be included in the soon-to-be-released MOSES2 testing job. Including the ancil doesn’t help the unpleasant temperature biases much though.

Sept. ‘08

brief note: you may have heard me complaining over the past 6+ months of a mysterious segfault problem with MOSES2.2+free CO2 runs, and, earlier, of free CO2 runs exploding with physically impossible levels of atmospheric CO2. I think I’ve sorted both of these issues now, both of which were traced to the calculation of the piston velocity for air-sea CO2 exchange operating outside its valid range while the warm MOSES2.2 climate spins up. I’ve put a couple of numerical caps into the formula, which shouldn’t affect “normal” runs at all. It’s probably not a good idea to attempt to spin up a completely new climate state with free atmospheric CO2 anyway, far too much potential for things to go wrong…
for reasons similar to the Schmidt bounds capping issue, I’ve put a cap of ± 30 moleC/m2/yr on instantaneous CO2 flux exchange between the ocean and atmosphere - there’s a carbon flux spike/heating/positive feedback/explosion problem that turns up when running with the free CO2 system sometimes. I’ve only seen it when running with the standard Wanninkhof piston velocity formulation whilst climate states are spinning up with MOSES2.2 - a short run with the Liss+Mervelat piston velocities didn’t show this (although possibly it wasn’t run for long enough), and neither has a long run using a well spun-up MOSES1 version of the model. The UMUI recommends the Wanninkhof form, and I didn’t want to change a parameterisation that seemed to work fine for most uses of the model, so I’ve put a cap on rather than switch to Liss+Mervelat. Seems to work, so far.

July ‘08

I appear to have neglected this page slightly - mostly a result of doing too many little things at once, none of which were quite worth writing up. So, new things with FAMOUS:
I’ve been spinning up the UTOPIA biogeochem MOSES1 FAMOUS, and have about 5000 years worth now. I’ve recalculated the iceberg flux for this run now and the salinity drift is now pretty small - there’s still drift in the ~2441 era dump runs as the climate settles down, even with the iceberg flux there.
this spun-up MOSES1 FAMOUS has been written up for the new EGU journal Geoscientific Model Development. You can read the draft, and make comments via the GMD discussion forum - please take a look.
given that the MOSES2.2 climate is still not great, I’ve worked up a version of MOSES1 FAMOUS which allows you to have interactive atmospheric CO2 via exchange with the ocean (land fluxes are 0 by default, or can be specified via the CO2 emissions ancil) - oddly enough, this isn’t allowed by the standard UMUI config. I’ve got about 1000 years of “free CO2″ MOSES1 FAMOUS that I haven’t looked at, but hasn’t crashed!
BUG WARNING a long-standing error in the UM4.5 coupling routines has been discovered and fixed. All versions of FAMOUS until now have had snow cover on land at coastal points overwritten by the snow depth on sea-ice every coupling step. It’s unclear what impact this has had - any salinity drift in the ocean has been corrected by the iceberg flux anyway. Fix mods wil be included in release downloads soon, or contact me for pre-release versions if you’re desperate. Thanks to Ron for bringing the issue to our attention.
impacts: fixing this has a larger impact than I expected. Global mean surface T comes down by half a degree or so, which is nearly all due to cooling along the coasts of Greenland and Antartica, with up to 2 degrees drop in zonal mean surface temp. north of 40N. Zonal surface temp deviations from Had CM 3 are still far more like XBYVA than ADTAN though. There’s a rather small increase in annual mean ice concentration. Quite a few of the coastal areas of Greenland and Antarctica look like they are successfully supporting significant snow amounts now, it’s not that the snow is just being lost at a slower rate. There’s an increase in freshwater input to the ocean amounting to an extra freshening rate of ~0.004 psu per century in this run, but this may be a short term result of having reset all the land snow to 50,000 kg/m^2 over ice and there being some extra melt as things come back into equilibrium.
FAMOUS workshop 2008. If you’re reading this, you almost certainly know about this already, but if not the workshop will happen on August 29th in Reading - let me know if you’d like to attend.
FAMOUS on QUEST is having more, subtle, reproduceability issues. Recompiling can sometimes change your results. Currently a mystery.

April ‘08

there’s a valnote up for the fully carbon-cycling FAMOUS at http://www.met.reading.ac.uk/~robin/valnote/MOSES2.2_Int/plots.html. It’s still too warm; someone, somewhere will probably have to do some tuning. Officially, time is up on the NCAS FAMOUS development work, so this is the “release” version of MOSES2.2 FAMOUS. Practically, work continues…I’ve started to put up some notes on the differences in climate between MOSES1 and MOSES2.2 versions on my Interactive CO2 page.

March ‘08

back to work after our first baby. UTOPIA fields are pretty much spun up now, as global CO2 fluxes are <<0.2GtC/yr and look much better than before. Development work will now concentrate on the differences produced going from MOSES1 to MOSES2.2. MOSES2.2 is a lot drier (which is probably a good thing, as MOSES1 was waterlogged) but a fair bit warmer (which is not such a good thing) - so currently the coupled carbon FAMOUS runs have quite a different surface climate to the Dec07 release.
a minor pitfall (sort of a BUG): although Dec07 FAMOUS includes Had OCC, there’s no coupling of CO2 values between ocean and atmosphere - if you don’t have a fully interactive carbon cycle (MOSES2.2, TRIFFID, 3d field in atmosphere etc), the atmospheric pCO2 seen by the ocean is set in the UMUI independently of that set for the atmosphere. The default, static values in the UMUI set both to be the same, which is fine as long as you don’t change one. If you specify a changing atmospheric pCO2 value (say, a 1% increase) in the UMUI, the ocean biogeochemistry will not see the increase in CO2. I have a mod that fixes this now, let me know if you need it.

January ‘08

The ocean CO2 flux fields in Dec07 FAMOUS don’t look too great - in general the fluxes are too large, with some large outgassing patches in the SO and N.Atlantic. A few thousand years of spinup and CO2 outgassing is still going on, although at less than 0.2GtC/yr, which is where the MetOffice decided to call their HadCM3LC runs “steady”. Ian Totterdell recommended the use of the flux-limited UTOPIA advection scheme for the biogeochem tracers, which is what they use in more recent versions of HadOCC, and I’ve finally got hold of some mods for this. I’ve made versions that seem to work with FAMOUS, and I’m trialling them now.
A number of people pointed out reproduceability and STASH issues on QUEST at the end of last year. We’ve been running various tests, and QUEST is definitely more of a problem than HPCx was. All the problems we’ve found so far can be alleviated by removing compiler optimisation on QUEST (just use -i8 -r8 -O0 -Kieee for compiler options), but this seriously slows the model down. More selective de-optimisation is under investigation by Annette et al. - I’ve left this one to the professionals!
UPDATE: Flux-limited UTOPIA advection of biogeochemical tracers really improves the CO2 flux fields and brings them back to something believable. It still needs spinning up quite a bit more though, so it’ll be a while before there’s a good ocean state to release. Also, Annette and Simon have been working on the bit-reproduceability issues on QUEST and other platforms, with a fair degree of success. There’s a mod, some compiler options and a new version of gcom that will be incorporated into the standard version soon - FAMOUS should now be bit reproduceable on QUEST across different processor configurations and across CRUN restarts.

December ‘07

Finally, the Summer Release is being released. It’s not perfect, but you’ve got to stop somewhere. See the FAMOUSStandardVersions pages. The documentation that I’ve put up for this (Dec07) is basically the same as the Summer07 stuff, but things that needed extensive handediting then have now been incorporated into the UMUI properly. I’m more than happy to answer queries and provide help, but it’s probably more transparent all round if questions get routed through the helpdesk, so they can be logged and tracked properly.

Nov ‘07

minor bugfix: diagnostics that require extrapolation from the surface to a certain height (e.g. winds at 10m, temp at 1.5m) occasionally blow up on coastal points. The proximate cause is that the drag coefficient, CD, slips a little too low in the new SFL_INT_SEA, and an EXP(1/f(CD)), often large anyway, explodes. I’ve fixed it by capping this calculation. I’m not sure whether there’s not an underlying, real problem here, rather than something that just upsets a couple of diagnostics. I don’t think there is, but am aware that really I’ve just fixed a symptom, not a cause.

October ‘07

Having been on a few trips and cleared up a few bugs, the “Summer 07 Release” of FAMOUS is now ready (see entry for August)! Release documention (science changes) can be found at the Summer 07 Release Page. Files will be available on PUMA somehow, sometime soon, via Annette, or email me.
MOSESII.2 finally runs! Assessment/tuning work will be logged in the new MOSES section below.
An iceberg calving field has been made by simply scaling the pattern derived for HadCM3 to match the FAMOUS water-loss - NB I didn’t repeat the process by which the HadCM3 field was derived using various regional components. This is included in the Summer ‘07 FAMOUS release. Whilst very small, salinity drift is still not zero, as the snow build up on land/ice is not constant - after 200 years running with the new iceberg field the original positive salinity drift has become a very small negative drift. In its present form the iceberg field is thus not suitable for really extended runs. It’s probably inappropriate for paleoruns anyway, seeing as it’s derived for modern conditions. To answer the questions in July below: snow on land is not reduced at any point, so this does “create” water in the system. And it’s not really desirable to have iceberg calving match the snow accumulation rate - iceberg calving is obvious dependent on the wider ice sheet growth/dynamics that we don’t have: having a constant rate is one thing, having a variable rate based on a (basically) arbitrary climate variable is just silly. It’s a quick fix that can be justified for a single, stable climate state - pretending we’ve got an iceberg model of any sort would be ingenuous.
A further small wrinkle has been added to the vflux_drift.mod included in the Summer ‘07 release: the HadOCC code as written includes tracer dilution effects from surface freshwater fluxes, but ignores any flux correction field applied - e.g. the iceberg calving field discussed above. This has been changed, so that freshwater correction fields also dilute Alkalinity and TCO2 tracers.
HadOCC includes dilution of surface tracers by freshwater fluxes, but ignores the freshwater flux adjustment field, if it exists. I’m not sure if this is deliberate or not, but it is inconsistent, especially when the adjustment is being used - as it is in FAMOUS - as a “real” flux of water due to iceberg calving. The version of vflux_drift.mod used in the Summer 07 release includes dilution of Alkalinity and TCO2 by surface freshwater flux adjustments too.
Spin-up runs for the Summer 07 release showed up an amusing little feature. The equations for gas exchange use the formula from Wanninkhof (1992) to compute the Schmidt number, whose square root is used in setting the piston velocity. This formula goes negative for SSTs over 41 degrees, at which point the piston velocity NaNs and the global TCO2 field does likewise after a few timesteps. The model appears to be able to cope with this just fine, and nothing else goes wrong - so if you happen not to look at TCO2 when checking your model climate nothing seems wrong. 41 degrees seems a lot for an SST, but odd spikes in the high 30s don’t seem that uncommon, especially with the small tropical warm bias from the new ozone. The problem area was off California, where FAMOUS amplifies other UM version’s warm bias, identified in other models as a serious lack of marine stratocumulus. Clearly, at least on one timestep, FAMOUS has managed to hit an SST>41 degrees. For the moment, a simple bound has been put on the Schmidt number to keep it above 0 (schmidt_bounds.mod)

September ‘07

Following a suggestion of Jonathan’s, I’ve run up a simple script to subdivide the climate up into the Koeppen zones, to give an indication of where errors might impact the vegetation most. Compared to both HadCM3, and observations (the plot below includes ERA data run through my script, which doesn’t match up perfectly with the published “observations” anyway) we’re looking pretty good, to my eyes at least.

Attach:Koeppen.gif Δ

August ‘07

Jonathan and I have decided to do a new release of FAMOUS, with all my current climate mods in, before we incorporate all the recoding Annette’s been doing for the MOSESII.2 version. In addition to the salinity drift cancellation mod (vflux_drift), this will have new sea-ice albedoes (improved Nhemisphere surface temps), modified - but still idealised - ozone (improved high altitude temps), less smooth orography (improved surface temps, jet stream EKE) and options for different orbital parameters and a verylong filename convention.

July ‘07

I’ve followed up Ken Caldeira’s suggestion of swapping the order of the filtering and convection subroutines in the ocean to improve stability. There is now a mod that compiles and runs - I don’t really have problems with crashes in the ocean, so I can’t tell whether it’s improved anything. If anyone’s got a problem they think this might help with, let me know so I can pass it on.
I’ve done a brief run with a less-smoothed 48×37 orography - the current, smoothed version was originally introduced into FAMOUS to try to remove some instabilities that used to exist. I’ve only run a few decades, but I have no instabilities and slightly improved surface temperature and eddy kinetic energy stats. from the rougher, occasionally higher surface.
Interestingly, tuning the gravity wave drag param doesn’t do very much. Ramping it up pretty high slightly improves the overestimation of the northern hemisphere midlatitude jet, maybe. Ozone though: my current best results, resulting in a tropopause without degrading the surface climate involve:
a) climatological ozone / 5. , shifted up/down relative to the tropopause in a mass conserving fashion, the tropopause disgnostic criteria having been relaxed
b) a close variant on the old 3 level parameterisation, where the top level of the model is always set to a concentration of 2e-6 ppmv, regardless of where the tropopause is. Tropopause diagnostic criteria are also relaxed for this.
These look almost identical, and not too bad in the tropics (slight warm bias below the tropopause, slightly cold above c.f HadCM3). Significant cold biases remain at higher latitudes, above ~300mb, but both do have a jolly good go at a temperature inversion, which is more than can be said for the old 3level results.
I’m going to go forward with fine-tuning these two versions of O3, and trying to find some justification for using what amount to pretty low column O3 amounts better than “otherwise we screw the longwave budget up worse than it already is”. Fine tuning involves combining it with the other cold-bias fixes - see that section for more details.

June ‘07

Wouldn’t you know it, a fairly catastrophic BUG has been found living in the above, “bug-fixed” mod. Don’t use vflux_drift.mod without HadOCC enabled. Now fixed - only use vflux_drift.mod_xcggb version.
The salinity drift code has been revised to STASH the correction in more helpful units for the post-diagnosing of tendencies. A number of small bugs have been found in the version currently in xbyvs, but they only affect accuracy by a % or so. The new version also applies the correction to the TCO2 and Alk fields to reduce spurious drift in those fields. This new version is in the xcggb release, which is now recommended instead of xbyvs. Make sure you’re using the vflux_drift.mod_xcggb version of the mod
I’m also working up a FAMOUS version of the “ice-calving” ancillary file used in HadCM3 to 0 the global water flux. This is (technically) a freshwater flux adjustment field whose global integral is the amount of water accumulating as snow on the land, which (scientifically) says that this accumulation must all return to the ocean as icebergs. I’m not sure whether the depth of snow on land is reduced again anywhere in this process. It’s also non-interactive - i.e. if the snow accumulation rate changes, the iceberg-water input doesn’t. The rest of the vflux mod does this calculation for us - maybe we could scale the iceberg calving to match? Do we want to?
have started looking ozone again. My current thinking, comparing FAMOUS and HadCM3 forced by the “same” O3 climatology is that the problem still lies in FAMOUS ending up with stratospheric O3 levels where there’s tropospheric water vapour. The thickness of the topmost level in FAMOUS means that, in the tropics where the tropopause is highest, there’s still some water vapour in the top layer, so even confining ozone to the topmost layer still results in the anomalous warming. I’m not exactly 100% convinced, but it’s my best idea right now - and it would explain why climatological O3 has never been used in FAMOUS (a tropopause-following mod should only really be necessary for global warming experiments where the tropopause is likely to move) and why none of my various O3 mods make very much difference - they all have to have significant O3 in the top layer at the end of the day. Am experimenting with an extra layer, or raising the top layer of the model, so I can keep stratopsheric O3 well out of troposphere and match the shortwave heating profiles in HadCM3 and FAMOUS better. - Nope, having removed some extraneous bugs, that doesn’t actually help. I can do various things in the stratosphere, but the troposphere response is remarkably similar in all cases. What does help everywhere, is just reducing climatological values. Using o3=(climatology/5.) gives a rather good-looking temperature profile, although o3 plots obviously now look too small, especially in the stratosphere. Interestingly, this puts o3 levels back to around the 3level o3 numbers. I think the problem with the 3level stuff may be mainly to do with the tropopause diagnostic not behaving appropriately for it, not the o3 concs. it specifies, which now look more appropriate for creating the right heating rates in FAMOUS.
I’ve also just been reminded of the influence of gravity wave drag on vertical temperature profiles - Manoj has pointed out that the tunable params in there are set for HadCM3 and may be too weak for the lower resolution FAMOUS. Looking at it, the “low level” boundary is almost certainly too high in std. FAMOUS. Maybe if I can tune this better, the vertical T gradient will improve, making the tropopause diagnostic work better and setting the O3 concentrations (in both 3-level and climatological regimes) better, and all will be well! Next week, I’ll work on the parameterisation of flying pigs, which is sadly lacking in FAMOUS.
A 100yr “spinup” suggests that deep N.Atlantic bathymetry, new ice thickness(H0)=0.25 and melting ice albedo(ALPHAM)=0.2 do produce significant, long term improvements (relative to HadCM3) to the surface temperature, radiation budgets and ice fraction, so that’s what I’m going to go with at the moment. The MOC spins up a little (~24Sv max), there’s not much in the way of AABW, and surface albedo north of 70N or so is now too low (it was far too high before), but the cold bias in zonal surface air temp. is pretty much removed. The 0 fraction ice line isn’t radically different in a lot of the N.Atlantic from before, but the fractions are down quite a bit. This is all just looking at annual average plots. A brief look at other times/regions suggests that there’s also a slight improvement in the southern hemisphere, and that the seasonal cycle isn’t much changed (it’s still too large), just shifted downwards in the mean. I’ll do some more checking up on this though.
a HadOCC restart with deep bathymetry is required to make the most of the cold bias fix. I’ve generated a deep version of CJ’s adbip - adbipo@dao41c1-DEEP. This has had the internal date reset to match that of the adtaa?@dao41c1 restart of standard FAMOUS.
Hooray for scientific communication. Somewhat after the fact, someone’s pointed out that the orbital functionality is already in the UM>5.2. For consistency, and because they wrote far more comprehensive explanations of what’s happening, I’ll backport that instead of using my homebrew version.
I’ve added some handedit scripts such that arbitrary fixed orbital parameters can be used - the next release should have these, and the verylong format, specifiable via the UM. The orbital stuff will now have 3 options - 1) fixed, user specified 2) calculated online (for ± 1 Myr via the 6.1 mod and 3) precalculated, read in from a table. This last will allow values ± 250 Myr (i.e. Laskar 2004, Astronomy and Astrophysics - prob only useful back to −65 Myr), for anyone who’s really picky about their orbital parameters.
The plan for specifying orbital forcing is now as follows. Please comment if you want something else and I’ll do that instead!
1) Fixed, modern defaults. Hardcoded into model, exact values for Julian2000 from UM6.1
2) Fixed, user specified year. Specify a year via the UMUI (and a calculation option, see below) and the model will calculate appropriate orbital params and stay fixed at those values for the course of the run
3) Varying, calculated online. Calculate orbital parameters based on the model year every new year, using the Berger78 method as implemented at UM6.1 (valid ± 1Myr BP)
4) Varying, using precalculated tables. Calculate orbital parameters based on the model year every new year, derived from precalculated tables i.e. Laskar04 (valid for whenever you can find values for. Laskar 04 claims some use up to −100Myr→20Myr)
Options 3) and 4) can additionally use an “acceleration” factor where the orbital forcing is speeded up. For example, with a factor of 10, 20kyr of orbital forcing would be applied over a 2000yr run
More testing of negative paleo-dates in FAMOUS currently implies that they’re fine in the model, but xconv/conv.sh based programs choke on them in postprocessing. ff2pp looks OK, so there is a way of getting pp files out, but currently not netCDF. Jeff is looking at this.

April ‘07

The salinity drift code has been revised to STASH the correction in more helpful units for the post-diagnosing of tendencies. A number of small bugs have been found in the version currently in xbyvs, but they only affect accuracy by a % or so. The new version also applies the correction to the TCO2 and Alk fields to reduce spurious drift in those fields.This new version is included in release xcggb, which is now recommended over xbyvs.
Previous work by Taro suggested that reducing ice albedo also killed off the MOC. Combining the deep bathymetry (with its initial MOC strengthening) and ideas about changing the ice albedo are proving fruitful however. Using the lower high albedo, as mentioned below, does start to reduce ice coverage with the deeper bathymetry. Standard albedoes, with a reduced “new ice” thickeness (0.5 → 0.25) doesn’t help much, but reduced thickness with a lower low ice albedo (0.5 → 0.2) produces much better looking ice coverage with a sensible strength MOC which reaches about as far north as Had CM 3’s does. AABW’s still not great though. Whilst more physically justifiable than lowering the high-end ice albedo (e.g. meltponds can really lower the albedo of melting ice; the new ice thickness seems to be a bit of a tuned guess anyway) these are pretty big changes - they do at least prove that this is a potential way forward though. I haven’t looked at the seasonal cycle, or the southern hemisphere yet either. Hopefully, an optimal tuned set of ice parameters will turn up in the next release that will give much better results.
Page last modified on March 09, 2012, at 10:02 AM by robin