sorainsm
commented
5 years ago Similarly I think that the binding times of your outputs should be changed to compile time. From my understanding labeling something as a run-time binding means that the decision about it will only be made at run time. For example, the "destination for output" variability being run time means the user needs to specify to the program as input the option of either file, screen, or memory.
I think that some of these are appropriate to be run time decisions (e.g. fluid characteristics), but that things like the encoding of the output, or the graphical model should be selected by you at compile time so as to refine the scope of your family better.
peter-michalski
@peter-michalski I think that the binding times of your input variabilities could use tweaking.
From my understanding of reading your document, many of the things you have listed as "scope time" bindings should really be compile time or run time bindings. The velocity, time, position vector, and others all seem like they are inputs a user would feed to the system in order for it solver to produce a model. By listing them as scope time variables you're saying that you have made a decision that your family of solvers only deals with problems that have one specific set of velocities bound at scope time (e.g. Set R : e > 0). From what's written here it seems like you would like for some of these things to be freely passed in by the end user.
I have highlighted in pink which variabilities I think would be better suited to run-time binding. Yellow highlights indicate what I think would be compile time bindings.