aladinux / bsim-bccs Goto Github PK

What steps will reproduce the problem?
1. Wrapping boundaries in simulation (sim.setBound(true,true,true);)
2. Moving bacteria (b.update(); in action method)


Throws up an indexing issue in array;
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1
    at bsim.BSimChemicalField.getConc(BSimChemicalField.java:85)
    at bsim.BSimChemicalField.getConc(BSimChemicalField.java:81)

It seems that in the current implementation of kd-tree partitioning, it is 
guaranteed that a particle will escape in finite time from a closed volume. 

- Can be easily reproduced with a minimal case (e.g., tetra- or octahedron 
bounding volume, where octahedron is probably better for generating a less 
trivial tree structure).
- This happens both in the case of deterministic and stochastic splitting 
vertex choice.

- Given a deterministic split, it seems that a particle will escape from the 
same face every time (not confirmed)

For example the method

BSimParticle.intersection(Vector<BSimParticle>)

will not work on a 

Vector<BSimSomeBacteriumThatExtendsParticle> 

when compiling against BSim3.0.jar whereas it works absolutely fine compiling 
within the BSim source tree (e.g. within the 'iGEM' folder as was).

Examples folders are also supposed to contain resources necessary to run the 
simulation, so we need the meshes for things like BSimMeshMotility to be 
present in the relevant folders (assuming the meshes are not too huge...!)

In terms of using BSim as a stand alone library, it would be helpful to have 
some more informative error messages, and more assertions, rather than just 
crashing with an exception. I'm thinking mostly of small errors or basic things 
that might be forgotten when making a new script. For example, bsim.preview() 
assumes that a drawer has been created in the simulation script (OK its 
reasonably obvious in this case, but its the kind of thing that might be 
forgotten when quickly trying to test out simulations).

It seems replication time might be coupled to the time-step size of the 
simulation (increasing the time-step size also increases the generation time of 
new bacteria). Replication/generation time should be independent of simulation 
settings so grow() and replicate() (BSimBacterium) need a close check.

The BSimBacterium class which receives a large number of function calls during 
execution also uses many static *synchronized* methods. This restricts the 
performance that parallelism will add and so some methods may need to be 
directly incorporated into BSimBacterium.

More a note of what needs doing so that I don't forget :)
The following examples at the moment are completely uncommmented i.e. no 
explanation of what they're supposed to be doing:
- BSimReaction
- BSimReplication
- BSimRotationalDiffusion
- BSimSimplest
- BSimTracking
- BSimVesiculeActivation
- BSimVesiculation

line 303 (new version)
This is part of the issue and is actually a bit more complicated than I
have said in the comment. The ratio calculations currently correspond to
chemical passing through two edges (ok for 2D) and need to be updated to
chemical passing through two faces.

Other than that I will check through the file and make sure all the rest of
the chemical field properties are being calculated correctly, and work
correctly if the ratios are changed

BSim GUI; Java script generated from GUI seems not include command lines for 
calling ODE solvers at every time step. GRN however is implemented fine.

A very high diffusivity constant gives numerical instabilities.
I've tried 800.0 and this works fine. Plugging in anything > 1000.0 returns NaN 
when exporting data.

 public void setBrownianForceMagnitude() {
                brownianForceMagnitude = Math.sqrt(2*stokesCoefficient()*BSim.BOLTZMANN*sim.getTemperature()/sim.getDt())*Math.pow(10,9);
        }

Multiplication with Math.pow(10,9) cannot be attributed to difference in scales 
alone. Stokes coefficient defined in meters and cells in micrometers, hence can 
only explain 10^6 multiplication.

Should this be changed to 10^6?

BSimLogger will create an empty file but not write anything to it when 
exporter.dt > 1. 

Modulus, logic etc. for data dumping in the export loop of BSim class appear to 
be working correctly though, so need to dig a bit deeper.

When exporter.dt < 1 (or at least, when the exporter is actually exporting), I 
think that the data dump often terminates early , i.e., I get an incomplete 
output file. Not sure if this is related to the other exporter issues, but it 
could possibly be some desynchronisation where the program terminates before 
the export process is complete? 

Might be related to Issue 2 
(http://code.google.com/p/bsim-bccs/issues/detail?id=2&can=1) but I can't 
comment on that one at the moment so I put it here...

Apart from very few parts of the code (in fact one of them is actually an 
example), there are no real tests ensuring correctness. This is important both 
for showing that code does what we claim, and does it correctly, and for 
ensuring that source changes don't break anything that is already in the code. 
I'm trying to make specific feature tests for what I'm working on now but am 
not sure what the best way to fit this to previous code would be, so we should 
probably discuss this soon.

BSimChemicalField discretisation. 

When defining boxes one must ensure that sim.getBound()/boxes gives an integer 
number. Otherwise numerically unstable and returns NaN when computing chemical 
diffusion in the environemtn.

Attempting to export a movie with a setDt() greater than 1 leads to the movie 
showing a black screen.