NK_CGG02AL not working (edit: NOT CGG99AL!) #86

gboehl · 2019-12-03T18:07:51Z

Describe the bug
~~NK_CGG99AL~~ NK_CGG02AL gives problem with Cholesky decomposition. See #82 (comment) and #82 (comment) for details.

@AlexDece as far as I understand, oo_.dr.jacobia is created by the AL routines. Apparently it fails somewhere on the way.

@millazar @btatar13 does either of you have a deeper understanding of these routines? If nobody knows how to fix it I would just remove the model for now, as it appears that it was never working (hence not our responsibility).

The text was updated successfully, but these errors were encountered:

JTWendelborn · 2019-12-03T19:40:09Z

To add to the confusion: it works for me (at least in the developer version) with both, Matlab 2019a and Octave 5.1 and Dynare 4.5.7...I used the default gain parameter setting of 0.01 and all states selected and tried all available rules with a MP shock.

j2L4e · 2019-12-04T09:42:17Z

We've encountered this before. (From conversation with fstrobel, sorry for citing the german text)

Jan
ich krieg die mmb 2.3 auch nicht ans laufen ('Reference to non-existent field 'jacobia'.')

Felix
Jau, das leigt an einem name-conflict. In der MMB 2.3-Version gibt es im Ordner ALTOOL ein paar für die Zwecke der AL-Simulationen modifizierte Standard-files von Dynare, die aber damals aus unerfindlichen Gründen nicht umbenannt wurden, so dass sie den gleichen Namen tragen, wie die nicht modifizierten Funktionen. Ehrlich gesagt, weiss ich nicht, warum das früher nicht zu Konflikten geführt hat. Ich schätze dieser name-conflict kommt nur bei Octave zu tragen. In der 3.0 Version habe ich die entsprechenden Files umbenannt (Suffix "_MMB") und die AL-Simulationen laufen wieder

AlexDece · 2019-12-04T11:29:11Z

This is what I encountered until now.

The model also works fine for me (in dev version, but also in the version for testing, using ctave 4.4.1, dynare 4.5.7, windows 10).

When I was looking into the code of MMB 2.3 I find the same ting Felix says.
So I focused on MB 3.1

Stoch_simul_MMB.m calls resol_MMB.m
resol_MMB calls dr_block.m (which I didnt find, but there exists dr1_AL.m)
or stochastic_solvers_MMB.m

stochastic_solvers_MMB.m has its main function called stochastic_solvers()
However, this shouldnt be a problem, since matlab takes the file name as function name and the file name is used when calling the function.

In line 227 of stochastic_solvers_MMB.m, it says
dr.jacobia=jacobia_; (remember)

