### LAT-LON, ADAPTIVE TIME STEPPING AND FFT_FILTER_LAT

Posted:

**Mon Sep 17, 2012 5:41 am**Hello,

If I understand well, lat-lon grids are tagged under projection 'PROJ_CASSINI' by WPS and WRF.

If am wrong on that point, forget the following lines ...

For this projection, the fft_filter_lat parameter represents the latitude above which the polar filter is turned on.

Default value of fft_filter_lat is set to 91 in Registry (instead of 45 according to run/README.namelist).

This was probably chosen to completely deactivate filtering by default.

However, when adaptive time stepping is activated, it appears that fft_filter_lat is also used to lower the CFL condition at high latitude. The Courant numbers are computed as if the minimum grid spacing was the one at a latitude of fft_filter_lat. (dx * cos(latitude) is replaced by dx * cos(fft_filter_lat))

-> Obviously the default value of 91 leads to erroneous results (negative results).

In our case, we fixed this problem by specifying in the namelist a value of 89 for fft_filter_lat, but it is not going to work for all cases.

Maybe a simple solution would be to add to the WRF namelist a logical which clearly indicates if filtering is required or not.

best regards,

Laurent

If I understand well, lat-lon grids are tagged under projection 'PROJ_CASSINI' by WPS and WRF.

If am wrong on that point, forget the following lines ...

For this projection, the fft_filter_lat parameter represents the latitude above which the polar filter is turned on.

Default value of fft_filter_lat is set to 91 in Registry (instead of 45 according to run/README.namelist).

This was probably chosen to completely deactivate filtering by default.

However, when adaptive time stepping is activated, it appears that fft_filter_lat is also used to lower the CFL condition at high latitude. The Courant numbers are computed as if the minimum grid spacing was the one at a latitude of fft_filter_lat. (dx * cos(latitude) is replaced by dx * cos(fft_filter_lat))

-> Obviously the default value of 91 leads to erroneous results (negative results).

In our case, we fixed this problem by specifying in the namelist a value of 89 for fft_filter_lat, but it is not going to work for all cases.

Maybe a simple solution would be to add to the WRF namelist a logical which clearly indicates if filtering is required or not.

best regards,

Laurent