KCL data parameter imports

[adamchalmers]

Our customers might have a parametric KCL design -- e.g. a fn wheel(diameter, thickness, numBolts). What specific parameters should they use?

This is usually answered by analysis software. Right now, the engineers have to:

1. Instantiate a specific wheel like myWheel = wheel(diameter = 2.1cm, height = 13mm, numHoles = 4)
2. Export it as wheel.step
3. Import that into their analysis software
4. Record its measurement
5. Loop back to step 1, tweaking the values of diameter = 2.1cm to diameter = 2.2cm.
6. Repeat until the value in (4) is good enough

This could be automated. Imagine if you could read KCL constants from an external file. Imagine you've got data.csv and want to load it into KCL. You'd make a KCL object which wraps the data source, then read data properties from it. Something like this:

params = load("wheelParams")
diameter = params.distance("radius") * 2
myWheel = wheel(diameter, height = params.distance("height"), numHoles = params.count("numHoles"))

This defines a data source named "wheelParams". Now the user chooses what file supplies that data. They either edit projects.toml by hand, or a ZDS UI updates it, adding

[datasources]
wheelParams = "data.csv"

In ZDS, users can see data.csv in the file explorer, next to main.kcl. Maybe the user dragged and dropped it in there themselves, or used their OS file explorer to put it there. The KCL interpreter, before it starts executing the program, reads the data sources and gets data from them. We'd support .csv, .json, .yaml, etc. We could also use another KCL module as this datasource, e.g.wheelParams=constants.kcl, because that's a common pattern I've seen our mechanical engineers use.

As a nice-to-have, we'd let the Zoo CLI override the values in project.toml, so you could do zoo kcl export main.kcl wheel.step --datasource wheelParams=new_data.csv instead.

Details

We'd define a KCL Datasource interface, which defines a common data model (an interface). It has two parts:

1. How to read data from files (.csv, .json, .yaml, or whatever format customers need) into this interface
2. How to get KCL constants (distances, angles, general numbers, booleans, etc) out of this interface

This way users can write the KCL file once, and rerun it with different specific parameters given by the environment. This decouples KCL, which defines a general parametric design, from the specific parameters chosen for a given model instantiation. Now users who don't know anything about KCL can treat ZDS or Zoo's CLI as a black box, and just tweak the parameters.csv, run the export, pipe it into their modeling software, look at the outputs, and tweak the parameters again

We'd probably support defaults, like params.distance("radius", default = 20mm). That way it's still easy to do everything in one copy-pastable main.kcl file. But it also lets other tools override the chosen constants and modify them in an edit-export-simulate loop.

Alternatives

• Tools could read main.kcl and look for a named constant like radius = 3cm and override it by editing the text
• Instead of params = load("wheelParams") we could use import statements, like import datasource wheelParams as params