DidierMurilloF / FielDHub

FielDHub is an R Shiny design of experiments (DOE) app that aids in the creation of traditional, unreplicated, augmented and partially replicated (p-rep) designs applied to agriculture, plant breeding, forestry, animal and biological sciences.
https://didiermurillof.github.io/FielDHub/
Other
39 stars 20 forks source link

Checks argument #9

Closed Prof-ThiagoOliveira closed 3 years ago

Prof-ThiagoOliveira commented 3 years ago

Dear authors,

I know we can use checks/tester to determine the effectiveness of manipulation in an experimental design related to social/medial science. Furthermore, checks can also be used in agriculture (mainly in genetics) and generally are commercial varieties because you know their characteristics and associated parameters.

You defined checks as an integer number of genotypes checks or a numeric vector. This argument definition is a bit confusing to me. Firstly, what do you mean by a numeric vector? What happens when end-users include a numeric vector there? I suggest you re-write this argument explaining to the end-user all the details, not just part of them.

Another point is in the Shiny App. Why did you decide to work with percentage for checks? Why you restricted this percentage to vary from 6.67 to 10%? It is not clear what is the difference between %Checks and Input # of checks. Alternatively, could you describe each shiny input in the dashboard?

DidierMurilloF commented 3 years ago

Dear Thiago Oliveira,

We will provide a better explanation of your questions here. First, the reason why we consider the number of checks as an integer is to define the number of genotypes that are being used in the experiment (i.e. 4 genotypes of the total will be checks) and also the Entry numbers for each. For example, if checks = 4 (integer number), we have four checks, and the function diagonal_arrangement() is going to assign 1 2 3 4 as entry numbers for each. In another case, users might want to customize entries for their checks just like checks = c(297,298,299,300), which implies there are 4 checks but now the Entry numbers for each are 297 298 299 300. In that case, the input was a numeric vector.

In our app, the first four entry numbers will be represented by check or control genotypes. Regarding the percentage of checks and the reason behind why this percentage is restricted is because of the dimension the user will use in the field. We want to provide flexibility to the user to define how many columns and rows they can put in the field and the percentage of check plots in the field will be based on the total amount of entries that are being tested and the number of checks the user is utilizing. Also, breeders usually allocate amounts of plot checks equivalent to 8%, 10%, or 12 % of the total available plots. That is why we fixed the percentage of checks approximately between 6% and 20%.

I hope this can answer your questions.

Best regards,

Didier murillo

DidierMurilloF commented 3 years ago

I know that non-replicated designs can be complex and not very common. But, the truth is that they are very used and useful when you want to test a large number of varieties with restricted quantities of seed, or physical resources. Please, let me share with you a key article in this area.
Clarke, G. P. Y., & Stefanova, K. T. (2011). Optimal design for early-generation plant breeding trials with unreplicated or partially replicated test lines. Australian & New Zealand Journal of Statistics, 53(4), 461–480.

https://onlinelibrary.wiley.com/doi/full/10.1111/j.1467-842X.2011.00642.x

Thanks,

Didier Murillo

Prof-ThiagoOliveira commented 3 years ago

@DidierMurilloF Thank you for your explanation. This now makes sense to me. Perhaps, reformulate the description of this argument. What do you think?

I'll read this reference. I agree with you about the complexities of those experiments, which is exactly why the idea of this package is so important. Best wishes,

Prof-ThiagoOliveira commented 3 years ago

Solved.

DidierMurilloF commented 3 years ago

@Prof-ThiagoOliveira Thank you for seeing the value of this work, especially since there are no packages in R to design these types of experiments.

I'm going to rephrase the description of the input checks. I think I should include more details. Thank you!