Sunday, December 4, 2011

0887057295.txt

From: Tom Wigley <wigley@meeker.ucar.edu>
To: Mike Hulme <m.hulme@uea.ac.uk>
Subject: Re: New MAGICC/SCENGEN
Date: Mon, 9 Feb 1998 15:48:15 -0700 (MST)
Reply-to: Tom Wigley <wigley@meeker.ucar.edu>
Cc: hm_pitcher@pnl.gov, o.brown@uea.ac.uk

Mike,

Thanks for the quick response. Responses to responses follows....

(1) I tried the composite GHG plus UIUC SUL on Norm's machine, in just
the way you said. However, the results for the USA seem to be identical
to those using *only* UIUC GHG input. I'll try again.

(2) You are right in saying one shouldn't scale GHG patterns by
GHG+SUL dTs. However, to be strictly consistent one should never allow
GHG patterns to be used alone. So you are *not* being consistent if you
allow this---which you do. The point then is to minimize the extent of
the inconsistency.

It is unarguably correct that the global-mean temperature to use
is the one containing all forcings (i.e., column 6 in *DRIVE.OUT). The
choice then is what pattern(s) to use. If we had no SUL information, we
would have to use GHG patterns; as in the original SCENGEN. Scaling these
with the MAGICC GHG output would give both incorrect patterns and
incorrect global-mean warming. Scaling with column 6 at least gets the
global-mean warming correct (within MAGICC uncertainties). You seem to
have chosen to get *both* things wrong, instead of just the patterns.

I can see some logic in your method; I just think (strongly) that
it is wrong. At the very least, it will be confusing to the user.
If the user selects only GHG model patterns, then won't they wonder why
the global-mean temperature is inconsistent with MAGICC? To take an
extreme case, suppose the full dT is 2degC and the GHG-alone dT is 3degC.
Is it better to scale an approximate pattern (i.e., the GHG pattern) by
2degC or 3degC? In my view, GHG scaled by 2degC would be much closer to
GHG+SUL scaled by 2degC than GHG scaled by 3degC. Surely the real issue
(given that it is impossible to be entirely consistent in this case) is to
get a result that is as close to the 'right' result as possible. I feel
quite sure that scaling by column 6 is best on this basis---especially
given that the patterns are much more uncertain than the global-means. I
think this is absolutely beyond doubt.

The bottom line here is that consistency is impossible if one uses
only GHG patterns. Column 6 was included deliberately, and after some
thought (along the lines noted above).

Of course, it is possible to get column 6 results by adding
columns 2, 3, 4 and 5 as they now stand (and as they are in the version
that you have). However, one cannot do this with the correct *raw*
column 3, 4, and 5 output because of the nonlinear direct forcing effect.
It just happens that, in your version, I 'faked up' column 5 as the
difference between column 6 and the sum of columns 2, 3 and 4. I did this
simply to get the code working; but (as you now know) I never got around
to fixing it up until now. In the latest version, column 6 is again equal
to the sum of columns 2, 3, 4 and 5 because I scale columns 3, 4 and 5 to
ensure that this is so.

(3) Re HadCM2, again it is impossible to be consistent. What I said
before is that the reason for adding these results is simply to make them
readily available. I do *not* advocate using them in combination with any
other model results. It is, I believe, perfectly reasonable to scale
these results with column 6 data. Of course, this 'hides' an assumption
about the relative magnitudes of the GHG and SUL components---i.e., it
assumes that the HadCM2 relative magnitudes are okay. The point of
scaling, however, is to account for other factors that change the
global-mean temperature relative to HadCM2 results, such as different
sensitivities.

I agree with you that it would not be an efficient use of time
splitting the HadCM2 SUL results into GHG and 'aerosol' component
patterns. The whole point of the sulphate part of SCENGEN is to look at
the influence of different SO2 emissions patterns. Splitting up HadCM2
wouldn't help here at all.

I also think it would be valueless to hardwire HadCM2 dT results
into SCENGEN---again, this would defeat the purpose of including these
results. It would introduce an additional inconsistency; since HadCM2
patterns change with time, it would not be logical to scale the 2071-2100
pattern with (e.g.) 2031-2060 dT. Of course, you could argue that it is
illogical to scale this pattern with (e.g.) 2031-60 dT from MAGICC; but
this is a different issue that I don't think is worth discussing at this
time.

