Last updated: 2025-04-09

Checks: 6 1

Knit directory: GradLog/

This reproducible R Markdown analysis was created with workflowr (version 1.7.0). The Checks tab describes the reproducibility checks that were applied when the results were created. The Past versions tab lists the development history.

R Markdown file: uncommitted changes

The R Markdown file has unstaged changes. To know which version of the R Markdown file created these results, you’ll want to first commit it to the Git repo. If you’re still working on the analysis, you can ignore this warning. When you’re finished, you can run wflow_publish to commit the R Markdown file and build the HTML.

Environment: empty

Great job! The global environment was empty. Objects defined in the global environment can affect the analysis in your R Markdown file in unknown ways. For reproduciblity it’s best to always run the code in an empty environment.

Seed: set.seed(20201014)

The command set.seed(20201014) was run prior to running the code in the R Markdown file. Setting a seed ensures that any results that rely on randomness, e.g. subsampling or permutations, are reproducible.

Session information: recorded

Great job! Recording the operating system, R version, and package versions is critical for reproducibility.

Cache: none

Nice! There were no cached chunks for this analysis, so you can be confident that you successfully produced the results during this run.

File paths: relative

Great job! Using relative paths to the files within your workflowr project makes it easier to run your code on other machines.

Repository version: d380601

Great! You are using Git for version control. Tracking code development and connecting the code version to the results is critical for reproducibility.

The results in this page were generated with repository version d380601. See the Past versions tab to see a history of the changes made to the R Markdown and HTML files.

Note that you need to be careful to ensure that all relevant files for the analysis have been committed to Git prior to generating the results (you can use wflow_publish or wflow_git_commit). workflowr only checks the R Markdown file, but you know if there are other scripts or data files that it depends on. Below is the status of the Git repository when the results were generated:


Ignored files:
    Ignored:    .DS_Store
    Ignored:    .Rhistory
    Ignored:    .Rproj.user/
    Ignored:    analysis/.DS_Store
    Ignored:    analysis/.Rhistory

Unstaged changes:
    Modified:   analysis/Log2024_new_beginning.Rmd
    Modified:   analysis/week_log.Rmd

Note that any generated files, e.g. HTML, png, CSS, etc., are not included in this status report because it is ok for generated content to have uncommitted changes.

These are the previous versions of the repository in which changes were made to the R Markdown (analysis/week_log.Rmd) and HTML (docs/week_log.html) files. If you’ve configured a remote Git repository (see ?wflow_git_remote), click on the hyperlinks in the table below to view the files as they were in that past version.

File	Version	Author	Date	Message
html	ff0bca7	liliw-w	2024-04-24	Build site.
html	9fd6e5f	liliw-w	2024-04-24	Build site.
Rmd	8173962	liliw-w	2024-04-24	wflow_publish("analysis/week_log.Rmd")
html	151bee4	liliw-w	2024-04-22	Build site.
Rmd	b7a0bd9	liliw-w	2024-04-22	test toc render
html	423f69e	liliw-w	2024-04-22	Build site.
html	1cf9a35	liliw-w	2024-04-22	Build site.
Rmd	2448521	liliw-w	2024-04-22	rename
html	ae55f7a	liliw-w	2024-04-22	test toc render
Rmd	f595c33	liliw-w	2024-04-22	rename
html	76794f9	liliw-w	2024-02-20	Build site.
Rmd	cd27671	liliw-w	2024-02-20	test
html	2b44f3b	liliw-w	2024-02-20	Build site.
Rmd	ab953a4	liliw-w	2024-02-20	test
html	79511af	liliw-w	2024-02-20	Build site.
Rmd	b4b7969	liliw-w	2024-02-20	test
html	355d984	liliw-w	2024-02-20	Build site.
Rmd	d469ed5	liliw-w	2024-02-20	test
html	387ac23	liliw-w	2024-02-20	Build site.
Rmd	85299ae	liliw-w	2024-02-20	test
html	d8c2606	liliw-w	2024-02-20	Build site.
Rmd	26506ca	liliw-w	2024-02-20	test
html	c775adf	liliw-w	2024-02-20	Build site.
Rmd	f3d506d	liliw-w	2024-02-20	test
html	8d7f0d8	liliw-w	2024-02-20	Build site.
Rmd	9b5c76e	liliw-w	2024-02-20	test
html	46b8cba	liliw-w	2024-02-20	Build site.
Rmd	04c5671	liliw-w	2024-02-20	test

April 09

Progress summary

Get familiar with and set up cluster.
Looked at the serial biopsies data.

`GENOMIC_SPECIMEN.csv`

Dataset Info

Each row is a sample. Multiple samples can come from one patient. These samples are profiled in different time points.
One patient’s samples can be tested by multiple TEST_TYPE (3%).

Filter samples and patients

Only consider patient specimens tested with OncoPanel from PROFILECOHORT, by filtering TEST_TYPE == 'ONCOPANEL_PROFILECOHORT'.
There are 27,148 specimen, 26,307 unique patients, 773 patients have their multiple samples tested.
719 patients have been tested twice. The other patients were tested 3 to 6 times.
I only keep specimen samples from patients that were sampled twice, corresponding to 1438 sample left. [This corresponds to what we mentioned about the data - “~1000 patients”, “sequenced twice”]

Figure: Number of samples each patient has.

Patient classification

To classify a patient of two samples, I use flag IS_MATCHED_FLG (normal or tumor sample) and REPORT_DT (Date this report was signed out by the pathologist), which results in four categories.

patient_category	n_patients
normal−normal	13
normal−tumor	1
tumor−normal	14
tumor−tumor	691

Figure: Number of patients belong to each catogory.

Questions -

No flag SAMPLE_COLLECTION_DT to record accurate date when sample was collected first.
Does “tumor-tumor” mean two samples were collected before and after treatment?
Why normal samples have non zero tumor purity? Some samples also have negative tumor purity.

Figure: Normal samples have non zero tumor purity.

TUMOR_PURITY change across patients’ two biopsies

TUMOR_PURITY - Estimated percentage of neoplastic cells in the sample.

Figure: TUMOR_PURITY changes across two biopsies of each patient belonging to four catogories.

`GENOMIC_MUTATION_RESULTS.csv`

Filter samples and variants

Use samples from above
Only SNP variants
Keep only patients that have two samples across mutation changes (some patients have only one sample with mutation info)
Resulting in 650 patients

Figure: Number of patients belong to each catogory.

ALLELE_FRACTION change across patients’ two biopsies for SNPs

ALLELE_FRACTION - Fraction of reads for the observed allele.
How many SNPs does each patient have?

Figure: Number of SNP varaints each patient has.

ALLELE_FRACTION change across patients’ two biopsies for SNPs

Figure: ALLELE_FRACTION change across patients’ two biopsies for SNPs.