We'll change the way gradual rotations are applied. Instead of a fixed increase of 1 deg/trial always starting at 0 degrees, the user will set the starting angle and the final angle and the increase in deg/trial is then determined by the difference between those two angles and the number of trials.
Advantages:
we can have quicker and slower gradual rotations
we don't need to start at 0 degrees
Disadvantages:
it becomes a little harder for undergrads to understand the GUI
We try to solve the ease of use by hiding the features unless people want a gradual rotation. That is, by default there is only one angle to set. Only when you choose to tick the gradual option, a second slider appears. I've attached a little mock-up to show you what I mean:
Notice that I think we should show the absolute change in rotation per trial in the GUI.
There's another issue, that we have a solution for. If the user has 30 trial task and a start angle of 0 with a final angle of 30 degrees, the change in angle should be 1 deg/trial. If we then say the final trial should have 30 degrees, then the first trial has to have a 1 degree rotation, not 0, which might be expected. We could set the change per trial to be some floating point number (~1.0345 deg/trial) so that the first and last trial are exactly at 0 and 30 degrees. Or we could have the mismatch at the last trial: start at 0 and finish at 29 degrees. Either way, it will not fully match user expectations, but the last option has the advantages that the increase per trial makes sense, and that if you then do another task right after that has a constant rotation of 30 degrees, that task will have all the trials with the 30 degree rotation. It is also the pythonic way of generating a list/array:
So I want to go with that implementation, while realizing that it is not perfect and may need change in the future.
BTW: the PyVMEC should always store a start angle and a final angle, and nothing else. If those are the same, the above line should of course not be used, because you get a 0-division.
Julius: can you add the keys you will use in the JSONs to the google doc with the definition and remove the existing keys? That way everyone knows what to use.
We'll change the way gradual rotations are applied. Instead of a fixed increase of 1 deg/trial always starting at 0 degrees, the user will set the starting angle and the final angle and the increase in deg/trial is then determined by the difference between those two angles and the number of trials.
Advantages:
Disadvantages:
We try to solve the ease of use by hiding the features unless people want a gradual rotation. That is, by default there is only one angle to set. Only when you choose to tick the gradual option, a second slider appears. I've attached a little mock-up to show you what I mean:
PyVMEC_rotation_mockup.pdf
Notice that I think we should show the absolute change in rotation per trial in the GUI.
There's another issue, that we have a solution for. If the user has 30 trial task and a start angle of 0 with a final angle of 30 degrees, the change in angle should be 1 deg/trial. If we then say the final trial should have 30 degrees, then the first trial has to have a 1 degree rotation, not 0, which might be expected. We could set the change per trial to be some floating point number (~1.0345 deg/trial) so that the first and last trial are exactly at 0 and 30 degrees. Or we could have the mismatch at the last trial: start at 0 and finish at 29 degrees. Either way, it will not fully match user expectations, but the last option has the advantages that the increase per trial makes sense, and that if you then do another task right after that has a constant rotation of 30 degrees, that task will have all the trials with the 30 degree rotation. It is also the pythonic way of generating a list/array:
So I want to go with that implementation, while realizing that it is not perfect and may need change in the future.
BTW: the PyVMEC should always store a start angle and a final angle, and nothing else. If those are the same, the above line should of course not be used, because you get a 0-division.
Julius: can you add the keys you will use in the JSONs to the google doc with the definition and remove the existing keys? That way everyone knows what to use.