user defaults for parameters

[ischeider]

The issue #976 by @lauraengelhardt brought me to an idea, which I would like very much.

What if the defaults of parameters are not given in the code, but in a readable data file, maybe defaults.json?
Then there might be the systemwide defaults in a file which the user should not change, but if the user has a user_defaults.json file, (some of) these default parameters overwrite the systemwide parameters.

It is not the same as having a set of parameters in an extra file, which is then read by INCLUDES, since one cannot give the same parameter twice. However, defaults can be overwritten in the input file.

Of course this might lead to different results on different computers, so if a system test is run, there should probably be a flag --ignore_user_defaults to run the simulation with the systemwide defaults.

I can imagine that the changes in the code are vast, but IMHO this would reduce input file parameters a lot.

[maxfirmbach]

I like the idea in general and see the benefits for a wide range of users. Here's my "but" though: certain input parameters are highly problem dependent / specific, with a meaningful default value nearly impossible to specify. I know that currently we already set default values, but there are many input parameters where I don't like this feature at all.

I'm more in favor of actively reducing input parameters and use more robust algorithms / methods to make them superfluous e.g.:

----------------------------------------------------------------BINNING STRATEGY
BIN_SIZE_LOWER_BOUND                  0.25
DOMAINBOUNDINGBOX                     -0.1 -0.1 -0.3 5.1 2.5 0.1

Is a input section that I would like to just see gone for ever.

[sebproell]

I know that currently we already set default values, but there are many input parameters where I don't like this feature at all.

@maxfirmbach Let me reinforce that a lot of the defaults that we have in today's input file were born from the severely limited input features we had before InputSpec. Every parameter needed a default regardless of whether it makes any sense (thus, the many -1, 0 etc defaults).

I think that much of the weirdness would go away if we simply started removing questionable defaults and forced users to set the parameters that cannot reasonably be defaulted. Basically this:

I'm more in favor of actively reducing input parameters and use more robust algorithms / methods to make them superfluous

[maxfirmbach]

@sebproell Right, I think we are definitely going in the right direction with 4C. I also didn't want to sound too negative with my comment 😅. @ischeider I still (of course) support any effort to make input file and usage of 4C easier.

[sebproell]

Maybe I have not fully understood the proposal. From what I believe to understand, this would essentially open up a new layer of input, namely the default parameter file. Wouldn't we run into the same trap of hard-to-coordinate changes that we already have with the existing input file? We want to start upgrading input files and if we also have to adapt the default files of users, this is going to be more difficult. So I would like to better understand what problem is solved first.

@ischeider, You laid out a possible implementation, but I don't understand the motivation for the change. Could you maybe sketch an exemplary workflow where this is useful?

[ischeider]

Let me first emphasize that it's only a convenience feature.

Sometimes we discuss changing defaults to more reasonable values. What is "reasonable" of course depends strongly on the user and the application, see, e.g., #590 , #976. So if we have a default parameter file, and somebody usually has a specific problem type, for which a set of parameters are always used with the same values, it makes sense to define defaults for these (which can then be overwritten in the concrete input file). Thus, moving defaults to some file opens up the opportunity to have a user_default_parameters file. Actually we could introduce the user_default_parameters even without moving the system-wide defaults to a file, if you want to keep the structure as it is.

The output issue #976 is IMO the best example for the benefit of user defaults, but changing the default INT_STRATEGY or the LINEAR_SOLVER (including the SOLVER 1 section) would be on my list as well.

[isteinbrecher]

@ischeider why can't you simply define a default parameter file (*.4C.yaml) and then read that into FourCIPP before adding your custom parameters?

[ischeider]

@isteinbrecher Thanks for the suggestion - now I was forced to investigate some time in fourcipp ;-) In general you're right, one can read in two input files. However, (1) it is AFAIK cumbersome to combine two inputfiles that may have common sections with different values, where one has to select one of them (the routines are not yet there), and (2) one has to write a new input file or overwrite the input file with the one including the defaults (which is not what I would like).

If we had a default mechanism within 4C, the defaults would be included automatically and the input file wouldn't be touched.

Anyway, if nobody else finds it useful, maybe it isn't. From @isteinbrecher 's suggestion I now built a wrapper which does the trick. @gilrrei Of course, I could provide a function include_defaults (can also be named overwrite_values to distinguish from overwrite_sections)

[mayrmt]

@ischeider, thanks for bringing up this topic! I can see use cases and the value of having "my own set of default parameters" that overwrite global default parameters. My possible use case: I'd use this feature for example to turn off visualization output of any field by default or turn on detailed linear solver output by default.

I am not sure about the technical realization, so I can't say anything to it at the moment.