Use of tabbed arrays for a model to convert to SDEverywhere

[eubtube]

Hello!

My colleague Khaled asked a version of this question to @chrispcampbell and @ToddFincannon, but wanted to ask a follow-up here in case it's helpful to others.

We are working to conform our model that we've been building for livestock response in Somalia to the SDEverywhere so that we can convert the model and make some web apps. One main issue that we are facing is that we use multi-dimensional subscripted variables which require tabbed arrays. We are pursuing a suggestion from a colleague to insert dummy values in the Vensim model, then use .csv with the parameter values to substitute the tabbed arrays.

We are thus looking for the SDE feature, similar to that of Vensim's Simulation Control -> Constant Changes -> Changes files -> then we select the .csv containing the parameter values we want reflected into the model (screenshot below) before simulating.

Based on our perusal of the SDE documentation, and the correspondence we received from Chris and Todd, our understanding is that the primary way to achieve this would be using the GET DIRECT CONSTANTS function in Vensim to build this functionality into the model directly.

We were previously under the impression that it might be possible to use an SDEverywhere function to ingest data from a .csv (without changing the variables in Vensim to include the GET DIRECT CONSTANTS function), but it seems that may not be the case. Could you please confirm that?

We have tried bringing in a .csv to a small sample model using a directData tag in a spec.json file, but the dummy data persisted in the model based on the tests we ran:

And here are screenshots of the spec.json file content and the full contents of the referenced .xlsx file.

Could y'all confirm that there are no functions or features built in to SDEverywhere that would allow us to achieve this, or will we need to use the GET DIRECT CONSTANTS function on our variables in Vensim first? Apologies if this is a silly question, but I'm both new to this package and to SD in general!

Thank you!

Aaron

---

EDIT - 10/28
We went ahead and pressed forward with doing some testing with use of the GET DIRECT CONSTANTS function in Vensim using a very simple model to test and encountered an error when trying to test the SDE build of the model:

Trial_20221028.c:73:21: error: implicit declaration of function '_GET_DIRECT_CONSTANTS' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
  _male_var[i][j] = _GET_DIRECT_CONSTANTS("data/csv.csv", ",", "B2");
                    ^
1 error generated.
make: *** [Trial_20221028.o] Error 1

I have tried this with both version 0.5.9 and the latest version and received the same error. It appears to be an issue in the C code with the function being undefined, but we're not sure how to resolve it and get the test to run successfully.

I have attached the model file (just one variable), which was built using the 'directconst' sample model as a reference, the reference .csv, and the dat file for the model.

trial_20221028_pkg.zip

Thank you for any support you can provide.

[ToddFincannonEI]

Thanks for trying SDEverywhere, Aaron. I installed the latest version of the SDEverywhere CLI with:

npm install @sdeverywhere/cli -g

and did sde test on your model, which generated correct results. If you do sde -v, you should get version 0.7.4.

So it looks like GET DIRECT CONSTANTS is working OK in the latest version of SDEverywhere. But I don't understand what you are trying to accomplish with overriding dummy variables. You can read the data into the variable with GET DIRECT CONSTANTS just like you do in your test model. This should obviate the need for the tabbed arrays.

Since your original model uses tabbed arrays, my understanding is that the data is static and will not change between runs. That would allow you to use GET DIRECT CONSTANTS. You don't need to use the "Constant changes" panel in Vensim — the file name can be written in the equation itself.

[chrispcampbell]

