Simple mutation simulation for use in science class

The code adheres to many good coding practices already, and it should be simple for beginners to follow. Here are some minor suggestions.

Documentation

The PEP 8 style guide recommends adding docstrings for functions. For example, you could convert your helpful function comments into docstrings like this:

def diss(x, y):
    """ Counts number of dissimilarities between two sequences """

There is no need to use the word "Function" in this case. It would be useful to also document the input variable types and the function return type. Documentation like this will help to achieve one of your goals (to make the code more intuitive).

It would also be useful to add a docstring at the top of the code to summarize its purpose. It is helpful to mention the code creates an output CSV file in the current directory.

Naming

In the diss function, the variables do not have very meaningful names. Since n represents a count, it could be named count.

The function inputs, in addition to having descriptions in the docstring, could have names with "seq" in them.

PEP 8 recommends snake_case for variable names. For example:

def mutate(Dna, Gen):

would be:

def mutate(dna, gen):

Comments

The comment doesn't seem to match the code here ("ten" vs. "12"):

# Generate four simulations, each ten generations long
Mutate_mat = mutate_i(Dna, 12, 4)

Layout

Simple return statements like this:

return (n)

are commonly written without the parentheses:

return n

There are lines with just a single comment character (#) on them:

Dis = []
#
# For loop that mutates the sequence Gen times and calculates the 

The code is cleaner with a true blank line:

Dis = []

# For loop that mutates the sequence Gen times and calculates the 

Simpler

Lines like this:

    header.append("sim_" + str(i))

can be simplified using an f-string:

    header.append(f"sim_{i}")

Python's true and false equate to 1 and 0 respectively.
Save one line of code with:

def diss(x, y):
    n = 0
    for a, b in zip(x, y):
#       n += ( a != b ) editted to improve clarity with next line
        n += ( a != b ) # true = 1, and false = 0
    return n

using optional parentheses to improve clarity of the code.

If it were up to me, I'd move the initialisation of the original DNA string inside mutate_i().
It doesn't appear to be needed at any higher level.

As already noted by @toolic, those constants 12 and 4 should be named, not magic numbers whose purpose is explained by a (erroneous) comment.

NUM_GEN = 12 # number of generations along each run
NUM_SIM = 4 # number of simulations to run

Mutate_mat = mutate_i(NUM_GEN, NUM_SIM)

Unless this program is destined to become more complicated, those values might be simpler if declared inside mutate_i(), rather than being passed as parameters (one of which becomes an anonymous i...)

Will the real "original DNA" please stand up?

def mutate(Dna, Gen):
    # yadda-yadda
    # yadda-yadda yadda yadda
    Dna_o = Dna[:]
    ...

versus

def mutate(Dna_o, Gen):
    Dna = Dna_o[:] # working copy of original DNA
    ...

"Working copies" are made from (unchanged) parameters passed.
"Preserving copies of originals" is putting the horse after the cart.

Give serious thought to using variations on the names of variables used. Code newbies may become confused about whether Dna is referring to a local or 'global' variable.

Proofread the code from the perspective of a coding neophyte.

# Outputs a nested list  <-- Not so good
# Returns a matrix of results for preserving as a CSV file.  <-- More honest

def export_mutate(Mutate_mat, Filename="mutation_simulation.csv"):
    ...
#   for i in range(1, len(Mutate_mat[0])):
    for i in range(1, NUM_SIM): # if only this constant were available here...

And...

        Dis.append(diss(Dna, Dna_o)/Len)

Really? Counting the number of mutations, calculating that as a fraction of the length, AND poking the result into an array... All at the same time! What's a beginner to make of this? Are you hoping to teach coding Python or how genetic mutation works across generations.

Think through all the Pythonesque techniques you've used that will bewilder a beginner. Seek to simplify (like no transposition of the matrix) so as not to lose any who might struggle to understand.

With some effort, this could be re-written to open the file, write the header, then loop generating all the data of a single simulation, write that data as a CSV, then loop generating all of the next simulation, and so on. As stated in a comment, I view time as passing left-to-right, and discrete rows for each different simulation.

EDIT:

I want to keep the code as simple and intuitive as possible, with few abstractions.

There's been a small bit of discussion in various comments regarding the orientation of the output results (ie. generation increments vertical or horizontal). The algorithm used implements "row major" population of the data store wherein there is no cross-row dependence of the data. Things are unnecessarily made more complicated by transposing the matrix and invoking a "CSV writing" module for transfer to Google Sheets.

There are no 'embedded comma/quote' concerns that require a robust CSV writer.

Simplifying the output to write each value with a print statement would eliminate much of this code's excursion away from its central purpose of simply generating some results for downstream analysis.

"Generations" across the horizontal rows, and "simulation runs" as successive rows. Transposing and decorative headings can be added, if desired, once the data values are in a Google Sheets table. KISS!

Phylogenomics is outside of my wheelhouse (having seen this word for the first time in this question.) You've noted that 0.625 is, in part, related to a "mutation" iteration that replaces an 'A' with an 'A', or 'G' with another 'G' (nett zero)... Yet every iteration is scored by comparing it to the original progenitor sequence.

Shouldn't every generation be compared to its own predecessor? Shouldn't the statistics account for 'A' -> 'G' -> 'A' across several generations whereby a subsequence may be partially restored in a descendent? This would have been two actual mutations, but, when compared to the original, the second would have 'undone' the first. Perhaps, for realism, more than one mutation per generation should occur occasionally?

To make this exercise realistic (ie. Darwin's Natural Selection), although it is much more complex, consider teaching the kids about "codons". There could be arbitrary 'good', 'bad' and 'neutral' (aka "junk DNA") codons in a longer "string" of DNA. Mutation still happens, but each generation might require, say, >3 'good' codons and <2 'bad' codons ('neutral' codons have no impact) to survive into the next generation. (John Conway's "Game of Life"). A 'bad' or 'neutral' codon may mutate to become 'good', or whatever... Insufficient 'good' or too many 'bad' codons means the lineage dies out and the 'molecular clock' stops (aka "extinction").

Faulty premise

Consider an (unlikely but plausible) edge case:
In the first mutation, one particular base is replaced; say: 'A' -> 'T'. In an unlikely sequence - but possible from a fair RNG - only that same character is ever replaced:
T -> G -> C -> T -> C -> G -> C -> G -> T ...
That run of the simulation would flat line indicating only one mutation ('A' -> something not 'A') even though there is variation between every generation... Less unlikely edge cases would, similarly yield (perhaps marginally less-) misleading values and still corrupt any statistical results.

It's looking like less time should have been given to dealing with the complexities of Python and its arrays, lists and CSVs; and more thought given to how to produce data that would demonstrate the use for Phylogenomics.
Oversimplification can fuzz important nuances out of existence.

I think the most confusing line for a beginner is:

Mutate_mat = list(map(list, zip(*Mutate_mat)))

I would personally remove the map for beginners in a course that isn't for python because it's just one more thing for them to learn.

Mutate_mat = list(zip(*Mutate_mat))

works exactly the same except that it is a list of tuples instead of a list of lists but you don't need it to be mutable past that point anyways

You could also avoid the zip altogether and write a transpose function:

def transpose_2d(array):
    """
    Transposes a list of lists, assuming that the inner lists
    are of the same length i.e. an M x N array.
    """
    M = len(array)
    N = len(array[0])
    
    transposed = []
    for i in range(N):
        sub_list = []
        for j in range(M):
            sub_list.append(array[j][i])
        transposed.append(sub_list)
    return transposed

Mutate_mat = transpose_2d(Mutate_mat)

Personally I wouldn't do this because I think the extra code to read through is more of a burden than the zip statement so I would use list(zip(*Mutate_mat)) but just an option.

I might also change this line:

Mutate_mat.insert(0, list(range(1, len(Mutate_mat[0])+1)))

to:

generation_count = list(range(1, len(Mutate_mat[0])+1))
Mutate_mat.insert(0, generation_count)

I think it is harder for beginners when there are multiple things happening on a single line. Also splitting up the lines allows you to choose a variable name that describes what that part of the code is.

I would also try to avoid short forms as long as variable names aren't too long. just makes it easier to read in my opinion.

Gen -> generation
diss -> dissimilarities
Dna_o -> original_dna

The suggestion to avoid magic numbers was already made but I just wanted to say that this comment really illustrates the point:

# Generate four simulations, each ten generations long
Mutate_mat = mutate_i(Dna, 12, 4)

You've changed those numbers so now isn't not clear from this comment which argument is number of simulations and which argument is number of generations.

NUM_GEN = 12 # number of generations along each run
NUM_SIM = 4 # number of simulations to run

at the top so it's easy to find the variable you want to play with is really helpful and makes it easier to make comments that don't become obsolete

# Generate NUM_SIM simulations, each NUM_GEN generations long
Mutate_mat = mutate_i(Dna, NUM_GEN , NUM_SIM )