Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit interface between JS runtime package and generated C model #302

Open
chrispcampbell opened this issue Dec 12, 2022 · 1 comment
Open

Comments

@chrispcampbell
Copy link
Contributor

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
Copy link
Contributor Author

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants