Hi Bill,

If it is OK for others, I agree that we should use 00UTC.  But, I foresee potential problems with this approach.  For example, if you have a day that is very hot followed by a cooler day, you may end up counting the maximum temperature twice for the hot day depending on locally what time 00UTC is.  A similar scenario could be thought of for minimum temperature.  For this reason, I suggested the max/min of the SRF output interval, so that the user could decide at the postprocessing stage what time to use.  Anyway, if you think that these potential problems are negligible, we can use 00UTC.

Regarding the 2m temperature, do you think there is a need to rethink our approach for computing it in the presence of tall vegetation?  If so, do you have any suggestions?

A small clarification...  In the default version, I pretty sure that the midpoint of the lowest model level generally about 35 to 40 meters.

Thanks for the comments.  It is nice to see so much interaction for so many different RegCNETers!

Jeremy

Wm. J. Gutowski wrote:

Re: [RegCNET] tmax and tmin

Lara:

        I'm not sure that using the lowest ATM level is the best choice, although we do want an air temperature.  What most models that I know about typically do is use the near-surface air temperature that the land-surface model determines, perhaps in conjunction with the PBL model   This is the temperature that corresponds to what the observing stations are measuring.  The lowest ATM level may be many meters above the surface.  For example, RegCM's lowest layer's delta sigma = 0.05 implies a lowest-layer thickness of about 500 m, that the nominal middle of the layer is at about 250 m.

        There may be a further issue here though (and I need help from the ICTP people on this!):  is the near-surface air temperature computed in RegCM3 at 2 m?  I thought some observation stations used

other heights above the surface.

        Also, how well do we know that Tmin/Tmax stations adhere to WMO standards?  I know if the U.S. they don't, simply because of the disparate reset times used.  If that is the case elsewhere, then I suggest doing the reset at a default time of 00 UTC (so that the values are for the calendar day ending at that time).  This could be a parameter that the user can change in the input files, though that might cause confusion about what day to associate the values with.   (Arguably, that potential for confusion will always be there relative to the local clock.)

Bill

At 11:02 AM -0800 05.11.16, Lara Kueppers wrote:

Jeremy-
A couple of things:
* Mark and I were discussing that it would be best if Tmin and Tmax were calculated from air temperature (lowest ATM level) so that they are consistent with the average T values. If you output this in the SRF file, that's fine, just so it's clear we're talking atmospheric min and max.

* Also, calculating min and max from 00 to 00 UTC seems the most workable option. Unless there is some argument for having sub-daily min and max (as opposed to average) temperature, we'd say limit the file size!

One other thought... Would anyone else find it useful to have the combined surface albedo values available from BATS? (i.e. the total vis and ir albedos calculated from veg, soil, snow etc.) This would be helpful for interpreting seasonal cycle results from land cover change experiments. Of course this would increase the file size...

Lara

Jeremy Pal wrote:

Hi,
Having it done based on local time may be a bit tricky to code up.  As an alternative, we could consider storing the max/min temperature and wind for every output interval (e.g. 3 hours).  This way, the user can decide the reset time at the postproc stage... Of course, this increases the SRF output file size by about 15% as opposed to just a couple percent.
What do you think of this idea?
Jeremy

Tomá" Halenka wrote:

Dear All,

Not bad hearing Tmax and Tmin will be included properly in new edition
of RegCM. But I would recommend to use WMO definition and reset time,
moreover, keep in mind it has to be done in local time as my opinion.

Best regards,

Tomas

*************************************************
RNDr. Tomas Halenka, CSc.
Charles University in Prague,
Faculty of Mathematics and Physics,
Department of Meteorology and Environment Protection,
V Holesovickach 2, 180 00  Prague 8,
Prague, Czech Republic,
Phone: +420 2 21912514
Fax:     +420 2 21912533
E-mail: tomas.halenka@mff.cuni.cz
*************************************************

-----Original Message-----
From: regcnet-bounces@lists.ictp.it
[mailto:regcnet-bounces@lists.ictp.it] On Behalf Of BI XUNQIANG
Sent: Wednesday, November 16, 2005 9:48 AM
To: Wm. J. Gutowski
Cc: Gao Xuejie; regcnet@lists.ictp.it
Subject: Re: [RegCNET] tmax and tmin


Dear Bill, Lara, and Gao:

In the next public released RegCM3 version, we will add Tmax, Tmin
and vertital velocity (for pressure level) as the standard output.

We will calculated Tmax and Tmin as the way Bill suggested (for
every land surface step, and reset at 00 UTC).

Any other fields are also necessary to be included ?

Thanks and best regards,

On Tue, 15 Nov 2005, Wm. J. Gutowski wrote:

 

Dear Lara:
      I am not the expert on this, but I am pretty sure that observed
  

Tmin

