I have found a Vector Migration issue that affects default geographies.
Because I have removed Enable_Vector_Migration parameter (are internally setting it to "true"), when you use default geography aka "Enable_Demographics_Builtin" = 1,
the vectors always migrate, because the default geography builds its own migration rates internally.
In addition, none of the vectors are affected by x_Vector_Migration modifier, but female vectors ARE affected by the Vector_Migration_Modifier_Equation.
I have found a Vector Migration issue that affects default geographies.
Because I have removed Enable_Vector_Migration parameter (are internally setting it to "true"), when you use default geography aka "Enable_Demographics_Builtin" = 1,
the vectors always migrate, because the default geography builds its own migration rates internally.
In addition, none of the vectors are affected by x_Vector_Migration modifier, but female vectors ARE affected by the Vector_Migration_Modifier_Equation.
It's.. weird. I'm not sure what to do about this.
we could:
leave as-is vectors always migrate (not good 'cause it's done in secret/default and will mess up any vector control interventions when usig builtin)
turn off vector migration when default geography aka Enable_Demographics_Builtin = 1.
implement x_Vector_Migration for default geography and then x_Vector_Migration = 0 would be no migration UNLESS they are using Vector_Migration_Modifier_Equation and then we might still end up with female vectors migrating.
add Enable_Vector_Migration back in on per-species basis <--- personally this would be annoying from a supporting point of view because it would be the only enable parameter not on "parameters"/main level and that messes up how emod-api does things and we would have to add/massage/rewrite python supporting code (but maybe it won't be that hard, it just wasn't obvious when I looked at it last).
add Enable_Vector_Migration on the "parameters"/main level and then have whether or not Vector_Migration_Filename is present to control per-species migration. This might be similar amount of work to 3 because things are always complicated with EMOD.
none of the tests caught this because none of them check for absense of vector migration and vector migration in general doesn't affect things much when they are all flying from everywhere to everywhere at the same rate (which is what it does in default geography).
@Bridenbecker :
I recommend #0 - Leaving-as-is but writing a ticket. The last time I even worried about this was 5 years go when we were trying to do minimal configurations. Hence, it is not a well used configuration and not really worth us fixing. However, a ticket will at least document it as a known problem.
If anything, I'd prefer we rip out the built-in demographics feature. Now that we have emodpy, there really isn't a reason for built-in demographics. In fact, we have emodpy examples so no one really needs the built-in scenario anymore.
@pselvaraj87 :
Yeah, agree with Dan. I don't think I've used built in demographics. Thanks for finding the bug, though, Svetlana!
I have found a Vector Migration issue that affects default geographies. Because I have removed Enable_Vector_Migration parameter (are internally setting it to "true"), when you use default geography aka "Enable_Demographics_Builtin" = 1, the vectors always migrate, because the default geography builds its own migration rates internally. In addition, none of the vectors are affected by x_Vector_Migration modifier, but female vectors ARE affected by the Vector_Migration_Modifier_Equation.
I have found a Vector Migration issue that affects default geographies.
Because I have removed Enable_Vector_Migration parameter (are internally setting it to "true"), when you use default geography aka "Enable_Demographics_Builtin" = 1,
the vectors always migrate, because the default geography builds its own migration rates internally.
In addition, none of the vectors are affected by x_Vector_Migration modifier, but female vectors ARE affected by the Vector_Migration_Modifier_Equation.
It's.. weird. I'm not sure what to do about this.
we could:
leave as-is vectors always migrate (not good 'cause it's done in secret/default and will mess up any vector control interventions when usig builtin)
turn off vector migration when default geography aka Enable_Demographics_Builtin = 1.
implement x_Vector_Migration for default geography and then x_Vector_Migration = 0 would be no migration UNLESS they are using Vector_Migration_Modifier_Equation and then we might still end up with female vectors migrating.
add Enable_Vector_Migration back in on per-species basis <--- personally this would be annoying from a supporting point of view because it would be the only enable parameter not on "parameters"/main level and that messes up how emod-api does things and we would have to add/massage/rewrite python supporting code (but maybe it won't be that hard, it just wasn't obvious when I looked at it last).
add Enable_Vector_Migration on the "parameters"/main level and then have whether or not Vector_Migration_Filename is present to control per-species migration. This might be similar amount of work to 3 because things are always complicated with EMOD.
none of the tests caught this because none of them check for absense of vector migration and vector migration in general doesn't affect things much when they are all flying from everywhere to everywhere at the same rate (which is what it does in default geography).
@Bridenbecker : I recommend #0 - Leaving-as-is but writing a ticket. The last time I even worried about this was 5 years go when we were trying to do minimal configurations. Hence, it is not a well used configuration and not really worth us fixing. However, a ticket will at least document it as a known problem. If anything, I'd prefer we rip out the built-in demographics feature. Now that we have emodpy, there really isn't a reason for built-in demographics. In fact, we have emodpy examples so no one really needs the built-in scenario anymore.
@pselvaraj87 : Yeah, agree with Dan. I don't think I've used built in demographics. Thanks for finding the bug, though, Svetlana!