configuration file might confuse users due to implicit settings

[dneise]

I believe, there is a source of confusion in the design of handling the configuration of the telescope simulation, that could be solved by dropping a feature or two.

Problem description

In the current design, the user does not have to explicitly state all parameters, that are needed to specify the behavior of the tasks that form the entirety of our telescope simulation. Instead she might omit parameters, because she can be sure that missing parameters are set to some default parameters she finds suitable.

If the defaults are changed, without here knowing about, she has a problem.

If she gives the configuration file to somebody who doesn't know about all defaults of the task, the person does not understand what she intended with that specific version of the configuration file. So in order to explain her intentions to her colleagues, she puts comments into the configuration file, that state the value of the default parameters for the interested reader. While her intentions are certainly noble, the outcome is even worse, because now somebody might accidentally change a comment in the configuration file and thus creating lies in the configuration file, lurking in the dark and waiting to confuse the next reader.

I think, one virtue of scientists should be to be very specific in their discussions. Since the configuration file of the telescope simulation has been topic of long discussions, and certainly will be in the future, it should be very explicit and specific.

Proposal

A way to overcome this problem, would be to request full specification of simulation tasks in the configuration file and abort the simulation in case of unspecified settings.

There are many examples, e.g. the simulation of the atmosphere, implemented in the task called MSimAtmosphere. This task reads some parameters from two files, this fact is entirely hidden from the user (let alone that she can't even change the file paths via the configuration file).

[tbretz]

You are mixing two things.

One thing is that every task should produce some reasonable outcome independent of a configuration file, because you can use them in macros without any configuration file as well. Another one is that a novice might want to run a program just to understand how to run it without bothering about a configuration file. So have default configurations is essential. if you force every resource to be specified, some tasks would need 50 lines for initialization although the default is perfect for 99% of all cases.

It also introduces backward compatibility because if you add a new configuration parameter, not every existing resource file needs to be updated. This is usually an advantage not a disadvantage.

If you want to be sure that the scenario describes by you doesn't happen, you have to ensure that people write complete resource files and not change the code or the requirements on the resource file.

If you force every possible resource to be given in the resource file, in the worst case you will end up with thousans of resources not even slightly linked to your physics problem because they deal with the output on the screen or other unimportant details.

About the MSimAtmosphere... all those tasks were written with a lack of time... so if you want to add more resources to the tasks to improve flexibility you are invited to do so. However, those files you refer to were never meant to be changed (at the time the code was produced) and it was intentional that you can NOT change it to ensure that nobody changes them by chance and produces wrong results.

Nothing is hidden from the user here, you could only argue that the documentation is not complete enough. Since you seem to have understood the details already, you are invited to write the corresponding documentation.

A better approach than what you propose is to
1) Choose the default values carefully so that they fit most of the cases
2) Communicate changes of the defaults (this of course only makes sense if more than one person is really using the code)
3) Ensure good documentation
4) Make sure that when you send a configuration file either the SVN version number is to which version it corresponds to is added as well or all variables are properly listed there

Your approach seems to solve a problem which appeared in the past, but creates a lot of new problems in the future for other people with a different use case. I am against changing a policy which now exists since over ten years in all existing programs.

[Daniela Dorner]

Isn't also the configuration printed to the logfile when the programm/macro is executed? Or at least there is the option to do so - so I would suggest to use this feature and write logfiles to have always clear knowledge of the configuration and with this reproducibility.