instructions for specifying floating-point precision of fields/materials arrays #1563
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stevengj
reviewed
May 4, 2021
doc/docs/Build_From_Source.md
Outdated
| @@ -244,6 +244,31 @@ By default, Meep's configure script tries to guess the gcc `-march` flag for the | |||
| — | |||
| This flag enables some experimental support for [OpenMP](https://en.wikipedia.org/wiki/OpenMP) multithreading parallelism on multi-core machines (*instead* of MPI, or in addition to MPI if you have multiple processor cores per MPI process). Currently, only multi-frequency [`near2far`](Python_User_Interface.md#near-to-far-field-spectra) calculations are sped up this way, but in the future this [may be expanded](https://github.com/NanoComp/meep/issues/228) with additional OpenMP parallelism. When you run Meep, you can first set the `OMP_NUM_THREADS` environment variable to the number of threads you want OpenMP to use. | |||
|
|
|||
| ### Floating-Point Precision of the Fields and Materials Arrays | |||
|
|
|||
| By default, the time-domain fields ($\mathbf{E}$, $\mathbf{D}$, $\mathbf{H}$) and materials ($\varepsilon$) arrays used in Meep are defined using [double-precision floating point](https://en.wikipedia.org/wiki/Double-precision_floating-point_format). Updating the fields arrays generally dominates the cost of the simulation because it occurs at every voxel in the computational cell and at every timestep. Because discretization error from the discontinuous material interfaces (as described in [Subpixel Smoothing](Subpixel_Smoothing.md)) typically dominates the [floating-point roundoff error](https://en.wikipedia.org/wiki/Round-off_error), the fields/materials arrays can be defined using [single-precision floating point](https://en.wikipedia.org/wiki/Single-precision_floating-point_format) to provide a significant speedup (by reducing the [memory bandwidth](https://en.wikipedia.org/wiki/Memory_bandwidth)) often without *any loss* in simulation accuracy. | |||
There was a problem hiding this comment.
Even without material interfaces, discretization error should dominate over the floating-point roundoff error.
There was a problem hiding this comment.
I have updated the wording in this line to make this point clearer.
bencbartlett
pushed a commit
to bencbartlett/meep
that referenced
this pull request
Sep 9, 2021
…als arrays (NanoComp#1563) * instructions for specifying floating-point precision of fields/materials arrays * clarify that discretization errors in general dominate roundoff error
This was referenced Oct 3, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following #1544, adds a new section "Floating-Point Precision of the Fields and Materials Arrays" to the Build From Source page of the user manual.
Also includes a couple of minor fixes in other (unrelated) parts of the user manual.