rasmusrendal / crnsimul Goto Github PK

In POSIX, you can start a executable file with #!/usr/bin/bash to indicate the file is to be executed in bash. Ideally, we should be able to do the same with the chemilang interpreter. But currently, it tries to interpret the shebang, leading to parser errors.

Ideally, we should just add comments that start with #, but we could also just make a special case to ignore shebangs.

At the moment, the only way the Markov evaluator will mark itself as "finished" is if there are no more reactions possible in the current state. However, most useful CRNs end up in some sort of equilibrium, which the Markov evaluator will just sit on infinitely.

So we either neet some sort of way to detect that we've reached an equilibrium (might be the halting problem in disguise), or just set a cap on the iterations we're willing to perform.

Det er floating point operations. GPU'er kan go fast med floating point operations.

When #42 gets merged, we can pretty easily see the test coverage. We should use that to try and figure out which parts of the program are not covered by automatic tests, and reduce that as much as possible.

You can see the code coverage for commit 02720c4 here.

When you sum n floating points numbers, the errors accumulate at a rate of n. There are compensated summation methods that fix such things.

Although the error mostly won't accumulate in the Euler evaluator due to the fact that it mostly converges to a fixed point, it is still deeply wrong to just use += in large floating point summations. Kahan summation should probably be used to compensate for any floating point errors.

If we don't have live plotting, we need to have some other way to view what's going on in a non-terminating CRN. Writing to stdout would be a pretty easy way to do that.

It's frankly just confusing to see the help menu printed, when you've supplied all the right arguments

The random walk example, for instance, goes way too fast for the visualization to be useful. We should probably slow it down by default, and then add a flag for running it in unconstrained mode. This will probably also be nicer on the user's CPU.

This makes it possible to run the out.crn files generated form chemilang directly.

I think we are at a place now where we can start implementing the high-level compiler. I also think it would be nice if it wasn't me who had to do that.

I think that for the very first version, we just need to accept the following code snippet, or variations thereof:

module main {
    private: [a,b];
    output: [c];
    concentrations: {
        a := 5;
        b := 3;
    }
    reactions: {
        a + b -> a + b + c;
        c -> 0;
    }
}

It should compile to

a := 5;
b := 3;
a + b -> a + b + c;
c -> 0;

The main challenge here is integrating our new code with the CRN parser code without copy-pasting. This will probably require changing the CRN code a lot. (Good thing we have unit tests)

At least you won't have to make up a data structure for module and such (yet)

This is quite difficult. Maybe I should create my own GitHub action, as all the existing ones are bad

Let's make the cleanest code yet. It's probably a good "getting started with cmake" issue.

For our basic reactions with only two or three species, it's fine that they are all plotted. But if you create big networks, it would be nice if we could say chemilang -p c mul.chem, and only get one of the values. This could eventually be part of the compilation process, adding this argument to the shebang.

The format could be something akin to -p c,a,i,u, ie. a commaseperated list of species names

It will crash if there are no initial concentrations in the CRN, and the error message will not be helpful either.

But since reactions of the form 0 -> c are possible, CRNs with no concentrations at all should be possible to define too.

There are deep copies everywhere, mostly based on gut feeling. The unit tests should be expanded, so we can remove where they are not used.

• lol

Probably gnuplot or something of the sort

Print the result to a csv file.

The main function itself should have as little code as possible. But currently it's giant. And the structure of it isn't great either. A rule of thumb for nice, readable code is having at most 2 levels of indentation in your function. We're at 6.

As a sidenote, if you're interested in writing better code, the books "Clean Code" is one I can recommend. Alternatively, Humble Bundle currently has "The art of readable code" for €1, together with a bunch of other books.

When the slope of the tangent line is calculated very weird things happen. I have tried calling GetNextNetworkState manually and the slopes on the graph for sure have a bigger slope than 0.00001

Reaction constants are required to use, for instance, the square root network. The functionality can be replicated by adding the reaction twice, but that is super ugly.

does not output any text to console when a crn is passed

Ideally, you should be able to supply a "step" value for the euler evaluator, and a threshold for when the simulation stops.

We need dat juicy 100% code coverage

If you call the program with -h, --help, or just any invalid arguments, it should present the user a help menu, that documents how the utility is used

There should be a unit test that tests the Euler Evaluator, if it works with all the stdlib functions we have in the report thus far.

Current plotting uses iterations as x-values, whereas it should use "time".
Time is equivalent to step*iterations.

Ideally, plots should only happen when using the -g flag. Otherwise, you could for example print to stdout.

This will allow for running the software headlessly, which will allow me to do some cool things

Implement a realtime plotter

It should be pretty easy to detect when the total change in concentrations is below some very small value (000.1), and terminate the simulation there.

Doxygen is a super neat framework for doing a lot of documentation. We just need a doxyfile, a bit of gitignore, and some doxygen comments to get started