This reminds me of a question Trixi.jl, which is also a simulation package, faced several years ago. Back in the beginning of Trixi.jl, input parameters were stored in .toml files. However, this turned out to be unhandy, error-prone, and not flexible enough. Think, e.g., of the case where an input “parameter” is a function, e.g., an initial condition. It’s much easier to provide this as a Julia function. So a question you could ask yourself: Do I really need to rely on text files as input files or could I also use Julia scripts as the main entry point to your program? If your main entry point is a Julia script, you already have access to num1, num2 etc. This does not mean that structuring the input parameters into logical entities isn’t helpful anymore. It could still make sense to bundle them into a struct or similar. Depending on your application it might also make sense to bundle different sets of parameters together rather than every parameters into one data structure. For instance, some parameters could be physical parameters, which would make sense to bundle together and others could be solver related and so on. This could additionally help you organizing the parameters. Once you have (a) datastructure(s) with your parameter, I agree with @JonasWickman that destructuring syntax can be helpful for cleaner computations.
6 Likes