stoch_simul_MMB.m calls TRFromBeta.m
In line 15 it says
jacobia = oo_.dr.jacobia;
But this does not exist (according to MMB 2.3, where 'Reference to non-existent field 'jacobia'.)

Is it possible that this problem can be solved by adding
oo_.dr.jacobia=dr.jacobia;
after line 227 in stochastic_solvers_MMB.m? But then, this problem should occur for every AL model, where options are specified such that stochastic_solvers_MM.m is called in resol_MMB.m.

It is very strange, since the model, like other AL models, is running through and delivers IRFs...

gboehl · 2019-12-04T16:23:19Z

Thanks for looking into that Alex. I also don't get it.

If it would be a naming issue ("ALTOOL" vs "ALTOOL_MMB") the problem would be with all models.

I renamed file references and folder anyways, the problem is then:

chol: input matrix must be positive definite
sim_AL_alt_gain.m, function 'sim_AL_alt_gain', line 40

stoch_simul_MMB.m, function 'stoch_simul_MMB', line 184

run_dynare_and_simulate.m, function 'run_dynare_and_simulate', line 15

run_model_with_rules.m, function 'run_model_with_rules', line 29

mmb.m, function 'mmb', line 35

Explicitely in sim_AL_alt_gain.m:

 Q = M_.Sigma_e + 1.e-14;
RQ = R * chol(Q);

Then its a problem with this Q object.
So I did not look at Q to see how ill conditioned it is, and I don't know what this M_.Sigma_e object is, but this looks much like a problem with the model now. Weird thing remains that it works for Jonas. As he is using the same version of Octave, the Cholesky decomposition should be the same.

I would just remove the model for now, as we don't have the time to have a closer look.

@AlexDece if you want to, you can have one last look at it. Otherwise I'd just put it in an alternative models_nonfunctional folder within mmci-cli.

gboehl · 2019-12-04T16:51:47Z

@JTWendelborn @AlexDece one quick thing to check is how this M_.Sigma_e looks for each of you. If its different it would be interesting to know why. If not, then 😠

Does Q look different for Matlab and Octave?

@JTWendelborn does the compatibility test run trough for you with Octave?

JTWendelborn · 2019-12-04T17:04:19Z

My M_.Sigma_e looks as follows and is the same for Matlab and Octave:

j2L4e · 2019-12-04T17:04:58Z

@JTWendelborn You can run the tests from the command line via

test('test/config.test.json', 'test/config.test-al.json');

after changing the dynare path in those test files.

JTWendelborn · 2019-12-04T17:13:14Z

Running this command from the command line strangely gives me a syntax error:
-bash: syntax error near unexpected token 'test/config.test.json'.
However, when I run the compatibility test (Octave 5.1, Dynare 4.5.7) from the developer GUI, it reports that one of the tests has failed.

AlexDece · 2019-12-04T18:23:28Z

My M_.Sigma_e looks like what Jonas sent above. Am Mi., 4. Dez. 2019 um 18:13 Uhr schrieb JTWendelborn < [email protected]>:

…

Running this command from the command line strangely gives me a syntax error. However, when I run the compatibility test (Octave 5.1, Dynare 4.5.7) from the developer GUI, it reports that one of the tests has failed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#86?email_source=notifications&email_token=ANVSGFLIOZGIWKUZ3OROW6LQW7QKXA5CNFSM4JU4I672YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5YB3Y#issuecomment-561742063>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANVSGFOTZVTOQLREQ3MN733QW7QKXANCNFSM4JU4I67Q> .

gboehl · 2019-12-04T19:06:03Z

@JTWendelborn you should run it from within octave, not bash. It is important that we get these details because it helps us to figure out what is wrong with the tests and/or octave (while the GUI is not very informative).

Running this command from the command line strangely gives me a syntax error:
-bash: syntax error near unexpected token 'test/config.test.json'.
However, when I run the compatibility test (Octave 5.1, Dynare 4.5.7) from the developer GUI, it reports that one of the tests has failed.

JTWendelborn · 2019-12-05T00:03:38Z

Sorry, my bad. I ran it from within Octave and got the following result, which seems to be the same that Alex reported in #82 :

       ---OUTPUT-START---

--- Autocorrelation ---
expected -0.071, actual -0.071
success
--- Unconditional variances ---
expected 1.1702, actual 1.1702
success
--- Input response functions ---
expected 0.0415, actual 0.0415
success
--- [AL] Autocorrelation ---
expected 0.7396, actual 0.777
failed
--- [AL] Unconditional variances ---
expected 8.2656, actual 15.9088
failed
--- [AL] Input response functions ---
expected -0.6807, actual -0.6807
success
4 out of 6 successful

I can try to install a different version of Octave/Dynare as my current setup is not officially compatible...

gboehl · 2019-12-05T00:51:41Z

Great, then we're all on the same page. Lets keep the compatibilty test in #82 and deal with NK_CGG99AL here (although it seems to me as if they are related).

@JTWendelborn Can you please confirm again that NK_CGG99AL works for you in Octave 5.1? This really puzzles me.

gboehl · 2019-12-05T00:52:46Z

Sorry, my bad. I ran it from within Octave and got the following result, which seems to be the same that Alex reported in #82 :
       ---OUTPUT-START---
--- Autocorrelation ---
expected -0.071, actual -0.071
success
--- Unconditional variances ---
expected 1.1702, actual 1.1702
success
--- Input response functions ---
expected 0.0415, actual 0.0415
success
--- [AL] Autocorrelation ---
expected 0.7396, actual 0.777
failed
--- [AL] Unconditional variances ---
expected 8.2656, actual 15.9088
failed
--- [AL] Input response functions ---
expected -0.6807, actual -0.6807
success
4 out of 6 successful

I can try to install a different version of Octave/Dynare as my current setup is not officially compatible...

To tackle this one, please see my latest reply in #82

JTWendelborn · 2019-12-05T01:07:45Z

@JTWendelborn Can you please confirm again that NK_CGG99AL works for you in Octave 5.1? This really puzzles me.

Yes, it works for me in the dev version of the MMB with Octave 5.1 and Dynare 4.5.7. I also tried out the different policy rules and they all work as well.

JTWendelborn · 2019-12-05T01:13:01Z

To tackle this one, please see my latest reply in #82

You mean:

Great, thank you! Did you do have to do the renaming of the ALTOOL folder as suggested?

I did not rename anything. It just worked.

gboehl · 2019-12-05T01:14:37Z

@JTWendelborn Can you please confirm again that NK_CGG99AL works for you in Octave 5.1? This really puzzles me.

Yes, it works for me in the dev version of the MMB with Octave 5.1 and Dynare 4.5.7. I also tried out the different policy rules and they all work as well.

Sorry! I was talking about the wrong model all the time. It is NK_CGG02AL that gives me an error with the Cholesky decompositon. Can you confirm that?

gboehl · 2019-12-05T01:15:32Z

To tackle this one, please see my latest reply in #82

You mean:

Great, thank you! Did you do have to do the renaming of the ALTOOL folder as suggested?

I did not rename anything. It just worked.

No, meant the other one ;-) I'll respond in #82.

