Issue with SCOPE recognizing a varying LIDFb parameter

[richardsonwillp]

I've recently been running some sensitivity analyses of SCOPE, primarily in the context of simulating a rice canopy, which tends to have an erectophile leaf angle distribution (i.e., LIDFa = -1). I wanted to vary the LIDFb parameter because deviation from pure erectophile behavior is expected and may change with the status of the crop. However, when supplying the complete set of parameters in my sensitivity analysis, all parameter values were respected and used EXCEPT for LIDFb. Indeed, despite the LIDFb value being supplied and changing, the "pars_and_input_short.csv" file does not show LIDFb as being a parameter that varied, and the result of each simulation in which LIDFb was supposed to vary was identical.

Upon further investigation, the program was considering LIDFb to be 0 in every simulation. The only way that SCOPE would recognize non-constant LIDFb values was to also provide an explicit value for LIDFa in every simulation, even though it was being fixed at -1. This got SCOPE to recognize the different desired LIDFb values, but in the "pars_and_input_short.csv" file, it supplies a column for LIDFa instead of LIDFb, despite the fact that LIDFa was constant and LIDFb was changing.

I have a workaround for the time being, but it would be nice to know the deeper cause of/reason for this behavior and to have "pars_and_input_short.csv" files that contain the actual parameters that varied in order to better document my work.

Thank you

[Prikaziuk]

Dear Will,

Thank you for your request and apologies for the late reply.

There is an additional constraint on LIDFa and LIDFb values:

• abs(LIDFa + LIDFb) <= 0

So, if you are targeting the erectophile leaf distribution, LIDFb must be 0.

Usually for sensitivity we sample

• LIDFa_proxy = LIDFa + LIDFb
• LIDFb_proxy = LIDFa - LIDFb
  , varying those proxies from -1 to 1.

From proxies, we compute LIDFa and LIDFb.

Regarding the bug, indeed, LIDFb value IS used as you provide it in time-series but IS NOT output to pars_and_inputs_short.csv. This has to do with the "feature" of selecting LIDFb with indices of LIDFa (L53 of select_input.m). I see your point of better documenting the work. We will think about correcting it.

Best regards,
Egor