From: Jonathan C. <jon...@cs...> - 2012-02-08 10:34:51
|
Hi Richard, Two quick points on your very thorough email, responding inline. On 07/02/2012 23:52, Richard Adams wrote: > I agree with Jonathan on this - if a nested simulation can handle a > uniform time course, by specifying the range to use 'time' as a > target, why not go the whole hog and get rid of UniformTimeCourse? The > concept in l1v1 of a task relating a simulation and a model, while > elegant, seems rather obsolete by this proposal. I don't think I'd get rid of UniformTimeCourse entirely, since it's a simulation type that occurs very frequently, and so it's useful to be able to specify it directly (and keep backwards compatibility more easily). But the spec could describe how it can be implemented in terms of a nested simulation, so implementers only really need to care about the latter if they want to. I do like your example though. > One other suggestion: in the current nestedSimulations, inner loops > are not reusable - they are defined with respect to the outer > simulations. How about > being able to define 1D parameter scans independently, which could be > combined together simply, e.g., > > <nestedSimulationTask> > <simulationTaskRef refid="paramscan1"/> > <simulationTaskRef refid="paramscan2"/> > </nestedSimulationTask> > > indicating a combination of two tasks to produce a 2D scan? I.e., > each task is defined 'one-dimensionally' but can be composed into N- > dimensional simulations by linear combination. This has the potential to be really nice, but the proposed approach is conceptually clunky I think. What it implies is that one of the referenced tasks (the first?) has to be modified so that instead of the original task specified in it, it uses the other referenced task. A cleaner way to do it would be to allow simulation tasks to be parameterised by the original task - these would then be more reusable components that could either be applied just to a model, or nested together. Best wishes, Jonathan |