Add Flystem Cells - #220
Conversation
…ty population now falls back to basal growth rate. Flattens nested frowth rate conditional into else-if chain.
… needed for ABM-like growth)
…degrees in line with experimental data
…division axis is rotating, defaults to apical axis but can be previous division instead
…t to move according to user specification
…oliferationModule and reference it instead of cell-specific critical volume for growth regulation math
…ns with deterministic division always yield a NB and a GMC
kristaphommatha
left a comment
There was a problem hiding this comment.
Look great so far! I looked over all the files except for the proliferation module and proliferation module tests, and had a couple of points of confusion for the files I did review!
I'll plan to come back and review the proliferation module and tests within the next couple of days! 🫡
| import arcade.core.util.MiniBox; | ||
| import arcade.core.util.Parameters; | ||
| import arcade.potts.util.PottsEnums.Phase; | ||
| import arcade.potts.util.PottsEnums.Region; |
There was a problem hiding this comment.
I see right below these lines there is the exact same import, except static. Why were these non-static imports added/ what is the difference between the static/non-static imports?
| case "fly-stem-wt": | ||
| return new PottsCellFlyStem(this, location, parameters, links); | ||
| case "fly-stem-mudmut": | ||
| return new PottsCellFlyStem(this, location, parameters, links); |
There was a problem hiding this comment.
I know that in the PottsCellFlyStem constructor, mudmut and wt cells have a different stemType code that differentiates them. This comment might be nitpicky, but without that context, this implementation could be confusing because it looks like both cases act the exact same way.
Is there a way to specify in the constructor call that you are creating a mudmut or wt cell?
| PottsCellContainer container, Location location, Parameters parameters, GrabBag links) { | ||
| super(container, location, parameters, links); | ||
|
|
||
| if (module != null) { |
There was a problem hiding this comment.
What is the reasoning behind this check?
From the setStateModule method, I assume that the only module that isn't null is proliferation. I'm just curious about why is it important that the state is undefined instead of proliferative?
| PottsCellContainer container = | ||
| new PottsCellContainer( | ||
| randomIntBetween(1, 10), | ||
| randomIntBetween(1, 10), |
There was a problem hiding this comment.
This might be really nitpicky and not even matter, but would there be any unexpected behavior if cellID and the parentID were the same?
|
|
||
| int cellPop = randomIntBetween(1, 10); | ||
| MiniBox parameters = new MiniBox(); | ||
| parameters.put("CLASS", "fly-stem-mudmut"); |
There was a problem hiding this comment.
I feel like because of the way the PottsCellFlyStem constructor is implemented, this test and the one above are virtually the same.
I'm not sure if you need both tests here if the class difference between fly-stem-wt and fly-stem-mudmut is tested already in the constructor_validWTStemType_createsInstance() and constructor_validMUDMUTStemType_createsInstance() tests under PottsCellFlyStemTest. I could be wrong though and would love to talk about this more
| PottsCellContainer container = | ||
| cell.make(cellID, State.PROLIFERATIVE, random, cellPop, cellCriticalVolume); | ||
|
|
||
| assertAll( |
There was a problem hiding this comment.
Would make on fly-stem-mudmut and fly-stem-wt cells create containers with the exact same parameters?
Estimated time to review: Large (sorry)
Summary of changes:
This code adds the fly neuroblast code into the codebase. The changes include:
How to verify changes:
resolves #137
resolves #109
resolves #91
resolves #58
resolves #50