Ensure GUIDRAT is checked when WGRUPCON value is defaulted

[vkip]

No description provided.

[bska]

The fall-back to GUIDERAT for defaulted WGRUPCON is okay. I am however not very excited about the new getPotential() function. Potential flow rates are supposed to be an internal implementation detail in the GuideRate class. Can you not use potential rates available elsewhere?

[vkip]

The fall-back to GUIDERAT for defaulted WGRUPCON is okay. I am however not very excited about the new getPotential() function. Potential flow rates are supposed to be an internal implementation detail in the GuideRate class. Can you not use potential rates available elsewhere?

As far as I know, not without something that seems like unnecessary code duplication. It is the potentials at the times guide rates are updated that I'm after, so appears it would require communicating potentials and storing them somewhere else, with very similar setup as for the current guiderates. If you have other ideas, please feel free to point me in the right direction and I'll have a go.

[bska]

It is the potentials at the times guide rates are updated that I'm after

Okay, understood. The contents of GuideRate::potentials are updated on every call to GuideRate::compute(wgname) which, very strictly speaking, could be more frequently than when we actually update the guide rates. The latter depends on the delay setting in item 1 of the GUIDERAT keyword. Depending on your point of view, updating the stored potentials more frequently than the guide rates might even be a bug.

In any case, I really don't like the idea of client code starting to depend on the fact that we have some version of some potential rates stored inside the GuideRate object. I suppose if we give the function a threatening name like latestGuideratePotentialsFor(wgname) then that might abate the risk slightly. Even then, I would really prefer that this coupling not become widespread.

[vkip]

It is the potentials at the times guide rates are updated that I'm after

Depending on your point of view, updating the stored potentials more frequently than the guide rates might even be a bug.

Good point, and that can surely be discussed, but for consistency with what's currently being done for entities where no guide rate value is found I think we should stick to returning the most recent potential (was just a bit imprecise above since I didn't think of this issue...)

In any case, I really don't like the idea of client code starting to depend on the fact that we have some version of some potential rates stored inside the GuideRate object. I suppose if we give the function a threatening name like latestGuideratePotentialsFor(wgname) then that might abate the risk slightly.

Another option could be to propagate always_use_potentials with default false to the GuideRate::get function - would that be better?