You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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(constchar*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):
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.
The text was updated successfully, but these errors were encountered:
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).
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):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 newsetInputsFromBuffers
in the generated model):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.The text was updated successfully, but these errors were encountered: