Weird error with input variables not altering the simulation

[serman]

Hello
I am new here, I started tinkering with SDEverywhere a week ago and if everything goes well I hope to keep doing it for the next few months!

I am building a proof of concept to check how well SDEverywhere plays with the model we have, and I am stuck with an issue. Let's see if I can explain it:

We have a world model where we can control policies and visualize indicators in different regions.
For instance, we can decide to play with the US and control the policies for the US only. We can decide that US invests in renewables but the rest of the world doesn't and see what's happening with the CO2 emissions in this scenario.

To "enable" a region to be controlled we have a Vensim variable called:

Switch for policies 1 is automatic 2 is userset[region_subscript]

If we set it to 2 for US, it means that the policy variables we change for US will affect the simulation.

---

The problem is that when the simulation runs in SDEveryhwere, the policies for the regions that depend on enabling the "Switch for policies 1 is automatic 2 is userset[us]" are not affecting the simulation.

Test scenario A):

1. SSGDR slider -> impact on "SSGDR policy to stretch repayment AF" chart. No dependencies from the Switch for policies...
2. ISPV slider user[us] impact on Total CO2 emissions us only when "Switch for policies 1 is automatic 2 is userset[us] == 2"
3. Switch for policies 1 is automatic 2 is userset[us] takes the value 2 by default (but could be changed with the slider).

Result:

• Sliding the SSGDR sider changes SSGDR AF chart -> GREAT
• Sliding the ISPV slider user[us] --> doesn't change anything in any chart --> BAD

Test scenario B):

We export a new model in Vensim. The same as the scenario A) However in this case Switch for policies 1 is automatic 2 is userset[us] is configured to be "2" by default, in Vensim.

In this case, I remove the "Switch for policies 1 is automatic 2 is userset[us]" slider

With this change, now ISPV slider user[us] slider has an impact on the simulation.

---

So there might be a problem setting up the "SWTICH ... []"variable = 2. But I am sure that the variable value is 2 because it is also represented in the charts. It is a strange behavior, that I don't know how to solve. I was wondering if you might have any clue about this error. @chrispcampbell

Note. There is no error in the terminal console. I have attached the charts.csv and inputs.csv

inputs.csv
graphs.csv

[chrispcampbell]

Hi @serman, thanks for providing lots of good details about this problem. The issue as I see it (after inspecting the mdl that you guys sent offline) is that SWITCH for policies 1 is automatic 2 is userset[region] is not considered to be a "constant" value from the compiler's perspective, see the definition here:

SWITCH for policies 1 is automatic 2 is userset[region]=
	IF THEN ELSE(region = us, 2, 1)
	~	Dmnl [1,2,1]
	~	To choose if a policy is chosen by user (=2) or automatically (=1)
	|

Currently it's only possible to configure an input variable if the underlying model variable is a constant (when the right hand side of the equation is a simple number or a constant list). It's not possible to configure an input that overrides a non-constant equation. Unfortunately the compiler doesn't currently produce an error message if you try to configure a non-constant; if we had had that, it would've helped catch this problem earlier. I filed an issue (#441) so that we can improve the compiler to report an error message in this case.

Let me know if the above makes sense. I'm not sure I understand yet the goal with the way SWITCH for policies 1 is automatic 2 is userset is currently defined. If you can explain more about how you're expecting or want it to work, that would be helpful. At first glance, I think if you want to have a global switch that controls whether a specific region is chosen by user or automatic, you could redefine your model variable to be constant for each region:

SWITCH for policies 1 is automatic 2 is userset[region]=1
	~	Dmnl [1,2,1]
	~	To choose if a policy is chosen by user (=2) or automatically (=1)
	|

If you set it up this way (and have a slider or switch defined in inputs.csv that controls that value for each region), I think it should have the effect you're looking for. Let me know if that makes sense.

[serman]

I cannot answer why it is defined as it is. I'll leave that to Ulrich.

Conceptually in our future simulation, the player will be manipulating policies in only one region of the world, but the player can also decide what other countries are doing. That variable SWITCH for policies 1 is automatic 2 is userset is used for two proposals:

• When SWICH is 2 for a region, it means the values of the policies in the world corresponding to that region are set by the user
• With other values, we can assign different scenarios to the rest of the regions.

I am confident Ulrich can find another way of doing this with "constants" instead of formulas, following your example as reference.

Thanks again!

[chrispcampbell]

One other note (unrelated to the problem described above). If you have a switch and want it to be controlled with a checkbox (or similar UI element) instead of a slider, the default template has support for that, but I realize we don't yet have documentation on how to configure it in inputs.csv (I hope to improve the docs soon with more guidance on configuring a web app).

If you change your first input row to the following, it will make it show up as a checkbox instead of a slider:

1,switch,view1,Switch for policies 1 is automatic 2 is userset[us],Switch for policies 1 is automatic 2 is userset[us],,Sliders,,,2,,(units),,,,,,,,,,,,2,1,|,,

The sample app code inserts that "When this is unchecked..." text, which is leftover from an older example and not really relevant here, so feel free to remove the text or modify to your liking. Also, ugh, I think there's a bug that causes the checkbox to show up unchecked initially regardless of the default value, but I'll leave that as an exercise for the reader for now :)

