hiddenSymmetries
vmec_indata is not updated when updating VMEC boundary without calling set_indata()
When updating the boundary of a VMEC object, some derived properties that only depend on the boundary are not updated until set_indata() is run. A call to set_indata() typically happens when run() is called, so this is normally not an issue. However, if a user would call get_max_mn() after updating the boundary (for example, to manually update mpol and ntor to values tailored to the new boundary), get_max_mn() would not return values corresponding to the new boundary unless the user has manually run set_indata().
A simple solution is to run set_indata() at the end of the boundary setter. This is slightly suboptimal, as set_indata() currently updates boundary shapes, magnetic axis shapes, and profiles – not just the boundary. It'd also result in set_indata() being called twice for many typical use cases, as it is automatically called by get_input() during each invocation of run(). Specifically, run() calls write_input() which calls get_input() which calls set_indata().
The clean solution would be to have separate set_indata() functions for profiles, axis and boundary, and to call these in the corresponding setters to ensure that these input data are always consistent in the VMEC object and vmec_input. If this was done, there would be no need to call set_indata() during run(), since the vmec_data would already be updated.
An alternative solution would be to have a boolean similar toneed_to_run_code for need_to_set_indata. Or we just run set_indata() an extra time whenever we set profiles, boundaries or magnetic axis.
Thoughts?
EDIT:
On further inspection, it seems like get_max_mn() is one of the few instances where this is a problem. Since get_max_mn() is not called by any other code in the codebase, I just added a set_indata() call at the start of this function, since the performance hit should be minimal since this is a method that basically never gets used internally.
This behavior is implemented in PR #502 which would thus mostly close this issue.
