It's the same mod-file, Approx_10.mod, just used in the two programs with order=3. As far as I understood, they rely on the same underlying routines.

--------
Johannes Pfeifer
Friesenwall 104
50672 Köln
Mobil: +49-(0)170-6936820
jpfeifer@gmx.de

-----Ursprüngliche Nachricht-----
Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard
Gesendet: Mittwoch, 12. August 2015 18:01
An: List for Dynare developers
Betreff: Re: [DynareDev] Dynare++ Memory

OK, but this is a problem different from the one encountered with Approx_10.mod

Johannes Pfeifer writes:

 Dynare++ always diagnoses 0 memory and k_order_pert.mexw64 in Dynare unstable always negative memory.

 -----Ursprüngliche Nachricht-----
 Von: Dev
[mailto:dev-bounces@dynare.org] Im Auftrag von Michel 
 Juillard
 Gesendet: Mittwoch, 12. August 2015 17:29
 An: List for Dynare developers
 Betreff: Re: [DynareDev] Dynare++ Memory

 Are you saying that under Windows, dynare++ always diagnoses negative memory?

 Johannes Pfeifer writes:

 Sébastien also indicated some time ago that this message "just" 
 triggers a different algorithm. But this is still a very undesirable 
 behavior. I get this exact same message in the jnl file that is 
 created when I use this mod-file with Dynare under Matlab at order 3 
 with the k_order_pert.mex64. In this case, at order=3 memory should 
 not be an issue. But the mex-file diagnoses negative memory and 
 immediately switches to the different algorithm from the start.

 --------

Johannes Pfeifer
 Friesenwall 104
 50672 Köln
 Mobil: +49-(0)170-6936820
 jpfeifer@gmx.de

 -----Ursprüngliche Nachricht-----
 Von: Dev [mailto:dev-bounces@dynare.org] Im Auftrag von Michel 
 Juillard
 Gesendet: Mittwoch, 12. August 2015 15:28
 An: List for Dynare developers
 Betreff: Re: [DynareDev] Dynare++ Memory

 Looking again the the journal, I believe now that the message "run 
 out of memory" is not an error message but an information that 
 triggers a change in the trade-off between speed and memory (i.e. 
 decreasing number of the
 threads)

 I don't think that dynare++ catches memory allocation failure and 
 just crashes at that point.

 Michel Juillard writes:

 Johannes,

 do you know for which order
this example is working on your machine 
 and for which order it doesn't?

 When it is working does the jnl make sense?

 It may be that 8GB is not enough to even store the derivatives of 
 the model before starting computations but that for some reason the 
 program doesn't crash until much later.

 Best

 Michel

 Johannes Pfeifer writes:

 Hi Michel,

 I ran dynare++ on the mentioned mod-file again under Windows++ and 
 used the system monitoring tools for monitoring memory usage. The 
 picture is attached. The blue line shows the percent of memory used 
 of my 8GB RAM on my Laptop from the start until the crash. As you 
 can see, there is not much movement. I do not get anywhere close to 
 the 8GB of memory used for the task that you report
for Linux.
 Rather, straight from the beginning the jnl-file reports 0 
 available memory and "out of memory". It simply seems as if
 Dynare++ is hardly using any memory straight from the start. This 
 Dynare++ does not
 seem to be just a problem of measuring memory usage on Windows.

 Best,

 Johannes

 ------

 Johannes Pfeifer

 Department of Economics

 University of Mannheim

 L7, 3-5, Room 242

 68131 Mannheim

 Germany

 +49 (0)621 181-3430

 Dev mailing list
 Dev@dynare.org
 https://www.dynare.org/cgi-bin/mailman/listinfo/dev

--
Michel Juillard

Dev mailing list
Dev@dynare.org
https://www.dynare.org/cgi-bin/mailman/listinfo/dev

Dev mailing list
Dev@dynare.org
https://www.dynare.org/cgi-bin/mailman/listinfo/dev