Again, the sample app code is meant to be a starting point, so you can configure your own app however you like, but I just wanted to demonstrate that we do have support for "switch" inputs that provide additional functionality.

[serman]

To avoid confusion, let's keep the discussion here. I'll ask Ulrich in case I don't understand something about the model or vensim.
We have this model:
https://hidrive.ionos.com/lnk/KncADFgwV
with the config files https://hidrive.ionos.com/lnk/Yxda5pbVj

"SWITCH for policies 1 is automatic 2 is userset[region]" is a constant here but the problem is the same I described: Variables that depend on this switch being ===2 don't affect the simulation.

Sorry for the misunderstanding with the "debug version" of the model that we shared with you. That one was only in use to help us to identify the error.

Rgds

[chrispcampbell]

Hi @serman, my apologies, when I tried the example yesterday (after converting it back to use a constant), I didn't notice that the issue you described is still present. I am able to reproduce the problem with the latest files linked above.

The issue turns out to be a bug in some older code that does constant analysis in conditional statements (IF THEN ELSE) to eliminate unused code branches. That code did not correctly handle the case where an input variable uses subscripts, and that bug caused some IF THEN ELSE statements to be eliminated incorrectly, which meant that the Switch for policies value had no effect at runtime.

The code in question is scheduled to be removed in the near future, because there is a new implementation of the parse/read/gen phases of the compiler, and that new code doesn't suffer from the same bug. The new implementation can be enabled with an environment variable like this:

SDE_NONPUBLIC_USE_NEW_PARSE=1 npm run dev

EDITED 2024.03.12: The SDE_NONPUBLIC_USE_NEW_PARSE=1 flag is no longer needed if you first upgrade to @sdeverywhere/cli v0.7.20 or later, since that release use the new implementation by default.

I'd recommend that you first delete the sde-prep folder in your project to force the builder to recompile the model using the new code paths.

When I run your project with that flag set, then it seems to work correctly:

• when the "switch" slider is set to 2, then the ISPV slider user[us] slider affects the green line
• when the "switch" slider is set to 1, then the ISPV slider user[us] slider does not affect the green line

Let me know if this works for you. I'm hoping to make the new compiler implementation the default in the near future, so I'm not sure if it's worth fixing the bug in the old code. Let's see first if there are any other issues you run into that might affect that decision.

[serman]

Finally, it works!
Thanks so much for your help!

[chrispcampbell]

@serman: I've amended my answer above to note that the SDE_NONPUBLIC_USE_NEW_PARSE=1 workaround is no longer necessary since as of @sdeverywhere/cli v0.7.20, the new (non-buggy) implementation is now the default. To upgrade, you can go to the root directory of your project, install the latest version, and restart the dev server:

npm install @sdeverywhere/cli@latest
npm run dev