Your simulation software is most likely either CPU bound or memory bound. For such workloads, one would not except to see any significant difference between running the code on "bare metal" or inside WSL (or any other compatibility layer or VM that uses native execution), since in either case the OS is mostly just standing by while the simulation code runs directly on the CPU.
However, it's also possible that your simulation is at least partially I/O bound, and that's where differences may emerge. Apparently, WSL (currently) has a rather slow filesystem interface layer that can slow down disk I/O significantly.* That said, while disk I/O can be the major bottleneck for many kinds of bulk data processing tasks, a "simulation" usually should not be spending the majority of its time reading and writing files. If yours is, you may want to consider running it from a RAM disk (e.g. tmpfs on native** Linux) to avoid needless physical disk access.
In any case, the only way to be sure is to test your simulation in both environments and time how long it takes to run. Before doing that, however, you may want to take a look at existing benchmarks, like this WSL vs. Docker vs. VirtualBox vs. native Linux performance benchmark by Phoronix from February 2018, and examine the results for any tests that stress the same components of the system as your simulation does.
(FWIW, the Phoronix results seem to mostly match the general principles I outlined above, although there are a few notable oddities like VirtualBox apparently outperforming native Linux in a few I/O bound benchmarks, apparently due to its virtual disk not always immediately syncing data to the physical disk. One potentially relevant issue that I failed to note above is that the benchmarks show significant differences in multi-threaded OpenMP performance both between the different host environments and also between different Linux distros even when running on bare hardware. In hindsight, that's not too surprising, since threading and IPC is handled by the kernel. I'd guess that much of the difference between the distros there may come down to different runtime and/or compile time kernel tuning parameters.)
*) According to this MSDN blog post from 2016, there are actually two filesystem interface components in WSL: VolFs, which closely emulates native Linux filesystem semantics over NTFS and is used to mount e.g. / and /home, and DrvFs, which provides mostly Windows-like semantics and is used for accessing the host Windows drives via /mnt/c etc. If your software doesn't specifically require native Linux filesystem features like multiple hard links to the same file, configuring it to store its data files in a DrvFs folder may improve file access performance on WSL.
**) According to this Reddit thread from May 2017, "tmpfs is currently emulated using disk" on WSL. Unless something has changed over the last year, this presumably means that using tmpfs on WSL gives no performance benefit over using a normal on-disk filesystem.
