Revisit interface between JS runtime package and generated C model

[chrispcampbell]

One of the things I'd like to address before we have a "1.0" of SDE is the exported API of the C model. I'm not planning to make these changes right away, but wanted to create this issue to start documenting/discussing.

Originally there was one primary entrypoint in the C API that worked with string data (this one used setInputs in the generated model):

char* run_model(const char* inputs);

Later I added an alternate entrypoint that takes pointers to pre-allocated double buffers to have more optimal communication between the JS-level runtime code and the wasm model (this one used a new setInputsFromBuffers in the generated model):

void runModelWithBuffers(double* inputs, double* outputs);

Besides the awkward naming of the new ones (to avoid conflicting with the old), it would be preferable to have only one way of doing things, both to simplify the implementation and to make the API less confusing.

I think we could probably reimplement the old string-based API as a higher-level thing that's written to use a lower-level one (more like runModelWithBuffers).

There may be other changes we could make to the C API (in model.c) and in the generated C code that is related to the above; we can note them in comments in this issue and then maybe figure out a plan for this once we have time to think things through.

[chrispcampbell]

As a secondary thing, we might want to (re)consider how the control parameters (INITIAL TIME, FINAL TIME, and SAVEPER) are initialized and made available to the higher-level code. See related discussion in the two recent issues about the control parameter accessors (#295 and #301).

For example, instead of implicitly initializing these in the new accessors, it might make sense to (also) provide an explicit way of initializing them, like a initControlParameters function. The benefit of this is that the higher level code could potentially override the values in the model, or set them based on inputs (similar to how runModelWithBuffers takes a list of input values).

EDIT: For the record, the issue described in this comment was filed as a separate issue #305, that way the scope of this issue is limited to improving the C runModel API.

[chrispcampbell]

Here's the spec that I wrote to get my head around the problem. I used this as a prompt to Claude Code, which generated the initial set of changes, which I edited pretty heavily.

• Our goal is to get rid of the old run_model entrypoint, along with the void setInputs(const char* inputData) API
  that is generated by the compiler and the char* outputs stuff used by run_model
• In short, we shouldn't have two ways of running the model, two ways of parsing inputs, and two
  ways of storing outputs
• We shouldn't have input string parsing or output string generation in the core model API or in the
  generated model code; we can retrofit the main.c file to handle the string code so that it behaves
  just like it did before, but implemented on top of the core API which only deals with double* buffers
• We want users of the C API to only use the runModel API that takes double* inputs and outputs
  (we will preserve the old char* inputs parsing and char* outputs generation in main.c retrofitted
  on top of the runModel API that takes double* inputs and outputs buffers)
• Add a void runModel(double* inputs, double* outputs) entrypoint that delegates to runModelWithBuffers,
  passing NULL for every argument after inputs and outputs
• Move the code that parses char* inputs from the generated setInputs function to main.c
  (make that code update a double* buffer so that we can pass it to runModelWithBuffers)
• Remove void setInputs(const char* inputData)
• Rename setInputsFromBuffer to just void setInputs(double* inputData)
• One issue is that the "old" char* input approach allowed for setting only a subset of all possible
  inputs (for example, even if there are 500 possible inputs, you could pass a string like "5:9.2 21:2"
  which would only set the inputs at index 5 and index 21). But the "new" double* input buffer approach
  (the generatd setInputsFromBuffer function) ONLY works if you provide ALL input values in the exact
  order that they're declared in the spec.json file. We need a middle ground here. I propose that we
  keep the pointer table (static double* inputVarPtrs[]) approach from the old setInputs function,
  then have setInputs(double* inputValues, int32_t* inputIndices). If inputIndices is NULL, then
  inputValues is assumed to contain ALL input values (like how setInputsFromBuffer works currently).
  But if inputIndices is non-NULL, it should be similar to how we handle outputIndices, where the
  first value in inputIndices is the number of inputs being specified, then the next value in
  inputIndices is the index of the first input, and the first value in inputValues is the value
  corresponding to that index and so on. This requires us to change the runModelWithBuffers function
  signature to:
  void runModelWithBuffers(double* inputs, int32_t* inputIndices, double* outputs, int32_t* outputIndices)
  We can still have:
  void runModel(double* inputs, double* outputs)
  which is shorthand for calling:
  runModelWithBuffers(inputs, NULL, outputs, NULL)

[ToddFincannonEI]

I'm in the process of understanding how this will affect EPS. I'll comment on this PR and the other one soon.