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

Expose accessor functions for control parameters #295

Closed
chrispcampbell opened this issue Dec 9, 2022 · 0 comments · Fixed by #296 or #294
Closed

Expose accessor functions for control parameters #295

chrispcampbell opened this issue Dec 9, 2022 · 0 comments · Fixed by #296 or #294

Comments

@chrispcampbell
Copy link
Contributor

To help enable the other changes and refactoring being done to support non-1 SAVEPER values in #291, I'm proposing to change the code gen to emit 3 accessors/getters for INITIAL TIME, FINAL TIME, and SAVEPER. These values are needed by the runtime and runtime-async packages when allocating the buffers that will hold the output values. The generated C code would look like this:

// Control parameter accessors
double getInitialTime() {
  return 2000;
}
double getFinalTime() {
  return 2100;
}
double getSaveper() {
  return 1;
}

Once these are available, we'll be able to simplify the build and runtime packages:

  • Currently the build package expects the developer to provide the initial/final times in the sde.config.js file, but this is error prone (because they can get out of sync with the actual values in the mdl) and also just redundant configuration. It shouldn't be necessary to pass these in as long as we can read them from the generated model.
  • Once these accessors are available, the runtime package can read them after initializing the wasm module, and crucially, we'll have access to the SAVEPER value so that we can fix the few other places that are currently assuming it to be 1.

I have the code gen changes set up such that it expects INITIAL TIME and FINAL TIME to be constant values, and SAVEPER can either be a constant numeric value or equal to TIME STEP (which is also expected to be constant). I think these are valid assumptions given the way the rest of the native code works.

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