Quick request to Chester Dias: Please move this ticket to "In Progress" if you have started working on it.

Understanding of the code
the images are fetched by key names that are used for referencing the images in the images folder.

Key names have a fixed format. Below is a list of array keys for the genomeData object. To maintain easy mapping all objects I believe have the same keys.
Location: utils.js, gnome keys: A_thaliana, S_lycopersicum, C_sativa .......

Keys are initialized in the beginning.

Current issue:
if 2 or more scientific names have the same initial for first name and same last name we get a conflict in images since image names won't be unique....

Quick Resolution specific to Removing image name Conflicts(I gave this idea a try on a small scale to see if this works attached screenshots):
change image name from objects key name to scientific name (ex: Camelina sativa.jpg)
Reference images by scientific name during an image search and display operation

A possible future issue(since I am not very clear on some aspects yet) with the current keys:
Due to data structures having key names such as C_sativa or A_thaliana we may have an overwrite of data if we add a new species with 'same initial of first name' and 'same last name'

Building on the previous comment - util.js is here:

https://bitbucket.org/lorainelab/genome-dashboard/src/master/utility/util.js

IGB and IGB Quickload expectations for genome version names:

• https://wiki.transvar.org/display/igbman/Sharing+data+using+QuickLoad+sites

IGB and IGB Quickload both assume there is never any name collisions between genome version prefixes. So the original premise of this task may be unworkable - we can't use the string C_sativa for two different species.

A related issue: https://jira.transvar.org/browse/IGBF-1175

Instead of using the scientific (binomial) name as the species image name, let's use the genome version prefix. The genome version prefix is the part of a genome version name preceding the month and year.

For example, IGB Quickload contains an apple genome version named M_domestica_Borkh_Jun_2017. The genome prefix name is M_domestica_Borkh, which uniquely identifies this species within all IGB systems. Note that in this case, "Borkh" indicates a particular apple cultivar.

If we add Cannabis sativa genomes, we can include strain in the genome version prefix.

For example, the Jan 2019 paper https://pubmed.ncbi.nlm.nih.gov/30409771/ described new assembles for two Cannabis strains abbreviated in the paper as "PK" and "FN". Within IGB, these two assemblies could be designated C_sativa_PK_Jan_2019 and C_sativa_FN_Jan_2019. Each could even get its own picture in IGB, ideally showing their distinctive features.

IGB Quickload main site now includes new genome version C_sativa_CBDRx_Dec_2018.
See: http://igbquickload.org/quickload/C_sativa_CBDRx_Dec_2018/