JTWendelborn · 2019-12-05T01:18:34Z

@JTWendelborn Can you please confirm again that NK_CGG99AL works for you in Octave 5.1? This really puzzles me.

Yes, it works for me in the dev version of the MMB with Octave 5.1 and Dynare 4.5.7. I also tried out the different policy rules and they all work as well.

Sorry! I was talking about the wrong model all the time. It is NK_CGG02AL that gives me an error with the Cholesky decompositon. Can you confirm that?

No problem. NK_CGG02AL also works for me with the same setup...I can check tomorrow whether it does for all rules and shocks, but for the moment it didn't give me an error.

AlexDece · 2019-12-05T11:41:18Z

In the version for testing, NK_CGG02AL works for me (Windows 10, Octave 4.4.1, Dynare 4.5.7) for several MP rules, shocks and variables.

In the developer version NK_CGG02AL also works for me (Windows 10, Matlab 2017, Dynare 4.5.6) for the same rules, shocks and variables.

In short, variables of MP shock look the same, but for example Price markup shock process of a technology shock looks different! However, this seems to hold in general for price markup shock process (for that compare second picture of testing version with corresponding IRF in first picture of developer version).

These values are very close to 0 though (they should be equals 0) and besides, I think it does not make sense to plot IRFs for a shock process besides the one of the actual shock. So we could think about not showing the IRF of price markup shock process when we consider a technology shock ... Only show IRF of technology shock process then.

It might be easy to implement by checking the maximum absolute value of each IRF and if it is smaller than, lets say 1.e-8, then the IRF is not shown or instead there is a message in the place of the IRF.

Testing version
-> MP shock

-> Price markup in Technology shock

Developer version
-> MP shock

-> Price markup in Technology shock

gboehl · 2019-12-05T18:05:01Z

Setting a max/min value would be possible, but at the end the user could see that for himself. 1e-16 in any case is far beyond anything meaningful in terms of machine precision. If he choses to look at shock processes that are not triggered by the chosen shock - his bad.

@JTWendelborn @AlexDece @millazar
So it seems as if I am the only one facing this issue that NK_CGG02AL is not working under Octave?
In that case I would not longer investigate this issue as it seems Linux/Octave related and not of particular relevance in practice...

btatar13 · 2019-12-06T15:22:15Z

Describe the bug
NK_CGG99AL gives problem with Cholesky decomposition. See #82 (comment) and #82 (comment) for details.

@AlexDece as far as I understand, oo_.dr.jacobia is created by the AL routines. Apparently it fails somewhere on the way.

@millazar @btatar13 does either of you have a deeper understanding of these routines? If nobody knows how to fix it I would just remove the model for now, as it appears that it was never working (hence not our responsibility).

I can have a look at it in the evening or tomorrow morning

Setting a max/min value would be possible, but at the end the user could see that for himself. 1e-16 in any case is far beyond anything meaningful in terms of machine precision. If he choses to look at shock processes that are not triggered by the chosen shock - his bad.

@JTWendelborn @AlexDece @millazar
So it seems as if I am the only one facing this issue that NK_CGG02AL is not working under Octave?
In that case I would not longer investigate this issue as it seems Linux/Octave related and not of particular relevance in practice...

For me it works fine with Octave 4.4.1, except that after the iteration is finished you will need to wait one minute until you can close the window and the results are displayed. However, this applies for all AL models and I don't think so that it is normal.

@JTWendelborn @AlexDece @millazar
What is your experience?

AlexDece · 2019-12-06T15:33:17Z

I didnt notice a difference there...

…

