Where should we create virgin queens?

[gregorgorjanc]

I have been trying to understand where should we really create virgin queens. At the moment we create ONE virgin queen when we create colony. Then, whenever we do something with the queen and virgin queens, we make sure we create a new ONE. Etc.

As I mentioned, with an active csd locus, this ONE virgin queen might be homozygous, which means we don't add her. So, we need another solution. A simple way is to bump the number of virgin queens (say 20 to 40), so we get at least ONE, but this will eventually fail - imagine a case with very high csd inbreeding. Should we then collapse the colony at that point? Or do we just rely on a "beekeeper" to add a virgin or a mated queen? We need to be able to catch such cases though - is this another event that we should store in a slot or at least have a function hasQueens() that checks if the queen or virgin queens are present - hmm, we have isQueenPresent() and I have now extended it so we could test for virgin queens with isQueenPresent(x, virginQueens = TRUE) (x can be Colony or Colonies).

Back to where we should create virgin queens. I have drawn a diagram of all the events that we cater for and what happens to the castes in these events according to my understanding from @JerBub explanations. In the diagram I am pivoting to creating virgin queens in buildUpColony() only - this would make it cleaner with respect to passing nVirginQueens argument just in one function (apart from createVirginQueens() and addVirginQueens()) - at the moment we would have to pass the nVirginQueens argument in createColony(), crossColony(), and swarmColony() Can you guys have a look at the diagram at some point and check if things make sense?

@LStrachan it would be great if you could produce a better quality version of this. It could be useful in publications!

The diagram also raised some questions - I have written them down - can you guys address them?

We also need to think at some point what to do with the 5 cases in relation to buildUpColony(). It seems to me that buildUpColony() would either have to:

1. change numbers/proportions depending on what happened before (such a code could get ugly and hard to follow) or
2. always add a totally new batch of workers, drones, and virgin queens (we can do this with buildUpColony(..., new = TRUE))

AND, this is important, at the moment by default buildUpColony() and buildUpColonies() only ADDS workers and drones on top of existing workers and drones (via addWorkers() and addDrones()). This means we could be stuck with workers and drones that are several year old! This will impact WCGALP paper! Aha, I see we call replaceDronesColonies(), ok, this is then a silent alarm then, but shows that maybe by default buildUpColony() and buildUpColonies() should have new = TRUE?

@JerBub @LStrachan @janaobsteter

[gregorgorjanc]

I have now implemented this scheme in the devel branch of SIMplyBee and the devel branch of lstrachan_honeybee_sim.

I just gave you access to https://github.com/gregorgorjanc/SIMplyBee - I don't want to push just yet to the main repository since this is a work in progress. You can get these by:

git clone https://github.com/gregorgorjanc/SIMplyBee.git
cd SIMplyBee
git checkout devel
git branch

git clone https://github.com/HighlanderLab/lstrachan_honeybee_sim.git
cd lstrachan_honeybee_sim
git checkout devel
git branch

I am struggling though with this version, even without the csd! I somehow keep loosing one virgin queen somewhere and when I come to crossing colony I don't have the virgin queen there :( I also sometimes get an error that we are combining two colonies with the same name in the Colonies, which is now not allowed.

Would anyone care help me to debug this?

@janaobsteter @JerBub @LStrachan

[gregorgorjanc]

OK, solved both problems - latest commit is https://github.com/HighlanderLab/lstrachan_honeybee_sim/commit/e70e11d0433f9ea7cef14850ec5796993e8e99db

To explain what happened:

1. I went and used getVirginQueens(donorColony-from-age1) and later on one of these virgin queens became the queen of a colony and that colony was combined into age1, which threw an error. I have now used pullVirginQueens(donorColony-from-age1) to ensure we don't get such cases.

2. For the lack of virgin queens, the current devel changes mean that after swarming the swarm does not have a virgin queen (case 1) above. So, I have added buildUpColonies() for all swarms, but we need to discuss if this is sensible or not - maybe we need to add only virgin queens?

I will now explore csd behaviour with this system

[gregorgorjanc]

