Evaluating code entered by web app users in the browser

[HildingElmqvist]

Thank you, Tom for providing this package. It would be great to enable web app users to enter model equations and quickly simulate in the browser.

I therefore tested to eval code, using Base.invokelatest, using GeneralizedGenerated and using RuntimeGeneratedFunctions. When using Base.invokelatest and RuntimeGeneratedFunctions, compilation to wasm did not work. I could compile code using eval and GeneralizedGenerated. However the called function returned the wrong value, always zero.

Is there an fundamental reason with WebAssembly with allowing evaluating user code or is it a matter of implementation effort?

[tshort]

HI Hilding,

I don't think there's an easy way to "eval" Julia code. All of the approaches you mentioned use the Julia compiler in some form. It'd be a big effort to mimic that.

One way that should work now [*] is to run the model equations in JavaScript. It might work well for the types of problems a user could be expected to enter. JavaScript can be surprisingly fast. A rough outline could be:

• Grab the user equations as strings, and wrap them in a model function (still strings).
• Create a Julia model function that uses JS.eval to call the JavaScript model function. This model function is used by the Julia solver.
• Read the results from JavaScript.

The equations will be in JavaScript, not Julia.

From the Julia side, it'll look like a black box, so you won't be able to do any symbolic manipulation. If you want that, you'll need a pre-processing stage that parses and does the symbolic manipulation.

[*] I say "should work", but there'll probably be bugs to work out.

[tshort]

If you really want Julia code (Modia or MTK for example), here's a plan that eventually might work with WebAssembly:

• Use JuliaSyntax.jl to compile Julia text.
• Use still-not-written Julia code to lower that to IR.
• Process that with Modia/MTK or whatever that uses Symbolics.jl. (I'm fuzzy on how realistic this step is.)
• Output Symbolics.jl results to JavaScript or (harder) to WebAssembly.

This path has all kinds of pitfalls, and you might need to rewrite parts of it to make it amenable to static compilation. It would need lots of enhancements to WebAssemblyCompiler (for string processing as just one example).

[HildingElmqvist]

We would like to utilize the Julia run-time to for example handle matrix equations, etc., so using Javascript evaluation would not be optimal.

Background on need: I was inspired by a presentation at the recent Modelica Conference about physiology modeling and simulation: https://www.conftool.com/modelica2023/index.php?page=browseSessions&search=kulhanek Small latency and real-time execution is then needed and model execution is performed in the browser using emscripten technology.

I have also seen some recent reporting, "Julia in WebAssembly": https://dspace.mit.edu/handle/1721.1/150151

[tshort]

As far as I can tell, Kulhanek et al. (2023) are doing much the same thing as this example. A model/FMU is compiled ahead of time, and the browser is used to adjust inputs, run the compiled model, and plot results.

It should be possible to compile several building blocks that a user could mix and match and connect together. Then, the combined system could be solved via co-simulation (having a master solver might also be possible, but it sounds trickier).

[HildingElmqvist]

Yes, I agree that I was talking about a more flexible use case than Kulhanek et al..

Anyway, I will close the Issue now. Thanks for sharing your insights and feedback, Tom.