Hi Miguel,
Thanks for the reply. I would like to understand the initialization process a bit better. In the following example, let's assume a METRo roadcast forecast is generated at 00 Zulu and produces the following forecast temperatures valid for 00 through 06 Zulu: 20C, 18C, 16C, 14C, 12C. Does the 01 Zulu run of METRo use the 20C or 18C value as an "observation"? I completely agree that observations are crucial to produce the best forecast possible. As is frequently the case in an operational setting, RWIS observations are occasionally not available due to various issues (construction, maintenance, etc.) and will then not be available as input to a pavement forecast. In these cases, it is assumed that the main driver of any changes to a pavement forecast has to be any atmospheric forecast changes that may occur. The crux of the issue is a pavement forecast that varies, sometimes greatly (20F) from run-to-run, despite a lack of observational or atmospheric forecast reason do to so. Jeremy Duensing Transportation Product Manager Work: 952.882.4554 Cell: 651.276.2802 Fax: 952.882.4500 [email protected] www.telvent.com/environment From: Miguel Tremblay [mailto:[email protected]] Sent: Monday, September 13, 2010 12:36 PM To: Jeremy Duensing; [email protected] Subject: Re: [Metro-developers] METRo run-to-run consistency for locationslacking observations I assume this may be caused by the METRo model using the previous hours' forecast as the observation and continuing from there, almost like a self-feeding problem. It causes forecast generated in the evening to get progressively colder as new model runs come out and forecasts generated in the morning to get progressively warmer as new model runs come out. Any ideas on how to resolve this? Hi Jeremy, Like you said, the problem arise from the fact that the roadcast is forced to match the first observation at first hour of roadcast. The later in the night you initiate the forecast, the colder it will start. This is what you observed in the provided graph, each line is below the previous one. I understand that you aim to improve the consistency between 2 roadcasts initiated at different time. (By the way, for our non-US friends, the 20 degrees difference in question where Fahrenheit, not Celsius). If you want to achieve a better consistency, you could simply use the output of the previous forecast (say the orange line) to initialize the next one (the green line) instead of the same old road forecast for all of them. This would most probably give more consistency but, since there is no more information added into the system, the road forecast would probably not be more accurate. In any case, I think that starting METRo with no observations cannot give a good accuracy in the first forecast hours, especially during the night. The accumulated energy into the soil is too important in the energy balance to simply guess it at start and hope to have consistent result. However, after a full daylight of roadcast, METRo is probably more accurate and consistent with the road surface temperature since it has taken in account the total energy that went into the soil. You can see this in your graph: the roadcast of day 2 are more consistent one with another. Maybe you can try, when there is no observations, to use day 2 for the roadcast, not the day 1. The atmospheric forecast won't be as good as day 1, but you will gain in term of consistency between the roadcasts, and the uncertainty will be averaged in part during day 1. What do you thing of this suggestion? Miguel -- Miguel Tremblay Coordonnateur national des services commerciaux de données- National coordinator, commercial data services Centre météorologique canadien - Canadian meteorological centre (CMC) Environnement Canada - Environment Canada http://www.ec.gc.ca/ 2121 Trans-Canada N. Suite 201 Téléphone/Phone: 514-421-4729 Dorval, Québec Fax: 514-421-4679 CANADA H9P 1J3 courriel/email: [email protected]
_______________________________________________ METRo-developers mailing list [email protected] https://mail.gna.org/listinfo/metro-developers
