lavinrp / eyedevelopmentmodel Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
Create a few tests with different types of cells surrounded by other types of cells.
Surround them with one or two layers.
This will be critical in debugging cell adhesion as we change it.
by using pickle to save our epithelium and simulation options we implicitly version lock things.
This can cause crashes or incorrect behavior if the saved epithelium or simulation options are somehow incompatible with the rest of the code.
Example: Cell is given a new property that is used in the collision handler. The cells form an old saved epithelium will not have this property and will explode in the collision handler.
cells should slowly grow or shrink to fit their target size.
This variable can be set by furrow events to cause cells to automatically change their size over time.
Cell collision handler moves each cell as soon as it interacts with another cell.
This means that after a cell is pushed by a different cell it will be in a different position when it interacts with the other cells around it.
This arbitrarily gives more weight to the first cell that a cell interacts with and can even entirely change the cells that are colliding.
When resolving collisions we should first gather all of the forces exerted on cells by all of their neighbors, then move the cells according to the sum of all of the forces.
Furrow events can still pass over cells without checking them. This most likely occurs b/c cells are pushed behind the furrow event in between its checks.
The furrow system also currently allows for furrow events to be run twice on the same groups of cells.
These problems cannot be in the full release of the program.
These config files will work with release/4-20-2018 to reproduce the issue
Cells_Not_Killed.zip
Call this function from MainFrame inside the simulation setter instead of inside the simulation controller.
This try - Except is a hack to get around the fact that cells that were killed will still be sent to the furrow for specialization.
These cells cant be removed from the epithelium and therefore cause an exception when they are killed a second time.
Find a way to be sure that these cells are not sent to the furrow a second time.
Add license to the project.
Dr. Buschbeck needs to approve license.
At the moment when cells divide both resulting cells get half the radius of the original. This results in a total area that is much smaller than the area of the original cell.
Should we instead have each cell get a radius of sqrt((orig_radius**2) / 2) which would result in each child cell getting half the area of the parent?
Right now cells will grow from the beginning of the simulation and never stop.
Have the cells only grow in the mitotic wave.
Remove all code related to the legacy renderer.
Remove PyOpenGL from requirements.txt
Right now nothing is an interface and implementations of things like the cell factory and the cell collision handler are just hard coded. It should be possible and easy to replace our implementations of these things.
Look at implementing just about everything in terms of an ABC.
Construct all objects that can be replaced by the user somewhere in quick_change and ensure that the ones specified there are the ones used by the simulation.
Dont specialize a cell if it has already been specialized.
Make sure that they can specialize all of the cells.
* Currently we only select a certain number of neighbors for some of the selection functions regardless of how many cells we intend to recruit. That means that if we try to get over 100 r2 cells it doesn't actually specialize that many.
Sit down with Dr. Buschbeck and figure out the best target size that cells try to grow to. Maybe different cell types have different sizes? Stop growing after they're specialized? Could possibly be a user input
When a cell is much bigger than the average cell CellCollisionHandler does not correctly handle its collision.
(if the cell is as big as two or more bins)
We should use the system temp directory instead of a hardcoded temp directory relative to the path of the application.
Update the MainFrame.temporary_epithelium_location
to use the system temp directory.
make .sim
and .epth
the default file types for simulation and epithelium saves respectively.
The epithelium is expected to be able to figure out how close together cells are and by forwarding its calls to the cell collision handler we're using max cell size instead of average cell size and reporting cells too far away as being neighbors.
http://mikegrouchy.com/blog/2012/05/be-pythonic-__init__py.html
lets get rid of the from package.file import File and replace it with from package import File
This can be done by importing the classes within the init.py for each module.
Sometimes cell death can cause a crash .
Currently when an epithelium cant be loaded it shows a popup error. When a simulation setting cant be loaded it shows a popup warning.
This should be standardised to error.
Right now the first R8 cells that are selected are touching the edge of the epithelium.
Make it so that R8 cells are only selected if they are at least r8 distance away from the edge.
It would be nice if the epithelium started centered on the screen instead of the bottom left.
Consider an extreme situation where cell growth causes many of the right most cells to shift 100 average cell radii to the right within a single update of the furrow position. Everything that was pushed to the right of the furrow will be missed by the next pass.
This is a crazy edge case, that probably will never happen, but this may be happening in small ways throughout the simulation.
Consider revising the Furrow to accommodate for this (make the furrow move relative to the movement of the epithelium? ).
Every register and Deregister of a cell causes a the CellCollisionHandler to bin everything.
We can probably save some time if we just have to do that once per tick.
The default parameters of the simulation should reflect Drosophila since that is what the simulation is based on.
From Dr. Buschbeck the paramaters should be:
Setting | Value |
---|---|
Min cell count | 10000 |
Average cell size | 8 |
cell size variance | 0.1 |
Cell max size | 15 |
Cell Growth rate | 0.005 |
Furrow Velocity | 20 |
simulation speed | 100 |
r8 exclusion raidus | 2 |
r8 target radius | 20 |
min distance from edge | 3 |
distance from furrow | 0 |
r2,r5 selection count | 2 |
r2,r5 target radius | 20 |
max distance from R8 | 2 |
distance from furrow | 100 |
r3, r4 selection count | 2 |
r3, r4 target radius | 20 |
max distance from R8 | 2 |
distance from furrow | 150 |
r1, r6 selection count | 2 |
r1, r6 target radius | 25 |
max distance from R8 | 4 |
distance from furrow | 200 |
border radius | 1 |
target radius | 20 |
distance from furrow | 1000 |
death chance | 30 |
distance from furrow | 1200 |
Saving an epithelium does not put the epithelium where requested.
It is impossible to load an epithelium. "Error: Could not load epithelium!" error always occurs.
Backend logic is clearly working (b/c Save/Load is what actually goes on under the hood when pressing the "stop" button in the simulation tab).
50 times is not sufficient for a large epithelium
Sometimes one R8 cell will select other photoreceptor cells multiple times. Fix this.
Add a requirements.txt file to simplify setup
Is this real?
CellCollisionHandler assumes that the positions of all cells are positive when determining how to partition the internal cell grid. This likely results in performance degradation and/or incorrect collision handling as cells expand/divide and push each other into negative positions.
right now Furrow events all have absolute distances from the furrow. It would be a nice usability feature to allow for one furrow events distance from the furrow to be relative to another furrow events.
Add a combo box that determines if a distance from a furrow is relative or absolute. If it is relative allow the user to select which furrow event it is relative to (another combo box?).
Absolute distance from furrow would be unchanged, but relative distance would add/subtract/multiply/divide the furrow distance of the selected event to produce the absolute distance to the furrow of the new Event
There appears to be a strange maximum number of receptors that can be recruited when trying to run configurations meant to create large units.
For some reason the maximum appears to be 256.
If 257 is input for any of these the entire field fills up with photoreceptors.
There should be no maximum.
There are currently almost no tests.
Ideally there should be a unit test for every functionality that we have and integration tests where the individual components interact.
We have been really lax on this so far, and that has created lots of opportunities for bugs and regressions.
Time to get some test coverage.
We should also add CI and require tests passing there before merging any PRs
in each cell selection function add a parameter to dictate what the max size of that cell type is
From Dr. Buschbeck's email:
if border cells are specified earlier than the photoreceptors, then the photoreceptors form from them (where they should stay what they are specified once that has been decided).
Selecting R8 away from the edge can use the cell grid correctly, the cell collision handler uses the cell grid correctly
currently we only have IntigerFieldType this greatly limits the power of the dynamic GUI.
It is also not currently possible to add more validation rules to a FieldType. Modify field type to allow users to add validation restrictions without needing to create a new FieldType child class. Perhaps a function pointer?
Right now the dynamic GUI system leaves a lot to be desired.
Adding inputs to the furrow event list requires three steps.
There is a lot of room for error between 1 and 2.
It would be nice to take advantage of python's reflection capabilities.
Each furrow event could be a class. We could look at the properties of that class and autogenerate the fields and their widget types from that.
The documentation is outdated and still references the initial senior design project.
Add full client-ready documentation
When a border radius of 0 is input border cells are still created.
A radius of 0 should result in no border cells.
Fix crashes that occur when starting with cells of size 100.
This has to do with creating only enough bins to hold cells if they all have an average size.
This has to do with adding the default cell events.
For some reason the scrolled window for Furrow Events does not allow the user to scroll (regardless of how many inputs it contains) until the window is resized.
WxPython is causing lots of cross platform problems. QT seems like it may be a better choice.
Try to make the switch.
It may be more readable and better maintainable if field types provide their own event handler functions rather than having a function in MainFrame that produces event handlers for each FieldType.
an attempt at this can be seen in bug/i81-FurrowEvents_dont_update_v2
Moving collision logic to pyOpenCL would allow us to use CPU and GPU parallelism in our collision logic.
This would make things MUCH master. Lets look into this.
https://en.wikipedia.org/wiki/Barnes–Hut_simulation
Try:
determine number of bins
histogram to determine the number of cells in each bin
Put cells in each bin (prob use single array in shared memory)
PushPull Cells
We may want to add the option for this to be a n-body simulation. That way cells would tend towards clumping together.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.