Fitness histogram output

[ms609]

The Fitness histogram feature is useful, but its documentation left me with a number of questions.

• I ran the command with its default settings (32 bits, one repeat); this looked like it would take a very long time so I tried to abort (which seemed to required a Ctrl-Alt-Del). If run time increases exponentially when the genome is |gt|16 (sic) bits (not clear why it is not exponential at lower values – does a fixed overhead dominate runtime?), perhaps a smaller default value would be more suitable?

• Is it necessary to evaluate every single genome, rather than a statistically representative subset?

• If every possible genome is being evaluated, it's not quite clear why a repeat is necessary – I guess this reflects stochasticity in environmental setup? It would be helpful to specify what is kept constant / varied under a "repeat".

• There's no indication of success/completion of a run. I was expecting to see a histogram pop up as a dialog box. I did find the output in the output directory, but as I hadn't been prompted to set a save location (and as the "Save path" seems to relate to the "Run", rather than to the separate "Commands" menu bar) I didn't immediately look there. Perhaps a dialog message "Run complete; results saved to " would have pointed me in the right direction. The fact that subsequent runs are appended to the same file also threw me somewhat; is there a single file for each TREvoSim session?

• I ran the command with a smaller genome but find the output difficult to parse. I interpreted Fit to environment: 20 as meaning "Fit to the twentieth environment". I was very confused until I understood what it actually meant. Could this be reworded?

[RussellGarwood]

I'm dealing with this now - just a note to say that on my system, this can be cancelled with either escape or hitting the stop button on the GUI - it would be good to know if this is not the case on windows!

[RussellGarwood]

With the above commits, I have made the following changes to address this issue:

• As above, the GUI updates correctly to allow a run to be cancelled part way through via toolbar buttons as well as escape - it would be good to know if this is not the case in windows
• The default for calculation is now 16
• For any genome length above 20, the function now reports results based on 1000000 randomly chosen genomes, rather than doing ah exhaustive search (I played with this for quite a while, and this turned out to be by far the preferable approach: I have also checked the distrributions make sense against an exhaustive search where possible)
• I've updated the documentation to reflect this, and increased the amout of information in that section about what to expect, etc, including why repeats are useful (you are correct that this is due to the stochasticity in environmental setup - masks are random and impact the nature of the distribution of the fitnesses)
• On completion there is now a pop up window telling the user where to fidn the output
• The append was a hangover from an older approach I used, the software now overwrites any histogram count files in the folder, but importantly provides a warning message before commencing the fitness histogram calculation if files will be overwritten
• I've changed the wording of the output to one that makes more sense (again, old wording represented a previous choice of how to describe what TREvoSim did which I decided ultimately was not useful) - and while I was there I also made the histogram section CSV formatted

I think that is everything!

[ms609]

I rebuilt the software this mornining. When I run the Fitness histogram, Trevosim pauses for a couple of seconds (presumably running the calculations), then closes without writing any output files (but after creating the specified output directory).

The updated documentation reads well and is clear to follow.

[RussellGarwood]

Oh no! Many apologies. I don't get this on my end - it is definitely the most recent source code, right (as it was crashing a few days ago whilst I was fiddling)?

I will dig into the code and try and figure out what it could be, however, are you able to debug it? Hitting this button, if debugging is installed: Should catch where it is crashing when you do the run, and if you could let me know what line it is, it would be a great help!

[ms609]

I've pulled commit 84826bdc6e90d25d6f42932028816454f69dccff.

Here's the debug info:

[RussellGarwood]

Hmm, this is the assembly code - somewhere in the GUI it should also tell you the line of the source code that is causing the issue - is that visible/obvious? I can create a crash here and send you a screenshot if helpful, though we may have a slightly different IDE GUI.

[RussellGarwood]

In mine, it is selecting the last line on the bottom right that is in one of the source files:

[ms609]

I needed to add debug information tools to my Qt installation and build the debug version of the software... Qt is still grumbling about this but hopefully the below gives the information you need?

[RussellGarwood]

Thanks for taking the time to do so, much appreciated. This is definitely a start, in that it is happening within the count peaks function itself. I'll next check whether this is a windows wide issue, and if not may come back and ask you to do a fresh rebuild just in case there is something lingering in the build chain that is messing stuff up!

[alanspencer]

Its a Windows-wide build issue. Digging into it now...

[RussellGarwood]

Thanks! It looks like a memory issue, but why it isn't segfaulting on Linux then is a bit of a mystery to me. Interested in what you find

[RussellGarwood]

@ms609 - Alan and I dug around, and turns out Windows limits stack variables to 1mb, whereas Linux to 8mb. The above commit moves the randoms to test onto the heap, and so hopefully should fix the crash for you.

[ms609]

Fab, that's got it working – good job on tracking the issue down!

If it's easy, you might consider making the entry for "how many bits" remember the last value used, to make repeat analyses easier to perform. But this probably makes at best a miniscule improvement to user convenience!

[RussellGarwood]

Good news, thaks for checking. Sure I can make the bits value persistent. For your use case, would within session surfice, or would persisting across sessions be of utility?

[ms609]

I think the gain in convenience is obtained within a session; in fact it's probably nice if a new session returns to the default.

[RussellGarwood]

Super, cheers - done!