Hi Miguel, thanks for your response. Julie Prestopnik provided me with some additional details on this issue since she first noticed it a couple years ago.
Perhaps there is no absolute fix for this, but I want to be sure that something else is not happening either. As you said, if you increase the concrete depth, METRo is stable and produces a forecast. However, we are already using a value that is larger than the minimum mentioned in the bug report (0.25m). We are using 0.275m, and it still fails. This seems rather thick to me, and is surprising that it cannot resolve enough layers here. Second, if we leave the concrete at 0.275m, but reduce the depth of the overlaying asphalt layer, it also produces a forecast. If the issue is resolving enough layers in the concrete, how does reducing the asphalt thickness suddenly cause it to work? Thanks for you help, -jim Miguel Tremblay wrote: > > > Jim Cowie wrote: >> I'm not sure if this is the correct venue for this issue, but we are having >> a problem running METRO (3.2.1) on a few sites. The one thing the sites seem >> to have in common is a rather thick asphalt layers on top of concrete. When >> METRo runs, we get the following message: >> >> --------------------------------------------------- >> >> EXECUTION : METRO_MODEL module: start execution >> EXECUTION : Start sending data to METRo core >> DEBUT SETCONSTPHYS >> FIN SETCONSTPHYS >> GRILLE ROUTINE START >> Numerical stability test failed >> for grid level 22 >> Please increase the tickness of your >> layer, especially the cement if present >> STOP : Fatal error in METRo physical model. >> >> ---------------------------------------------------- >> >> We can make this message go away if we increase the concrete thickness or >> decrease the asphalt thickness. However, this is arbitrary and I would >> rather have some additional guidance on layer thicknesses. >> >> I do not see any guidelines in the METRo documentation on minimum or >> maximum number of layers or layer thickness. Is this information >> documented somewhere? >> >> I have attached the example XML files for this case. >> >> Thank you for your attention, >> >> jim >> >> > > Hi Jim, > > The problem with this configuration is numeric stability (as written in > the error message). > > Before throwing this error, METRo was producing NaN as outpout. See bug > 7737 on Gna! > https://gna.org/bugs/?7737 > > This was fixed in the METRo release 3.0.1 in December 2006. > > The problem is that if a layer with a good thermal conductivity is too > thin, METRo does not have enough layers in it to resolve the thermal > balance equation in one timestep. It is a well know problem in NWP, as > you might know, and it is called the CFL condition. See: > http://en.wikipedia.org/wiki/Courant%E2%80%93Friedrichs%E2%80%93Lewy_condition > > The workaround is to do like you did: increase the tickness of concrete. > Sorry, there is no other fix and, even if we would fix METRo to process > your specific case, there would still be configuration that would raise > this error. > > It is hard to give a guideline with real numbers to respect this > condition. It is why the error message is given at runtime. Depending on > the deepness of the layer (METRo as more layers at the surface), his > tickness and his type, the value will differ. > > I have added a note in the METRo documentation regarding this. It is here: > http://documentation.wikia.com/wiki/Input_station_%28METRo%29#Layer_description > > Does it answer your question? > > Best regards, > > Miguel > -- Jim Cowie NCAR/RAL [email protected] 303-497-2831 _______________________________________________ METRo-developers mailing list [email protected] https://mail.gna.org/listinfo/metro-developers
