I have to correct my previous message. filter_step_ahead and filtered_vars are two distinct things. See http://www.dynare.org/phpBB3/viewtopic.php?f=1 <http://www.dynare.org/phpBB3/viewtopic.php?f=1&p=12780&sid=b5eb85128d1c094f 0a84366c55c411e9#p12780> &p=12780&sid=b5eb85128d1c094f0a84366c55c411e9#p12780 for a discussion of the problem. Instead of saving in different fields, we actually rule out filter_step_ahead for Bayesian estimation and do not elaborate on this in the manual. Is there a particular reason for not allowing this? The code itself seems to work after Bayesian estimation. -- Johannes Pfeifer Haußerstr. 29 72076 Tübingen Tel.: +49-(0)7071-6396184 Mobil.: +49-(0)170-6936820 Germany Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Johannes Pfeifer Gesendet: Mittwoch, 25. September 2013 11:16 An: Dev@dynare.org Betreff: [DynareDev] filter_step_ahead Dear all, could it be that there is a mistake in the manual? It currently says: filter_step_ahead = [INTEGER1:INTEGER2] Triggers the computation k-step ahead filtered values. Stores results in oo_.FilteredVariablesKStepAhead and oo_.FilteredVariablesKStepAheadVariances. But this seems to be only true for “%% ML estimation, or posterior mode without metropolis-hastings or metropolis without bayesian smooth variable“ as the comment in dynare_estimation_1 before the call to DsgeSmoother says. Instead, for Bayesian estimation, the respective field seems to be oo_.filtered_variables. Best, Johannes -- Johannes Pfeifer Haußerstr. 29 72076 Tübingen Tel.: +49-(0)7071-6396184 Mobil.: +49-(0)170-6936820 Germany