You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wonder if it would make sense to restructure the way we select options for sinking speed and aggregation.
At the moment we have three logical switches USE_WLIN, USE_AGG and USE_M4AGO, of which only one should be .true., i.e. 4 options if we include the option that all of these are .false.. We trust the user to know that only one of these options should be applied at a time, and I don't think we do much testing to see if this the case.
I propose to replace these logical switches with a string variable that can take values "WLIN", "AGG", "M4AGO" or "default" (i.e. if none of the first three applies). This would make it easier to control that only one sinking algorithm is applied. Does this make sense to you? Are there any pitfalls you foresee in implementing such a solution?
The text was updated successfully, but these errors were encountered:
I wonder if it would make sense to restructure the way we select options for sinking speed and aggregation.
At the moment we have three logical switches
USE_WLIN
,USE_AGG
andUSE_M4AGO
, of which only one should be.true.
, i.e. 4 options if we include the option that all of these are.false.
. We trust the user to know that only one of these options should be applied at a time, and I don't think we do much testing to see if this the case.I propose to replace these logical switches with a string variable that can take values "WLIN", "AGG", "M4AGO" or "default" (i.e. if none of the first three applies). This would make it easier to control that only one sinking algorithm is applied. Does this make sense to you? Are there any pitfalls you foresee in implementing such a solution?
The text was updated successfully, but these errors were encountered: