.cin files

[akuptel]

Does SDEverywhere support using .cin files? I know this was marked as an issue three years ago but when I tried using SDEverywhere with my model that uses multiple .cin files, I don't think it was included. Do I just point to the .cin files in the simulation manager and ensure the model and .cin are in the same directory?

[travisfranck]

I thought there was a way to use CIN files but I'm not seeing it right now. @chrispcampbell – what am I missing?

Where I've looked:

1. I don't see a way to include CIN files in the model.csv file, for usual web app builds.
2. I thought there was a way to pass in CIN files during a CLI call, but I don't see that as an option either

Breadcrumbs for others: I was looking at the SDE cli pluging, with documentation here:
https://github.com/climateinteractive/SDEverywhere/blob/main/packages/cli/README.md

As stated there, the easiest way for most people to run the CLI if you've focus on publishing to the web is:

npx sde -h      # print out help info
npx sde run    # print out help for `run`

[chrispcampbell]

@travisfranck: Looks like our replies crossed paths. There's no support in SDEverywhere for reading cin files. Maybe you're thinking of the generated C model, which allows for passing in a txt file of input values at runtime (but that's a different format; we've never had native support for reading cin files).

[travisfranck]

Yep -- must have been the compiled C app. Thanks for clarifying.

[chrispcampbell]

Hi @akuptel, thanks for writing in. SDEverywhere currently doesn't support loading cin files, but it could be made to do so if there's a clear need and use case.

Can you explain a bit more about in which part(s) of the build or testing process you'd like to be able to use cin files? For example, do you want something like #282? (That issue was about adding a hook in the build (code generation) process to override constant initializations at build time.) Or do you want to be able to use existing cin files to represent test/comparison scenarios in model-check? (The latter is something I've considered adding but I hadn't filed an issue / feature request, but I just did that, see #719.)

Or if there are other places not covered by those two issues, let me know.

[akuptel]

I think my personal use case is both? I use one CIN file to override a single constant in the model build representing initial housing stock but I don’t change those (as they come from some data analysis I’ve completed). That use case seems more like using a CIN during model build. I use second CIN file to override some calibrated parameters. As I update the model, the calibrated values change and I update the CIN file. This use case seems to be more like your second example; as I recalibrate the model, I would put in the new set of parameter values from the CIN and run the model from there without having to build it again.

[chrispcampbell]

Thanks, this was helpful. It highlights that there is a distinction between two use cases (that have two different but complementary solutions):

1. Using a cin file to override constants at build time. This is a one-shot thing; once the constants are baked into the generated model file. This is basically Add support for using cin files to override constant initializations at build time #282.
2. Using a cin file to override constants at runtime. By "runtime", I mean either at initialization time (a one-time thing when the app/model is loaded), or later (where the user can select a different set of constant values). This is a different feature, see Allow for overriding constants at runtime #470.

Both of these would be useful. If anyone wants to prototype the changes, I could advise. Otherwise, it is something I can look into in the new year.

[travisfranck]

My understanding, from our in-person conversation, is that both of your CIN files are using to initialize variables instead of reading in values from other file formats (DAT, VDFX, CSV, XLS, etc). Is that correct? I want to state that because there might be some reasonable workarounds.

[akuptel]

Yes! So I suppose just being able to input a CIN when the model is converted would be helpful. One would work around would definitely be just to input these constants in the model itself. However, I brought this up to confirm if SDE has this capability, and to suggest it as a feature for others as well since I think it would be useful. On Dec 15, 2025, at 7:25 PM, Travis Franck ***@***.***> wrote:  My understanding, from our in-person conversation, is that both of your CIN files are using to initialize variables instead of reading in values from other file formats (DAT, VDFX, CSV, XLS, etc). Is that correct? I want to state that because there might be some reasonable workarounds. — Reply to this email directly, view it on GitHub<#718 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A27R543ZK76OEB5F2XQ7TGD4B5GODAVCNFSM6AAAAACO4STK4SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMRWGQZDGNI>. You are receiving this because you were mentioned.Message ID: ***@***.***>