(4) Thanks for explaining the UIUC 'other data' problem. I will ask
Michael whether he can provide full global fields for the other variables,
since it really would be valuable to include them. If he can give us
these data, could you add them to SCENGEN? (re this, see below)

(5) I appreciate your problems with Olga and Mike Salmon. As far as I
can see, incorporating the revised MAG.FOR code into MAGICC/SCENGEN
shouldn't be too difficult. I can, however, get hold of some money to pay
for some of Mike's time to do other work---perhaps $5000 or so. Can we
set something up? The contractual side would be easy---just a matter of
agreeing a brief statement of work, and having CRU send a bill. If this
is useful and possible, then can you check it out with Mike and Trevor?

Cheers,
Tom


On Mon, 9 Feb 1998, Mike Hulme wrote:

> Tom,
>
> Got your fax and email. Five responses:
>
> 1. UIUC SUL results *can* be combined with any GHG pattern (or
> combination). Simply click on the relevant GCMs in the GCMs menu. You can
> choose all 15 GHG patterns and also the UIUC SUL pattern simultaneously if
> you want. Not sure how you missed this one.
>
> 2. We do *not* allow GHG patterns to be scaled by GHG+SUL dTs from MAGICC
> (what you call 'global sulphate'); i.e., we never use column 6 in the
> *DRIVE files. We always follow the 'disaggregated sulphate' route by using
> columns 2, 3, 4 and 5. I still maintain it is not correct to scale GHG
> patterns by a global dT that results from GHG+SUL forcing. The way we have
> designed SCENGEN is so that the choice of what columns in *DRIVE to use is
> governed by what GCMs are selected in the GCMs menu. If only GHG patterns
> are chosen we use column 2. If only SUL patterns are chosen we use columns
> 3, 4 and 5 with the appropriate weightings applied (i.e., we have three
> UIUC SUL pattern files corresponding to the three SCENGEN regions,
> re-combined of course from Schlesinger's six original regions). If *both*
> GHG and SUL patterns are chosen then we combine the various patterns using
> columns 2, 3, 4 and 5. You will see that the global dT displayed in red on
> the main screen changes in keeping with these selections (i.e., GHG only,
> SUL only or GHG+SUL).
>
> If we allowed GHG patterns to be scaled by dTs from MAGICC that resulted
> from GHG and SUl forcing I believe that we break the consistency of our
> method. Column 6 is therefore redundant and serves only to check the
> summing of the other columns.
>
> 3. This parallels an earlier discussion about using HADCM2 SUL results in
> SCENGEN. Strictly, we should not use them since they are SO2 pattern
> specific. Allowing the user to scale HADCM2 SUL by a set of dTs resulting
> from *any* SO2 pattern is plainly wrong. A compromise would be to allow
> HADCM2 SUL to be scaled by the dT from the HADCM2 SUL simulation (i.e.,
> hard-wiring these dTs into SCENGEN and using only these if the user wants
> HADCM2 SUL). Of course, other GCM patterns should not then be added to
> this. There is another way of using HADCM2 SUL results more flexibly and
> that is by differencing HADCM2 GHG from HADCM2 SUL (2071-2100),
> standardising the result according to the dTs from the three SCENGEN
> regions and then treating these standardised HADCM2 SUL only patterns as
> independent aerosol patterns to be used in SCENGEN. This would be my
> approach but again requires more time and effort.
>
> 4. We only include T and P from UIUC for the very good reason that only T
> and P contain complete global fields (at least from the ftp site data).
> The other variables exist only for land areas. Since the UIUC grid is 4
> (lat) by 5 deg and SCENGEN is 5 by 5 we would need to regrid (and the
> longitudes are displaced by 0.5 a box as well which complicates matters).
> Regridding land only grids onto a different land only grid is non-trivial
> (possible, but would take some working at). For example, UIUC have no
> Iceland or Caribbean islands so what do we give to SCENGEN for these boxes?
> We have to tell SCENGEN something since we add other GCMs together.
> Faking up data here is very time-consuming. If UIUC have other fields
> apart from T and P for a full global grid but just not put them on the web
> site then fine, the problem is quite straightfoward. If not, then we have
> a messy problem on our hands.
>
> 5. Points about revised MAGICC code noted and we will have a look at the
> new code when it is here. Please also note that apart from Olga not being
> paid by me now, neither is Mike Salmon. Indeed, Mike's contract is rather
> uncertain again. But I hope I can pursuade him (and Trevor) to keep pace
> with MAGICC changes for all our sakes.
>
> Regards,
>
> Mike
>
> At 19:23 06/02/98 -0700, you wrote:
> >Dear Mike,
> >
> >Some rather urgent SCENGEN issues have arisen from my meeting with Norm
> >Rosenberg, Hugh Pitcher et al. at Battelle. While at Battelle, I had my
> >first chance to look at the new SCENGEN, since I have not had time to try
> >to get it working under NT. (I haven't had time to try your new batch
> >file yet.)
> >
> >The first thing is that you seem to have constrained things so that
> >Schlesinger's sulphate results can only be added to *his* ghg results.
> >This defeats the purpose of the method. The sulphate patterns,
> >appropriately scaled, can be added to *any* (or any combination) of ghg
> >(i.e., CO2 alone) results. I am at a loss to understand why you did this,
> >because it seems to me that the coding should be easier for the more
> >general case. The way it should work is this:
> >
> >First, the user selects the MAGICC output; low, mid, high or user climate
> >output. This determines which file to use to get the normalized pattern
> >weights, LODRIVE, MIDDRIVE, HIDRIVE OR USRDRIVE.
> >
> >The user must then select whether to use global sulphate or disaggregated
> >sulphate. This determines whether to use the last column only in *DRIVE
> >(labeled SUM) to weight the ghg (or composite ghg) pattern (global
> >sulphate case); or to use the second, third, fourth and fifth columns of
> >*DRIVE (labeled GHG, ESO21, ESO22, ESO23) to weight, respectively, the ghg
> >(or composite ghg), region-1 sulphate, region-2 sulphate and region-2
> >sulphate patterns---and then sum these weighted patterns.
> >
> >What you seem to be doing now is to only allow SCENGEN to use
> >Schlesinger's ghg pattern for weighting with the GHG column. It should be
> >trivial to fix this. The ghg (or composite ghg) pattern should be
> >calculated no matter whether the user selects the global or disaggregated
> >sulphate case. You may have switched this calculation off for the
> >disaggregated case---but you *shouldn't*. As I noted above, the coding
> >should be easier for the proper working of the model.
> >
> >You may recall that I said earlier that I think there is still a glitch in
> >the sulphate pattern weights. On looking at the *DRIVE outputs again I
> >still think this is a problem. Have a look yourself and see whether you
> >think the numbers look reasonable or not. Ill check this out further over
> >the weekend.
> >
> >The second thing that came up in the Battelle meeting was the fact that
> >the only data sets for Schlesinger's output seem to be temperature and
> >precipitation. Battelle wants to do some sulphate cases (driving crop and
> >hydrology models with SCENGEN output), and they need the other variables.
> >They are working to a tight deadline, so getting these data into SCENGEN
> >is much higher priority that plugging HadCM2 SUL into SCENGEN. This is
> >why I am going to spend some time (at last!) checking out the pattern
> >weights a.s.a.p. I hope you can help out with these things. The first
> >should be easy---but I realize the second could be both tedious and
> >somewhat time consuming. There is clearly a lot of scope for using
> >SCENGEN to define the pattern consequences of sulphate aerosol forcing;
> >both to look at the implications of different SO2 emissions scenarios and
> >to investigate uncertainties. We can't do this until I've fixed the
> >MAGICC end to get the weights working properly. It is something we could
> >spend some time on (i.e., writing something up for publication) when I'm
> >in CRU in the summer (and/or earlier).
> >
> >Thanks for your help on this. The people at Battelle are very impressed
> >by SCENGEN--as am I.
> >
> >Cheers,
> >Tom
> >
> >
> >
> > **********************************************************
> > *Tom M.L. Wigley *
> > *Senior Scientist *
> > *National Center for Atmospheric Research *
> > *P.O. Box 3000 *
> > *Boulder, CO 80307-3000 *
> > *USA *
> > *Phone: 303-497-2690 *
> > *Fax: 303-497-2699 *
> > *E-mail: wigley@ucar.edu *
> > **********************************************************
> >
> >
>


**********************************************************
*Tom M.L. Wigley *
*Senior Scientist *
*National Center for Atmospheric Research *
*P.O. Box 3000 *
*Boulder, CO 80307-3000 *
*USA *
*Phone: 303-497-2690 *
*Fax: 303-497-2699 *
*E-mail: wigley@ucar.edu *
**********************************************************


No comments:

Post a Comment