On Fri, 6 Dec 2019, 16:22 btatar13 ***@***.***> wrote: *Describe the bug* NK_CGG99AL gives problem with Cholesky decomposition. See #82 (comment) <#82 (comment)> and #82 (comment) <#82 (comment)> for details. @AlexDece <https://github.com/AlexDece> as far as I understand, oo_.dr.jacobia is created by the AL routines. Apparently it fails somewhere on the way. @millazar <https://github.com/millazar> @btatar13 <https://github.com/btatar13> does either of you have a deeper understanding of these routines? If nobody knows how to fix it I would just remove the model for now, as it appears that it was never working (hence not our responsibility). I can have a look at it in the evening or tomorrow morning Setting a max/min value would be possible, but at the end the user could see that for himself. 1e-16 in any case is far beyond anything meaningful in terms of machine precision. If he choses to look at shock processes that are not triggered by the chosen shock - his bad. @JTWendelborn <https://github.com/JTWendelborn> @AlexDece <https://github.com/AlexDece> @millazar <https://github.com/millazar> So it seems as if I am the only one facing this issue that NK_CGG02AL is not working under Octave? In that case I would not longer investigate this issue as it seems Linux/Octave related and not of particular relevance in practice... For me it works fine with Octave 4.4.1, except that after the iteration is finished you will need to wait one minute until you can close the window and the results are displayed. However, this applies for all AL models and I don't think so that it is normal. @JTWendelborn <https://github.com/JTWendelborn> @AlexDece <https://github.com/AlexDece> @millazar <https://github.com/millazar> What is your experience? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#86?email_source=notifications&email_token=ANVSGFPDJFUACYETM53QLF3QXJU2RA5CNFSM4JU4I672YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGENCBI#issuecomment-562614533>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANVSGFJW7HBGZGK64WQ5HTDQXJU2RANCNFSM4JU4I67Q> .

gboehl assigned millazar and AlexDece Dec 3, 2019

gboehl mentioned this issue Dec 3, 2019

Compatibility tests with octave fail #82

Closed

gboehl changed the title ~~NK_CGG99AL not working~~ ~~NK_CGG99AL~~ **NK_CGG02AL** not working Dec 5, 2019

gboehl changed the title ~~~~NK_CGG99AL~~ **NK_CGG02AL** not working~~ NK_CGG02AL not working (edit: NOT CGG99AL!) Dec 5, 2019

gboehl added the wontfix This will not be worked on label Dec 6, 2019

gboehl unassigned millazar and AlexDece Dec 6, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NK_CGG02AL not working (edit: NOT CGG99AL!) #86

NK_CGG02AL not working (edit: NOT CGG99AL!) #86

gboehl commented Dec 3, 2019 •

edited

Loading

JTWendelborn commented Dec 3, 2019

j2L4e commented Dec 4, 2019

AlexDece commented Dec 4, 2019 •

edited

Loading

gboehl commented Dec 4, 2019 •

edited

Loading

gboehl commented Dec 4, 2019

JTWendelborn commented Dec 4, 2019

j2L4e commented Dec 4, 2019 •

edited

Loading

JTWendelborn commented Dec 4, 2019 •

edited

Loading

AlexDece commented Dec 4, 2019 via email

gboehl commented Dec 4, 2019

JTWendelborn commented Dec 5, 2019 •

edited

Loading

gboehl commented Dec 5, 2019

gboehl commented Dec 5, 2019

JTWendelborn commented Dec 5, 2019

JTWendelborn commented Dec 5, 2019

gboehl commented Dec 5, 2019

gboehl commented Dec 5, 2019

JTWendelborn commented Dec 5, 2019

AlexDece commented Dec 5, 2019 •

edited

Loading

gboehl commented Dec 5, 2019

btatar13 commented Dec 6, 2019

AlexDece commented Dec 6, 2019 via email

NK_CGG02AL not working (edit: NOT CGG99AL!) #86

NK_CGG02AL not working (edit: NOT CGG99AL!) #86

Comments

gboehl commented Dec 3, 2019 • edited Loading

JTWendelborn commented Dec 3, 2019

j2L4e commented Dec 4, 2019

AlexDece commented Dec 4, 2019 • edited Loading

gboehl commented Dec 4, 2019 • edited Loading

gboehl commented Dec 4, 2019

JTWendelborn commented Dec 4, 2019

j2L4e commented Dec 4, 2019 • edited Loading

JTWendelborn commented Dec 4, 2019 • edited Loading

AlexDece commented Dec 4, 2019 via email

gboehl commented Dec 4, 2019

JTWendelborn commented Dec 5, 2019 • edited Loading

gboehl commented Dec 5, 2019

gboehl commented Dec 5, 2019

JTWendelborn commented Dec 5, 2019

JTWendelborn commented Dec 5, 2019

gboehl commented Dec 5, 2019

gboehl commented Dec 5, 2019

JTWendelborn commented Dec 5, 2019

AlexDece commented Dec 5, 2019 • edited Loading

gboehl commented Dec 5, 2019

btatar13 commented Dec 6, 2019

AlexDece commented Dec 6, 2019 via email

gboehl commented Dec 3, 2019 •

edited

Loading

AlexDece commented Dec 4, 2019 •

edited

Loading

gboehl commented Dec 4, 2019 •

edited

Loading

j2L4e commented Dec 4, 2019 •

edited

Loading

JTWendelborn commented Dec 4, 2019 •

edited

Loading

JTWendelborn commented Dec 5, 2019 •

edited

Loading

AlexDece commented Dec 5, 2019 •

edited

Loading