Hi Julie Thanks for sending along this information. I have read the information on coupling and it seems that at least 3 hrs of observation/forecast data overlap is required in order for METRo to produce good forecasts in the first few hours. We are in fact attempting to provide 8 hours of overlap, but sometimes as I said in my original post this can result in the first timesteps in the forecast and observations files being the same. When this happens the model crashes.
Our workaround is to have 12 hours of historical forecast data, 8 hours of historical observed data, prior to the first desired forecast timestep in the output file. This way we get 8 hours of coupling (good for data quality), and no crashing of the model because the first forecast timestep and first obs timestep in the input data never line up. That's our workaround ; I'm just a bit surprised that no-one else has come across this issue at some point. Regards Iain -----Original Message----- From: Julie Prestopnik [mailto:[EMAIL PROTECTED] Sent: November 12, 2007 12:54 PM To: Iain Russell Cc: [email protected] Subject: Re: [Metro-developers] METRo crashes when obs and forecast start times are the same Hi Iain. I'll have to defer to the developers of METRo regarding your coupling question, because I don't know the details of how all of that works (I'm a software engineer). But, here is a link to an article on METRo that was published in the Journal of Applied Meteorology which may be able to answer your question: http://ams.allenpress.com/perlserv/?request=get-document&doi=10.1175%2F1 520-0450%282001%29040%3C2026%3AMANMFR%3E2.0.CO%3B2 In the example I gave, there was actually one hour of overlap: 2006-07-12T12:00Z. For most all of the cases I've run, I've given METRo only one hour of overlap in the observation and forecast data, and METRo has continued to produce reliable results. Also, looking at the Input observation QA/QC page on the wiki: http://documentation.wikia.com/wiki/Input_observation_QA/QC_%28METRo%29 it says under "Time constraints": "3. Let H, the first hour when METRo provided a road forecast. All observations after the H time are not be used." In my example, the first time for the input forecast data was 2006-07-12T12:00Z, which means that the first time for output roadcast data would be 20 minutes later at 2006-07-12T12:20Z. The text above indicates that any observations after this time would not be used; another indicator that you want to have observations prior to the first time in your input forecast file. I'm sorry I'm not able to provide more detailed/technical information. I hope this helps. Thanks, Julie Iain Russell wrote: > Hi Julie > > I will get some example input files for this situation when the model > crashes, but I won't have the output roadcast file because...er...well > the model crashes :) > > Regarding your comment that the input obs file end timestep should be > the same as the input forecast start timestep ; how does the coupling > stage of the model work in this case ... i.e. in the example you gave, > there's no overlap of obs and forecast and so there's no way for the > model to learn from the forecast biases. Maybe I'm missing something. > > Regards > Iain > > -----Original Message----- > From: Julie Prestopnik [mailto:[EMAIL PROTECTED] > Sent: November 12, 2007 12:19 PM > To: Iain Russell > Cc: [email protected] > Subject: Re: [Metro-developers] METRo crashes when obs and forecast > start times are the same > > Hi Iain. > > I'm not sure if I'm interpreting your message correctly or not. It > sounds like you want the input observation file and the input forecast > file to start at the same time. For example, having them both start at: > > 2006-07-12T00:00Z > > But instead, METRo wants to have the first input forecast time the same > as the last input observation time. So, for example, my observation > file would start at 2006-07-12T00:00Z and end at 2006-07-12T12:00Z. > And, my forecast file would start at 2006-07-12T12:00Z and end at > 2006-07-15T23:00Z. > > METRo wants to get the model going by using input observations to start > with and then use the forecast information following the observations to > help determine the roadcast. > > The issue that I reported back on April 6th, was a different situation. > We only had one hour of forecast data, but METRo requires at least two > hours of forecast data. > > I hope this has helped. Also, if you want help in reproducing > behaviour, it's always helpful to attach all of your I/O files > (observation file, atmospheric forecast file, station configuration > file, output roadcast file) and the command line that you're using. > That way we can test the exact problem that you're having without having > major differences. > > Let us know if you have any further questions or need any assistance. > > Thanks, > Julie > > Iain Russell wrote: >> Hi >> >> We have found that METRo crashes when both the input observation file >> and the input forecast file start at the same timestep. >> >> Operationally we are running version 2.1.1, but we also did a test > with >> the latest stable release and got the same result. In order to >> circumvent the problem we are capturing more historical forecast data >> than observation data so that our 2 input files never start at the > same >> time. >> >> A similar-looking issue was reported on April 6th 2007 by Julie >> Prestopnik ; but I'm unsure if the case that Julie reported and the > one >> I'm reporting here are related in any way. >> >> Can someone do a test to see if you can reproduce the behaviour I'm >> reporting here ; make the first timestep in the input observation file >> and the forecast file the same times. >> >> Thanks >> Iain >> >> >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> METRo-developers mailing list >> [email protected] >> https://mail.gna.org/listinfo/metro-developers > _______________________________________________ METRo-developers mailing list [email protected] https://mail.gna.org/listinfo/metro-developers
