This feature request has been on my mind for a long time.
With the old NetLogo format, I thought it would be difficult to implement without breaking existing models / experiments. (In fact, that part was already in XML format.)
Recently, I stumbled on it again.
Sometimes, one would create an experiment to just collect data on initial configurations.
Then intiutively the time limit should be zero.
However, the experiment dialog of BehaviorSpace says “0 = no time limit”.
There is a work-aroung of course, but it always feels a bit clumsy. And the output file will still list one step.
Could you change the default time limit to -1 with help text “-1 = no time limit”?
The “no time limit” case is already stored as an absent time limit field in XML, so I expect this is trivial to implement. And no existing models and experiments will be broken.
I’m not entirely sure what the purpose of this kind of experiment would be. What new data is there to collect when you have to manually define the initial configuration in the “vary variables” field? But regardless, it sounds to me like your issue would be solved by not including any reporters in the metrics field.
Generally, it’s not good practice to implement something without understanding why it’s being done, even if it might seem harmless up front. Especially if it’s not a problem that has been reported in the past, getting a better understanding might reveal a more general problem hiding behind the surface-level problem. Also, I disagree that it’s a small change that does not break anything. Since the time limit is currently restricted at to a non-negative number, there could be sections of the code that only work under this assumption, so it would require careful review and testing of the entire BehaviorSpace workflow to ensure that nothing broke.
Thank you for the clarification. That makes sense.
I did not think of the possibility of other code assuming that the time limit is strictly positive.
So, it is less trivial than I thought.
I still have to check for the project(s) where we needed zero steps.
The key factor was that we gathered many outputs of the initial configuration (after Setup, for many parameter settings and random seeds), and then used another program to classify expected behavior. If I remember correctly there was a case of routing, where it made a huge difference whether paths of vehicles crossed or not. Then, we could do the real runs (with fewer outputs) on a selection of parameter settings.
The solution proposed by Seth above, though less intuitive, will work well for this kind of situation.
Thank you for the explanation, I think I have a potential solution now. Would it benefit you to be able to export a table with the fully generated set of parameter combinations and random seeds? That way, you could get easily parseable initial configuration data all in one place without needing to run the experiment. This is something that has been requested before, so it’s definitely something we would consider implementing if it would solve your problem. Unfortunately, I don’t think this would help if you need the ouptput of any actual NetLogo code that runs during the setup commands; it would just get you the expansion of the variables box.
Thank you, Isaac. That is indeed another use case for this feature.
I have had many students that needed something like this, and then we used the same work-around as for recording initial state.
Recording initial state does need NetLogo code (usually setup) to run before reporting any values. And these values are typically not parameters.
So, your proposal is very useful. Please provide this functionality.
Yet, it does not help for the original purpose.