Should sparta warn when setting hidden parameters with -p?

[MichaelSchoenfelder-SiV]

It seems that hidden parameters are most often used for internally calculated values. However, the user is able to set a hidden parameter via -p. This has caused problems for internally calculated values since it confuses the model.

Some ideas:

1. Consider this an error condition. Perhaps override the error condition with a "I really know what I am doing flag"
2. Issue a warning

The same behavior would be good for --read-final-config, although this shouldn't normally happen since hidden params are not written to a final config.

[ghost]

Funny... I just ran into this case -- I forgot I hid a parameter and was confused why I couldn't set it. 😆

I think the error that the parameter "does not exist" is good... after all, the modeler doesn't want the user to know it exists; this is why they hid it. Providing an override to force these parameters visible can expose an unexpected side-effect that the modeler does not want. For that reason, I think I'll keep the design as it is.

[MichaelSchoenfelder-SiV]

I thought users could set a hidden parameter via -p. That's why I wrote this issue. Maybe the behavior has changed since I wrote the issue. I didn't run into the issue myself; I wrote it due to this private slack conversation

[kathlenehurt-sifive]

@MichaelSchoenfelder-SiV you are right - the user can set a hidden parameter. I agree that the behavior should be changed as Knute suggested. If I've made a parameter hidden, it means I don't want the user to know about or be able to override it.

[MichaelSchoenfelder-SiV]

@knute-sifive , I am confused by your comment "I think I'll keep the design as it is.". Are you saying that the design is to tell the user that the parameter doesn't exist, but we have a bug that allows the user to set that parameter?

Here's a clearer bug report: the user is able to set a hidden parameter via -p. This has caused problems for internally calculated values since it confuses the model.

Some ideas:

1. Consider this an error condition. Don't allow the user to set a hidden parameter.

2. Perhaps override the error condition with a "I really know what I am doing flag"

3. Issue a warning and set the parameter anyway.

From the conversation above, everyone wants idea #1. I agree, but I suggest that that the error should say that one can't set a hidden parameter. Many users are also model developers, so they can see the params in the code. This is what lead to this bug report. An error of "does not exist" may lead to confusion since the modeler can very well see that the parameter exists and may not have noticed that it is defined as hidden.