Hi Iain,

Please give us the input files you used as well as the command line and 
the error message. I will look at it and answer your question.

Thank you Julie for the answer regarding Iain's questions.


Miguel

Iain Russell wrote:
> 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
>   


_______________________________________________
METRo-developers mailing list
[email protected]
https://mail.gna.org/listinfo/metro-developers

Reply via email to