FWIW, on the topic of overriding variables, a colleague made the case last week that SDE should have support for Vensim's cin file format as a way to override initial values (which I filed today as #282). I could see a similar case being made to support other types of "Constant changes" for situations like Aaron's. (I think what Todd wrote above still sounds like the right way to go for now, but I'm just throwing this out there as a way to possibly make overrides easier in the future.)

Anyway, @eubtube let us know if you're able to get things working based on Todd's suggestions. I'll also note that I haven't quite finished updating the documentation to reflect the new @sdeverywhere packages, so things are unfortunately may appear to be in a transitional state and could lead to confusion about which package/version to install, how to generate a web app, etc. Improving the docs is on my todo list for this month.

Also, @eubtube let me know if you need help generating a web app for your model; the create command should get you started, but I can provide further guidance if you need it.

[eubtube]

Hi Both,

Thanks so much for your thoughtful responses and apologies for the delay on our end, we've had some leave and illness on our end.

First @ToddFincannonEI, thanks for testing our sample model for GET DIRECT CONSTANTS. I got a fresh install of the latest version of SDE going (was using 0.5.3 before) and it worked fine. So I think we're all set there.

@chrispcampbell, thanks for pointing us to the new way to make the web app. I had been holding back my version because the web app builder had appeared to go away when y'all removed the --genhtml argument from sde build. I really appreciate the wizard that y'all put together for the web app piece. It's very nice and great that it auto updates with changes to the configs.

At this point, we are still encountering one more issue on our ALLOCATE AVAILABLE piece, which is crucial to using our model in SDE. We put together a very simple sample model to test this functionality out with a couple of of our test cases and got this error when we tried to build it:

It seems to be something C doesn't like, but we've compared it against your sample "Allocate" model and can't see anything glaring. Thought y'all might know this error offhand. Here is the model if you want to take a look.

Alloc_trial_20221114_pkg.zip

Thanks again for all your support!

Aaron & Khaled

[ToddFincannonEI]

This is a bug in the SDEverywhere equation reader in the special handling for the ALLOCATE AVAILABLE function. I will be turning my attention to the SDEverywhere compiler this week, and will look at this then.

[ToddFincannonEI]

The problem is that the equation reader expects the priority profile argument to ALLOCATE AVAILABLE to be a non-apply-to-all variable, but in the test model, it is an apply-to-all variable. That is, in the test model, a single constant value of 1 is applied to all subscripts of the Priority vector variable.

Priority vector[region,PriorityVec] = 1

The EquationReader exception does not occur if the priority profile subscript indices are defined separately ("non-apply-to-all").

Priority vector[region,pType] = 1
Priority vector[region,pPriority] = 1
Priority vector[region,pWidth] = 1
Priority vector[region,pExtra] = 1

This is a reasonable limitation, because in practice, ALLOCATE AVAILABLE is only useful when the priority is different for each requester. This prevents the priority profile from being an apply-to-all variable. For instance, in the allocate.mdl test model, the priority is different for each region:

priority vector[region,ppriority] = priority[region]
priority[region] = 1,2,3

One other thing to note is that the pType value should be 3, because SDEverywhere only supports the normal curve type. In fact, it ignores pType altogether. This and the priority issue above should be documented.

Separating the Priority vector subscripts as shown above solves the EquationReader problem, but the converted test model still does not generate correct output. I will file an issue once I understand it better.

[ToddFincannonEI]

The other problem in the test model turns out to be caused by demand greatly outstripping supply. Vensim can handle this, but not the SDEverywhere implementation. If we reduce demand to fit supply, the model works.

Demand[region] = 300

Here is the test model modified to meet the limitations discussed in this post and the previous one.

alloc_test.zip

[GaafarK]

Hey Todd,
I'm Khaled, Aaron's colleague working together on getting our model to be compatible with SDE.
First of all, I'd like to express my deep appreciation for all the help you've given us so far. We have successfully implemented your advice on "GET DIRECT CONSTANTS" and it seems to work just fine now, so that's great news.

Regarding the ALLOCATE AVAILABLE:

• I understand the "non-apply-to-all" feature and it makes good sense.
• I understand your point on pType and also it makes good sense, we do in fact use pType=3 in our full model

I have a few follow-ups that may help us close this issue:
1. On Priority vectors:

ALLOCATE AVAILABLE(request,pp,avail)
In order to provide the second argument to the ALLOCATE AVAILABLE macro, "pp" as shown in the formula above from Vensim, we would need to have the individual priority parameters (one for each requester) collapsed into a single variable Priority vector[region,pPriority] arrayed by region which would then provide an input to "pp". I only know one way of doing this in Vensim, which is via tabbed arrays. Can you confirm that this is the way to go?
I saw it was done in the ALLOCATE AVAILABLE sample model, but I also remember reading that tabbed arrays aren't supported.

2. On demand outstripping supply
I see you mentioned that in our test model demand "greatly" outstripped supply, the solution of which was to reduce demand to fit supply, making total demand <= supply. This is a little problematic for me to understand since in Vensim if total demand < supply, each requester gets what they demanded, but if supply < demand the individual priorities are used to determine how much of such scarce supply does each requester get. That last part, in our understanding, is the true value of ALLOCATE AVAILABLE, and the key reason why we implemented it in our Vensim model as supply will most likely always be less than the total demand.
My expectation for our test model was each requester was going to receive 333.3 given that the demands and priorities were equal.
So can you please help shed some light on what constitutes "greatly outstripping supply", and your advised way forward?

Thanks in advance, and I really appreciate all the support you've granted us thus far.

[GaafarK]

Hey Todd,
I hope all is well with you.
I've spent a few hours with Aaron today further testing the Allocate available implementation on SDE, using our previously shared models as well as the sample model provided on the GitHub.
We noticed something that may help address the issue of "demand greatly outstripping supply". Below is a screenshot of the Allocate sample model (which builds smoothly on SDE). I plotted a graph of Total demand/ Total supply and total demand is initially ~80x supply @ t=0, falls down to 2x @ t=5, to finish at 1.08x @t=10.

When testing on SDE (comparing the SDE output with the .dat generated from Vensim), we got quite good results (a difference of <1%), screenshot below.

This is quite perplexing, as we faced an issue when total demand =3x supply, yet no issue was faced when trying to build and test the sample model (having a TotalDemand/TotalSupply of >3x until t=3). So we are wondering, why is the sample model not giving us the same errors?

For your reference please find attached our edited version of the sample model.
Test-20221205.zip

Thanks in advance and looking forward to hearing back from you.
Khaled and Aaron

[ToddFincannonEI]

Even though SDEverywhere doesn't support the TABBED ARRAY function, you can do much the same thing with subscripted constants.

Subscripting constants

The constant list can have one or two dimensions. The arrays_varname sample model in the SDEverywhere models directory has some examples.

The allocate sample model shows how this could work for ALLOCATE AVAILABLE.

priority[region] = 1,2,3

priority vector[region,ptype] = 3
priority vector[region,ppriority] = priority[region]
priority vector[region,pwidth] = 1
priority vector[region,pextra] = 1

You could also use GET DIRECT CONSTANTS to read them from a file.

I take your point about demand exceeding supply being the condition of interest for ALLOCATE AVAILABLE. I will take another look at your previous sample model to see if I can understand why it is failing in SDEverywhere.