From @JerBub "I found another problem with csd and virgin queens. You fix it with build up colony but that works only in P1. We don't have build up colony function in P2 but we have swarming and supersedure. I think that we need function create virgin queens that would create specified number of them regardless of csd problems and would be also implemented in swarm and supersedure functions."

GG: So, if I understand correctly, you're saying that after swarming in P2 the colony does not go through build up (case 1 in the above diagram), because it's too late?, but it only creates new virgin queens from existing larvae, right? A way to do this in SIMplyBee would be to add one of the following options in the swarm function:

1. Pull nVirginQueens workers and assign them as virgin queens. This could impact say honey production down the line since we likely won't be able to simulate x10K workers per colony - so, if we say simulate 100 or so workers per colony, then pulling ~30 nVirginQueens is a lot. We could pull just one worker too - she will be heterozygous anyway. 1 out of ~100 is not massive, but it can impact a colony for 1% honey yield if we make honey yield a function of colony strength. These small percentages build up quickly in quantitative genetics.
2. Other alternative is to generate nVirginQueens from the queen before swarming (just technically, I know this happens after swarming!, but it would have to be done before while we still have the queen because we are not simulating brood - maybe we should?) and we can, say double the number to ~60 to counteract csd? This counteracting would be needed since a colony will always have ~10K of larvae (it has to be of this order of magnitude), so there is always some chance to raise at least one queen.
3. Related to 2. we could make as many crosses between the queen and drones to ensure at least one virgin queen. The queen has to be heterozygous, so even if we she would be mating with her own drones, she has 50% chance to generate heterozygous virgin queens - so, theoretically the worst pHomBrood is 50%. I think the following should work well - generate the standard number of virgin queens, if that gives us 0 viable virgin queens, try again with another set (this doubles our chance to get viable larvae), if it fails again, then we collapse the colony? We could make the number of repeats as an argument to provide maximum flexibility.

Should we do the same with the supersedure too?

[gregorgorjanc]

From @janaobsteter: "Could the solution be "copying" a set to workers? Or would that mess up the IDs somewhere?"

Yeah, SP@lastId tracks ids, BUT, workers are a reproductive dead end, so this could indeed be a very simple trick! So, in swarm and supersede functions we simply copy workers into virgin queens? Wait, do we then need addViringQueens() etc. at all?

[gregorgorjanc]

From @janaobsteter: "We probably still need the function in case someone wants to add them in (for example for queen rearing). But the question is how should this function work? Copy or make new ones? What is there is not workers there (don't know why, but perhaps there is a case)?

Copy from workers if they are there and create otherwise?"

Something like this. The other case, where there are no workers, will have the same csd issues as mentioned above;) Lets revisit this in 2022:)

[gregorgorjanc]

As discussed today we should create virgin queens during:

1) Swarming 2) Supersedure 3) Split, but if a user later requeens the split colony, we kill all virgin queens

So we modify the buildUpColony() (which at the moment creates virgin queens as a temporary solution - in the devel branch), swarmColony(), supersedeColony(), and splitColony(), which will all create an exact number of virgin queens using the exact argument from #113

[gregorgorjanc]

Addressed in https://github.com/HighlanderLab/SIMplyBee/pull/116/commits/078be79f675ed9c1c3678ce7f093f5e18da56212, https://github.com/HighlanderLab/SIMplyBee/pull/116/commits/7b902edfb7e4531fcd353ecfca4a9ef9628e0962, https://github.com/HighlanderLab/SIMplyBee/pull/116/commits/b5a7281145947888a5afdd77361afeb110517b22, and https://github.com/HighlanderLab/SIMplyBee/pull/116/commits/beea8fcbfe73011fec1803de18197d1e84449e6f.

This implementation will fail due to csd homozygosity, so I will leave this issue open until we get the exact argument for createViringQueens #113 sorted @janaobsteter

[janaobsteter]

The exact issue is now solved - so if we have moved the creation of virgin queens to swarming and supersedure, this issue can be closed.

[gregorgorjanc]

We think this is now all done. Hopefully!