my laptop runs a 64bit Linux. By any chance, did anybody get the source code to compile or have a binary available?
I tried, for an hour or so, to change the makefiles to use icpc as the compiler and ifort as the linker and link dynamically against Intel MKL. However, after a while, the build stops with the last couple of lines of errors being reproduced below.
Thanks in advance for any suggestions.
Joachim
./korder_stoch.hweb(465): remark #981: operands are evaluated in unspecified order
bruno.calculate(Zstack (),f,*res);
^
detected during instantiation of “void KOrderStoch::performStep(int) [with t=0]” at line 210 of “./approximation.cweb”
./korder_stoch.hweb(516): remark #981: operands are evaluated in unspecified order
gs ().insert(new _Ttensor(ypart.nstat,ypart.nys(),*g_sym));
^
detected during instantiation of “void KOrderStoch::performStep(int) [with t=0]” at line 210 of “./approximation.cweb”
./korder_stoch.hweb(518): remark #981: operands are evaluated in unspecified order
Gstack ().multAndAdd(1,h (),*G_sym);
^
detected during instantiation of “void KOrderStoch::performStep(int) [with t=0]” at line 210 of “./approximation.cweb”
Ok, sorry for the lame self-reply, but it seems I got it to work using the GNU compilers and linking against Intel MKL version 10.0.1.014. The only essential change in the makefile is to set
where MKLPATH=/path/to/mkl/lib/em64t and INCLUDE=/path/to/mkl/include
Thus far, I ran the asset.mod as a test. I attach the output files as a .tar.gz–if anybody is interested in verifying the results on a supported platform, I would very much appreciate a short reply if the results coincide.
thanks for experimenting with dynare++, it is good to hear that it can be seamlessly compiled on 64bits.
Regarding to your first post:
The compiler erros you quote are not errors, just warnings. A compilation of approximation.o failed for some other reason, possibly some language problem? I do not have icpc.
Regarding to your second post:
I ran dynare++ version 1.3.5 and calculated relative errors of derivatives in two norms: these are the numbers from order=1 through order=6:
ans =
4.259961177295135e-16
ans =
5.687164796943692e-16
ans =
5.649407074428512e-16
ans =
1.122312736307596e-15
ans =
1.346587314633392e-15
ans =
3.347290070072144e-15
This means the solutions are very very close. Differences are probably caused by a different code for atlas and lapack.
The whole tree does build on Ubuntu Hardy 8.04 on amd64, but it does not link at the end:
dynare_model.o: In function `ogdyn::DynareParser::parse_glob(int, char const*)':
dynare_model.cpp:(.text+0x325): undefined reference to `dynglob__scan_buffer(char*, unsigned int)'
../parser/cc/parser.a(atom_assignings.o): In function `ogp::AtomAssignings::parse(int, char const*)':
atom_assignings.cpp:(.text+0x1a9): undefined reference to `asgn__scan_buffer(char*, unsigned int)'
../parser/cc/parser.a(formula_parser.o): In function `ogp::FormulaParser::parse(int, char const*)':
formula_parser.cpp:(.text+0x719): undefined reference to `fmla__scan_buffer(char*, unsigned int)'
../parser/cc/parser.a(matrix_parser.o): In function `ogp::MatrixParser::parse(int, char const*)':
matrix_parser.cpp:(.text+0x150): undefined reference to `matrix__scan_buffer(char*, unsigned int)'
collect2: ld returned 1 exit status
flex is creating the .cc files with those symbols which are found in parser.a, but the linker isn’t finding them. The flex output is identical to that from a 32-bit Hardy machine.
dynare++-1.3.5/src$ nm ../parser/cc/parser.a | grep 'T .*__scan_buffer'
0000000000000620 T _Z17fmla__scan_bufferPcm
0000000000000610 T _Z19matrix__scan_bufferPcm
0000000000000610 T _Z17asgn__scan_bufferPcm
0000000000000610 T _Z21namelist__scan_bufferPcm
0000000000000610 T _Z16csv__scan_bufferPcm
[quote=“Ryan”]The whole tree does build on Ubuntu Hardy 8.04 on amd64, but it does not link at the end:
dynare_model.o: In function `ogdyn::DynareParser::parse_glob(int, char const*)':
dynare_model.cpp:(.text+0x325): undefined reference to `dynglob__scan_buffer(char*, unsigned int)'
../parser/cc/parser.a(atom_assignings.o): In function `ogp::AtomAssignings::parse(int, char const*)':
atom_assignings.cpp:(.text+0x1a9): undefined reference to `asgn__scan_buffer(char*, unsigned int)'
../parser/cc/parser.a(formula_parser.o): In function `ogp::FormulaParser::parse(int, char const*)':
formula_parser.cpp:(.text+0x719): undefined reference to `fmla__scan_buffer(char*, unsigned int)'
../parser/cc/parser.a(matrix_parser.o): In function `ogp::MatrixParser::parse(int, char const*)':
matrix_parser.cpp:(.text+0x150): undefined reference to `matrix__scan_buffer(char*, unsigned int)'
collect2: ld returned 1 exit status[/quote]
The problem was in the function declarations of *__scan_buffer. After changing “unsigned int” to “size_t” for each of the four functions, it compiled on x86_64. This matches what is in the flex output.
I will fix the declaration of *__scan_buffer in the svn. It seems that your flex generates the the functions with int 64 and thus unsigned int is not compatible with that (on 64 machine unsigned int is still 32).