It applies the approximated policy function to a set of particles, using
Dynare++ routines.
There is support for parallelization, using Dynare++ multithreading
model (itself based on C++11 threads; we don’t use OpenMP because it is
incompatible with MKL). For the time being, default to a single thread. This
should be later refined through empirical testing.
The changes in 8065e9d439 were not working as
intended, because AC_CHECK_PROG expect values and not actions. Hence
AC_MSG_ERROR was not properly executed.
By the way, simplify some test conditions using && instead of if/then/fi
blocks.
In particular, if either MATLAB or Octave is missing, one needs to pass either
--disable-matlab or --disable-octave.
Moreover, several new configure flags have been introduced for disabling some
components:
--disable-doc
--disable-dynare++
--disable-mex-dynare++
--disable-mex-ms-sbvar
--disable-mex-kalman-steady-state
The MEX files are built out-of-tree (because we want to do them in parallel).
This would create a potential race condition if several builds want to create
the symlinks under mex/matlab/ or mex/octave/.
The solution is to disable those symlinks for out-of-tree builds.
The scripts are based the former “dynare-build” project. They have been
overhauled and simplified.
Building a Windows package (both installer and zip archive) is as easy as
running “make -C windows” (provided the right Debian packages are installed,
use the “windows/install-packages.sh” script for that purpose).
The layout of MEX files for Octave in the package has been
changed (mex/octave/win32/ and mex/octave/win64/ instead of mex/octave32/ and
mex/octave/), for consistency with MATLAB MEX.
It constructs the stacked residuals and jacobian of the perfect foresight
problem.
It is an almost perfect replacement for the perfect_foresight_problem.m
routine, while being much more efficient.
Note however that the DLL never return complex numbers (it instead puts NaNs at
the place where there would have been complex). This may create problems for
some MOD files; the algorithms will need to be adapted to use a more
line-search method.
On Windows, this means that a POSIX threads implementation is no longer needed,
since C++11 threads are implemented using native Windows threads.
On GNU/Linux and macOS, POSIX threads are still used under the hood.
A new m4 macro (AX_CXX11_THREAD) is used to add the proper compilation
flags (instead of AX_PTHREAD).
- Use the -static flag when linking Dynare++, so that shipping libquadmath and
libgcc DLL in the installer is no longer needed.
- Use AM_CXXFLAGS and AM_LDFLAGS variables for changing flags, since CXXFLAGS
and LDFLAGS are user variables. Also, this avoids passing these flags down to
configure scripts in subdirectories.
- Check for the SZIP library in the configure test for the MatIO, this is
needed under MSYS2.
- Statically link MatIO and GSL in MEX files for MATLAB, this is needed under
MSYS2.
With automake 1.14 there are a lot of new warnings related to the way we deal
with MEX files (they are compiled from source files located in a different
tree). Automake wants us to use the 'subdir-objects' option, but it breaks in
our case.
In automake 2.0, the 'subdir-objects' option will be activated by default, so
we will have to refactor the build system for MEX files. But for now we can
live with the automake warnings.
This reverts commit 7541bb52f5.
This commit was breaking compilation of MEX files: the subdir-objects option
does not deal well with source files that are under a distinct tree.
Sébastien Villemot
Houtan Bastani
Stéphane Adjemian (Charybdis)
Houtan Bastani