[ENHANCEMENT] where to set cutoff, gain_scale_factor and up?

[raoulcollenteur]

Describe the proposed enhancement

After the change to only allow instances of response functions, a user can set the gain_scale_factor, up, and cutoff in two places: ps.Gamma(arg=arg) or ps.StressModel(ps.Gamma(), arg=arg). The args given to StressModel will override those from the response function. I don't think this is the desired behaviour.

• So to start, I would propose to remove the cutoff argument from the StressModels and only allow setting this parameter when creating a response function instance.
• For up, intuitively I think it makes more sense to set this at the rfunc instance level and looking at the code I can only see a few small changes for WellModel required, which has up=True by default.
• For gain_scale_factor, this depends on the stress and I think it makes sense to set this through the StressModel and keep this as is. However, for this argument, only the StressModel actually allows setting it and all other stressmodels set this values internally, which is also not what we want I think. Here I prefer the StressModel behaviour, only using stress.std() if no gain_scale_factor is provided.

[mbakker7]

My thoughts:

1. cutoff is set in the rfunc only. So I agree.
2. up should be set by the stress model. Only the stress model knows whether a positive stress should create a rise or decline of the head. So we need a set_up function for response functions.
3. meanstress should be set by the stress model. Again because only the stress model knows that value. So here I agree again.

[raoulcollenteur]

I addressed this issue and implemented the changes as commented by @mbakker7 in PR #491 .

[raoulcollenteur]

Changes made. The new place to set cutoff is at the response function level. The other two arguments are still provided at the stressmodel level. For the gain_scale_factor, it should be noted that all stressmodels set these internally, except for StressModel, and cannot be set by the user. Whether or not that is desired behaviour could be another issue in the future.

Closing this issue now, as PR #491 has been merged and addressed this.