Some interface design decisions regarding input data, outcome in data2draws

[Dashadower]

A rough implementation of data2draws is partly implemented. You can write the following python code:

model = StanVensimModel("ds_white_sterman", am, 0.0, list(range(0, 10)))  # 0.0 is initial time, range(0, 10) is the integrations times
model.set_prior("inventory_adjustment_time", "normal", 0, 1)
model.set_prior("minimum_order_processing_time", "normal", 0, 1)

This (currently) results in the following generated code:

#include ds_white_sterman_functions.stan

data{
}

transformed data{
    real initial_time = 0.0;
    int T = 10;
    array[T] real times = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}
}

transformed parameters {
    # Initial ODE values
    real inventory_initial = 2 + 2 * 10000;
    real expected_order_rate_initial = 10000;
    real work_in_process_inventory_initial = 8 * max(0,10000 + 2 + 2 * 10000 - 2 + 2 * 10000 / 8);

    vector[3] initial_outcome;  # Initial ODE state vector
    initial_outcome[1] = inventory;
    initial_outcome[2] = expected_order_rate;
    initial_outcome[3] = work_in_process_inventory;

    vector[3] integrated_result[T] = ode_rk45(vensim_ode, initial_outcome, initial_time, times, minimum_order_processing_time, inventory_adjustment_time);
}

parameters{
    real inventory_adjustment_time;
    real minimum_order_processing_time;
}

model{
    inventory_adjustment_time ~ normal(0, 1);
    minimum_order_processing_time ~ normal(0, 1);
}

The problem is how we're going to expose vector[3] integrated_result[T] to the user. There are 2 ways the user would want to access it. 1. along the time axis(which results in a array of length T with a single stock) 2. for a single timestep(which results in a vector of length 3)

Another problem is linking the codegen with data specified by the user. I'm not sure what form the data would have to be inputted from the user. If data was specified, we'd have to construct the data block that matches the inputted data.

[hyunjimoon]

Some default choices, with the help of @hazhirr and @jandraor 's precious prior knowledge on SD modeler's default decisions. Let me know (as comment below) if you have additional knowledge that we can quantify! I am not sure whether 2 should be user or developer's duty. If it doesn't complicate the coding too much, we can supply. However, as users may find this measurement error concept new, I feel it is important to deliver this concept well; especially since this appears again in SOPS policy optimization of the second workflow 3.b. The state_init as est_param would be the famous latent data concept. Bob's prior knowledge and unexplained variation explains this better.

I will make 2 and 3 as new issue after getting @Dashadower 's confirmation.

Implementation duty are

• on user: 1
• on developer: 2,3

1. penalize only the states (=stock)
   all comparison between simulated and observed state is done with stock variable. Users should change the structure within vensim, by adding artificial stock ([var_name]_state) that ensures its value is close to the value of the original type (observed data of flow or auxiliary variable).

2. state_init as ass_param
state_init is ass_param by default; when user selects to it as est_param, we need two machines under the hood:

• add two est_param: initial (latent) value z_init and measurement error scale z_sigma

• add times's length by one
  times is the index variable along which integration happens. Let's say we have length 20 observed state data series vector[20] y. Then,times is 1:19 for state_init is ass_param and 0:19 state_init is est_param. When state_init is ass_param, the length of times should be 19 (y[0] becomes y_init). However, when state_init is est_param, then the penalizing (between z_init and y_init happens from time 0.

The need for 1:19 for state_init as ass_param is bc we don't want to simulated what's already known as explained here.

3. separate implementation of data2draws vs draws2data

a. data block
@Dashadower I don't know whether times in data vs transformed data is better.

data2draws has the following components

    int n_obs_state;
    int n_t;
    real initial_time;
    array[n_t] real times;
    array[n_t] vector[n_obs_state] y; //observed states

draws2data has the following components

    int n_obs_state;
    int n_t;
    real initial_time;
    array[n_t] real times;

b. function, transformed parameter block are the same

c. parameter and model block
only for data2draws

d. generated quantities block

• y_ppc for both
• log_lik for data2draws
• _tilde for draws2data on generator logics (~ parameter and model block for data2draws)

Will commit the current fixes by today which includes some minor fixes (but not d.)

[Dashadower]

I don't know whether times in data vs transformed data is better.

I would rephrase that question into, "Do you expect the integration times to be able to vary, without any changes to the existing model?". If the answer is yes, then I would believe that moving times into data would be the correct option.

However, since we also handle the input data automatically within pysd, it would't hurt to just move it into data regardless, since that would remove the need for recompilation in the event that times changes.