The MATLAB_CFLAGS variable was not injected when testing for the presence of
libslicot64_pic. In particular, on GNU/Linux system, this means that the -fPIC
flag was not injected when doing the test. This was not a problem on Debian,
where GCC now enables -fPIC by default. But this would fail on RHEL, where
-fPIC is not enabled by default.
By the way:
— rename ac_save_* variables to my_save_*, to avoid conflicts with internal
autoconf variables;
— do not inject “$(mkoctfile -p LFLAGS)” into LDFLAGS when testing for SLICOT
under Octave; this is no longer necessary, since those flags are already
injected at the beginning of mex/build/octave/configure.ac.
Partially addresses issue #1680:
- unconditional welfare resorts to dynare++ simulation tools, which shall be updated very soon
TO DO:
- implement a function computing kth-order approximation of simulated moments of y
This can make a difference when the return value of those function is directly
passed to a BLAS/LAPACK function.
On the other hand, if the return value is first stored in a pointer variable,
then it seems necessary to explicitly say that this pointer is also contiguous.
— allow the user to override compilation flags for MATLAB MEX (it was already
working for the preprocessor, the MEX for Octave and Dynare++)
— increase the symmetry of MEX build infrastructure between MATLAB and Octave
— when linking MEX for Octave, do not add the output of “mkoctfile -p FLIBS”.
It is unneeded, and it can create a conflict between the system compiler and
a user-supplied compiler
By the way:
— restore optimization on macOS for C/C++ MEX (it had been removed in
5df2392a09)
— remove -fno-omit-frame-pointer on MATLAB/Linux, since it would be cancelled
by subsequent -O2 and should not be needed anyways
— remove FFLAGS under Octave, unused
The current Octave support is utterly broken (both in stable and unstable), it
crashes Octave. It relies on an unofficial Octave app for
macOS (https://octave-app.org), which is infrequently updated.
This commits drop support for Octave in the macOS package. We will now tell our
macOS+octave users to use the Homebrew Dynare package (which is maintained by
the Homebrew team, and is in reasonably good shape).
In its output, the MEX was returning values for all endogenous variables, but
it was used in a context where only the variables from oo_.dr.restrict_var_list
were expected (as is done with local_state_space_iteration_2 MEX).
This commit fixes this discrepancy, and also fixes the test that was checking
that both MEX are returning the same output.
Closes: #1768
Incidently, remove the possibility of passing model derivatives as arguments to
the k_order_perturbation. That possibility was only used by the risky steady
state code.
Closes: #1338
— FCFLAGS needs to contain the compilation flags used when compiling Octave,
otherwise it fails at configure stage when looking for gfortran
— Explicitly add -L$OCTLIBDIR, because with Octave 5 it is no longer there, and
on Fedora the Octave libraries are no in the default linker search path
After simulating a block containing purely forward variables (thus of type
“evaluate backward”), the it_ variable of the evaluator would be left in an
inconsistent state (typically 0, which means that taking the value of a lagged
variable would lead to an invalid read).
By the way, fix a symmetric problem for backward blocks (which could
potentially create a invalid read for purely backward models).
Ref. #1727
- block trust region solver now available under solve_algo=13
It is essentially the same as solve_algo=4, except that Jacobian by finite
difference is not handled. A test file is added for that case
- block trust region solver with shortcut for equations that can be evaluated
is now available under solve_algo=14 (in replacement of the pure-MATLAB solver)
Closes: Enterprise/dynare#3
— add interface for more functions (cell, logical, struct)
— add new mexPrintf wrapper that trims and prints a newline
— functions that take indices of type mwIndex now 1-based indices
— improve the wrapper for mxArrayToString so that it returns a character scalar
In particular, higher order derivatives are now returned as sparse matrices by
the static/dynamic files, instead of 3-column matrices (which was inconsistent
with the M-file mode).
In Octave, when some values given to the sparse() function are numerically
zero, then the nzmax of the generated sparse matrix is shrinked accordingly;
while under MATLAB, the nzmax is the length of the vector of values, zeros
included.
The check at the top of
DynamicModelMFile::unpackSparseMatrixAndCopyIntoTwoDMatData() would then fail
under Octave if some higher-derivatives had an element which is symbolically
non-zero but numerically zero.
We therefore relax the check, and accordingly adapt the code that handles
numerical zeros.
This bug was uncovered by tests/pruning/AnSchorfheide_pruned_state_space.mod,
which was failing under Octave.
Because at some point throwing exceptions from MEX files (with mexErrMsgTxt())
was not working under Windows 64-bit, we had designed a workaround to avoid
using exceptions.
Most MEX files were returning an error code as their first (or sometimes last)
argument, and that code would have to be checked from the MATLAB code.
Since this workaround is no longer needed, this commit removes it. As a
consequence, the interface of many MEX files is modified.
For some background, see https://www.dynare.org/pipermail/dev/2010-September/000895.html
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.
This MEX solves nonlinear systems of equations using a trust region algorithm.
The problem is subdivided in smaller problems by doing a block
triangularisation of the Jacobian at the guess value, using the
Dulmage-Mendelsohn algorithm.
The interface of the MEX is simply:
[x, info] = block_trust_region(f, guess_value);
Where f is either a function handle or a string designating a function.
f must take one argument (the evaluation point), and return either one or two
arguments (the residuals and, optionally, the Jacobian).
On success, info=0; on failure, info=1.
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.
The logic of the dynSparseMatrix::Sparse_substract_SA_SB() routine was
incorrect.
In some cases, it would read past the last nonzero elements of the A matrix,
and consequently write past the number of allocated nonzero elements of the C
matrix.
This would lead to crashes and, probably, to wrong results under certain
circumstances.
Closes: #1652
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.
Various modernizations and simplifications.
Also remove a workaround for a LAPACK bug in DGGES (the VSL argument was
apparently referenced even though JOBVSL="N"). Hopefully the bug has been fixed
everywhere now.
Previously there were GeneralMatrix::numRows() and TwoDMatrix::nrows() for doing
the same thing (and same for columns and Const versions).
Merge these two into GeneralMatrix::nrows().
Sébastien Villemot
Stéphane Adjemian (Ryûk)
Johannes Pfeifer
Normann Rion
Houtan Bastani