and Tmax are obtained primarily from min/max thermometers, which
  

record the

highest and lowest temperature attained since the last time they were
  

reset.

They are almost always reset every 24 hours, though they don't all get
  

reset

at the same time.  That is, different stations, even in the same
  

country (or

in the US, the same state) may reset their thermometers at different
  

times of

the day.  This can induce a small bias in one station's climatological
  

 

averages compared to what it would get if it reset at another time.
  

This is

documented in the literature somewhere, though I don't have the
  

reference

myself.
Using the 3-hourly output will tend to reduce the diurnal
  

temperature

range you get because that is probably not sampling the extremes of
  

the day,

though I have not seen this reduction tabulated by anyone, and it
  

probably

depends on location and season.  Including a computation of the true
  

daily

min/max temperature would be just a few lines of code, and some of us RegCNETers have undoubtedly done it for their version of the code - we
  

really

should have it as part of the standard model, I think.  There would
  

still be

the question of what time of day to "reset the thermometer", but in
  

model

intercomparisons I've been part of, we typically agree to go from 00
  

UTC - 00

UTC.

Bill

At 11:32 AM -0800 05.11.14, Lara Kueppers wrote:
  

Hi-
Awhile back I asked how Tmin and Tmax in the SRF output file were calculated. Here is Nellie's recent reply, in case anyone else is interested.:

"Hi Lara,

I just verified this with Bi...Tmin and Tmax are calculated from the
    

BATS

output, so if you have the model output to the SRF file every 3
    

hours, then

that is what the min and max are calculated from.  Bi thinks this is
    

a

better way to do it since min and max temp observations are generally
    

taken

from 3 or 6 hourly obs.  You can increase the frequency of the srf
    

output

variables (in the regcm.in file) to see how much of difference it
    

would

make in the diurnal temp range. "

--
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Lara M. Kueppers, PhD
Postgraduate Researcher
Department of Earth Sciences
University of California, Santa Cruz
1156 High Street
Santa Cruz, CA  95064
USA

831.459.3504 ph
831.459.3074 fax
kueppers@pmc.ucsc.edu

_______________________________________________
RegCNET mailing list
RegCNET@lists.ictp.it
https://lists.ictp.it/mailman/listinfo/regcnet
    

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William J. Gutowski, Jr.
3021 Agronomy Hall
Dept. of Geological and
   Atmospheric Sciences
Iowa State University
Dept. of Agronomy
Ames, Iowa  50011-1010

gutowski@iastate.edu
Tel:1-515-294-5632
Fax:1-515-294-2619
http://www.ge-at.iastate.edu/
http://rcmlab.agron.iastate.edu/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
RegCNET mailing list
RegCNET@lists.ictp.it
https://lists.ictp.it/mailman/listinfo/regcnet

  

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~  Dr. Xunqiang Bi         email:bixq@ictp.it  ~ ~  Physics of Weather and Climate Group        ~
~  The Abdus Salam ICTP                        ~
~  Strada Costiera, 11                         ~
~  P.O. BOX 586, 34100 Trieste, ITALY          ~
~  Tel: +39-040-2240302  Fax: +39-040-2240449  ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
RegCNET mailing list
RegCNET@lists.ictp.it
https://lists.ictp.it/mailman/listinfo/regcnet


_______________________________________________
RegCNET mailing list
RegCNET@lists.ictp.it
https://lists.ictp.it/mailman/listinfo/regcnet
 

--
The Abdus Salam International Centre for Theoretical Physics
Strada Costiera 11; 34100 Trieste, ITALY
Phone: +39 040 2240579; Fax: +39 040 2240449
 
------------------------------------------------------------------------

_______________________________________________
RegCNET mailing list
RegCNET@lists.ictp.it
https://lists.ictp.it/mailman/listinfo/regcnet
 

--
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Lara M. Kueppers, PhD
Postgraduate Researcher
Department of Earth Sciences
University of California, Santa Cruz
1156 High Street
Santa Cruz, CA  95064
USA

831.459.3504 ph
831.459.3074 fax
kueppers@pmc.ucsc.edu

_______________________________________________
RegCNET mailing list
RegCNET@lists.ictp.it
https://lists.ictp.it/mailman/listinfo/regcnet

--
 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William J. Gutowski, Jr.
3021 Agronomy Hall
Dept. of Geological and
     Atmospheric Sciences
Iowa State University

Dept. of Agronomy
Ames, Iowa  50011-1010

gutowski@iastate.edu
Tel:1-515-294-5632
Fax:1-515-294-2619
http://www.ge-at.iastate.edu/

http://rcmlab.agron.iastate.edu/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
The Abdus Salam International Centre for Theoretical Physics
Strada Costiera 11; 34100 Trieste, ITALY

Phone: +39 040 2240579; Fax: +39 040 2240449

--