contents.txt for this site (http://igbquickload.org/quickload/contents.txt) now lists two genome versions with potential name collisions in genome dashboard:

C_sativa_DH55_Apr_2014 Camelina sativa (false flax) April 2014
C_sativa_CBDRx_Dec_2018 Cannabis sativa CBDRx Dec 2018

Master branch species.txt now contains:
Cannabis sativa CBDRx Cannabis sativa CBDRx C_sativa_CBDRx

Genome dashboard is making an incorrect assumption about genome version names which causes more than just an image problem.
See attached image - falseflax.png.
As you can see, the genome versions being shown includes the Cannabis genome, which is wrong.
utils.js needs to use the entire genome version prefix string as a key, not just the first two components.
That is, it should use C_sativa_DH55 as the key for false flax and C_sativa_CBDRx as the key for Cannabis strain CBDRx.
In addition, we need to rename the image files in the repository to use the entire genome version prefix and not just the first two components. Let's rename the image files as part of a separate ticket to spread the work out a bit more.

Required change has been made
New change:
instead of using genius and species name(ex C_sativa) as the key the dashboard uses genome prefix name (ex: C_sativa_DH55)
Please review change: https://bitbucket.org/chesterdias/genome-dashboard/branch/IGBF-2399#diff

Note: This will need a change of image names for some images to genome version name (ex: for False flax will change from C_sativa.jpg to C_sativa_DH55.jpg)

I'm not sure this will work:

          if(temp_name.length==5){
                 final = final + '_' + temp_name[2];
           }
           final=final.trim();

The problem is there can be arbitrarily many components connected by underscore characters in a genome version name.

For example:

• H_sapiens_Chester_Dias_from_UNCC_May_2020

is a perfectly legal genome version name.

In python, you would do something like this:

genome_version = "H_sapiens_Chester_Dias_from_UNCC_May_2020"
tokens = genome_version.split("_")
tokens = tokens[:-2] # get rid of month and year
genome_version_prefix = "_".join(tokens)

(I don't know how you do this in javascript - sorry!)

Maybe write a function that does this and put it into utils.js. You could call it "getGenomeVersionPrefixFromGenomeVersion" or something similar.

Then you can use it in multiple places in the project.

Understood I will change it.

Review: https://bitbucket.org/chesterdias/genome-dashboard/branch/IGBF-2399#diff

this is same as python logic I think

Change request:

• change getGenomeVersionName to getGenomeVersionPrefix

A genome version name includes the month and year of release and a prefix that uniquely identifies a strain and/or species.

This code does not look like it will return:

• H_sapiens_Chester_Dias_from_UNCC from H_sapiens_Chester_Dias_from_UNCC_May_2020

It looks like it will return H_sapiens_Chester_Dias_from_UNCC_May instead (includes the month).

I did slicing 2 times and verified the output in the output log. It does the exact same thing, this first slice will remove the year and the second slice will remove the month.

I have changed the function name please review again

OK I see! Thanks.
Please remove the console logging statement.

Done

Please also raise a ticket for an image name change, otherwise, images won't be visible for some.

Question: Why is this line still needed?

let temp_name = element.split('\t')[0].split('_');

Question:

I don't know if it is a good idea to use "trim" in this way:

final=final.trim();

The values are separated by tab characters, and there could be values that end with whitespace characters.

I wasn't sure if it is used somewhere else in the code...let me go ahead and remove it

trim was needed to remove the empty space that occurs sometimes, makes the key mapping different on some situations. Adding trim to the key is fine I think, Keys are used only internally for array manipulation and images.

I have removed the temp_name

When does empty space occur? Can you show an example?

Chester Dias

I had one situation. where spaces resulted in 2 images for same species. Since the text with space got introduced as a new key. The logic is in such a way that if a key is not found it has to be added to the array.

will try and replicate the error will take some time

change requests to make the code a bit easier to read:

• Change variable name "final" to "genomeVersionPrefix"
• Change variable name "genomeData" to "genomeVersions"
• Instead of calling element.split('\t') many times, do it once and assign the result to a variable named "contentsTxtValues" (or similar)

I guess it was an issue in the earlier way how I had written the code. The issue is no longer present, I have removed trim.
Please Check

Also you should probably delete the second "try" block in utils.js getContents.

I don't know why the second "try" block is still there. Looks like it pre-dates the first "try" block. I should have asked about on or around this commit:

https://bitbucket.org/sshanbh1/genome-dashboard/commits/6fea92c8a08500a25cf9eaf8cb289b2c42f791c4

Sameer Shanbhag - we can delete the second "try" block below - correct?

// this one should stay
try {
        let content_arr = await mergeAllQuickLoadSites();
        content_arr.forEach(element => {
            if (element.trim().length > 0) {
                let temp_name = element.split('\t')[0].split('_');
                let final = temp_name[0] + '_' + temp_name[1];
                if (!final.includes(undefined)) {
                    temp = element.split('\t')[1].split(' ')[0] + ' ' + element.split('\t')[1].split(' ')[1];
                    if (genomeData[final] !== undefined) {
                        if(!scientificName[final].includes(temp)){
                            scientificName[final].push(temp); // = genomeData[final].
                        }
                        if(!genomeData[final].includes(element.split('\t')[0])){
                            genomeData[final].push(element.split('\t')[0]);
                        }
                    } else {
                        genomeData[final] = [element.split('\t')[0]];
                        scientificName[final] = [temp];
                    }
                }
            }
        });
    } catch (error) {
        console.log(error.message);
    }
// this one should probably be deleted
    try {
        await fetch(CONTENT_TXT)
            .then((response) => response.text())
            .then(newResp => {
                let content_arr = newResp.split('\n');
                content_arr.forEach(element => {
                    if (element.trim().length > 0) {
                        let temp_name = element.split('\t')[0].split('_');
                        let final = temp_name[0] + '_' + temp_name[1];
                        if (!final.includes(undefined)) {
                            temp = element.split('\t')[1].split(' ')[0] + ' ' + element.split('\t')[1].split(' ')[1];
                            if (genomeData[final] !== undefined) {
                                if(!scientificName[final].includes(temp)){
                                    scientificName[final].push(temp); // = genomeData[final].
                                }
                                if(!genomeData[final].includes(element.split('\t')[0])){
                                    genomeData[final].push(element.split('\t')[0]);
                                }
                            } else {
                                genomeData[final] = [element.split('\t')[0]];
                                scientificName[final] = [temp];
                            }
                        }
                    }
                });
            });
    } catch (error) {
        console.log(error.message);
    }

Also, let's add some comments explaining what the returned data structure (a hashtable?) is supposed to do.

If I were re-designing this, I would be very tempted to make this into a Web service instead of making the javascript do all this heavy lifting. I feel like javascript is too hard to test and debug. But maybe that's only because I'm not used to coding in javascript.

The second try block can be removed, If I do that I would probably handle the catching using the ".catch()" method for promises as we don't actually need to Try Catch when we are dealing with promises. Fetch API returns a promise, to make it synchronous we use await.

More explanation on this can be found here:

1. https://developers.google.com/web/updates/2015/03/introduction-to-fetch
2. https://medium.com/@lucymarmitchell/using-then-catch-finally-to-handle-errors-in-javascript-promises-6de92bce3afc

I am using a dictionary data structure as it is faster and efficient to read and write data into the Dictionary. The output of the utility will have Dictionary of Dictionaries, each having specific information about a particular genome. Another reason os using a dictionary is, it can be easily converted into JSON if we were to convert it into Web API, which can be easily done by replacing

```
res.render('index',

);
```

with

```
res.send(

);
```

in Index file:https://bitbucket.org/sshanbh1/genome-dashboard/src/master/routes/index.js

P.S. [~aloraine]

I tried commenting the whole second try-catch block it does not seem to affect the UI in any way, I guess it can be deleted.

I have made removed that block as no longer needed. It did not seem to affect the UI.
Added comments wherever required in utils.js, the rest of the files seem to have comments.
Updated Readme.md to include steps to get started with this project using PyCharm IDE.

Review :https://bitbucket.org/chesterdias/genome-dashboard/branch/IGBF-2399#diff

If you happen to see this, do please rebase and submit PR at your earliest convenience. Otherwise no worries.

If you want to wait

If you happen to see this, do please rebase and submit PR at your earliest convenience. Otherwise no worries as we can easily get the changes from your fork and merge in without your needing to do anything. The commit will still be yours.

cc: Philip Badzuh and Chester Dias

https://bitbucket.org/lorainelab/genome-dashboard/pull-requests/10/igbf-2399/diff

Merged.

Philip Badzuh - IGBF-2399 code changes (from Chester Dias) are now merged to master branch.