For the geometry: There are several types of FNG model, which one do we use? FNG-dose or others?
I think we should use the model which will be easiest to ensure that data and materials are consistent between OpenMC and DAG-OpenMC.
More detail discuss see #5 .
For the neutron source: Are we going to use a psudo-source (simple point source for example), or use the real FNG neutron source? It seems that we do not have a FNG source for OpenMC yet.
I think we would want to use a pseudo-source. Probably something that explores the geometry well, like a volumetric neutron source over the entire model.
For the tally: Do we focus on specific cells or the entire geometry (all cells)? Or use mesh tally instead?
Because we're concerned with the spatial accuracy, a mesh tally would be good to have. A few cell-based tallies would be interesting as well to see how the faceting affects these values too.
For the geometry complexity: We need an indicator for geometry complexity. For CSG model, number of cells/surfaces maybe a good one, but for DAG model, number of triangles maybe better than number of cells/surfaces. Which one should we use?
This has long been an area of debate. I tend to view the number of triangles as a problem of scale rather than complexity. The same could be said for number of cells. I think really the average number of surfaces per volume, number of surfaces in total, and (in the case of DagMC) the number higher order surfaces (higher than order 2) are good ways of measuring the complexity of a model. It's tricky because CSG query performance will scale with the number of surfaces per cell, and DagMC's will scale with the number of triangles - making it difficult to have one metric to measure both by.
For the performance: Items to compare: CPU time, Maximum memory usage, particles/s, maybe parallel efficiency, anything else?
We'll probably want to focus mostly on the performance. CPU time and parallel efficiency. It would be good to put a lot of emphasis on how DagMC scales with the number of threads. Memory is less interesting because moving from equation-based surfaces to our triangles is going to incur more memory usage, and the simple story there is that if you want to represent real-world engineering geometries, you'll have to take that hit in memory usage no matter what. What's significant about our implementation in OpenMC is that it's threaded! So our memory usage will lower than when using other implementations in HPC environments. We can mention this when talking about how DAG-OpenMC scales with the number of threads.
For the geometry: There are several types of FNG model, which one do we use? FNG-dose or others? I think we should use the model which will be easiest to ensure that data and materials are consistent between OpenMC and DAG-OpenMC. More detail discuss see #5 .
For the neutron source: Are we going to use a psudo-source (simple point source for example), or use the real FNG neutron source? It seems that we do not have a FNG source for OpenMC yet. I think we would want to use a pseudo-source. Probably something that explores the geometry well, like a volumetric neutron source over the entire model.
For the tally: Do we focus on specific cells or the entire geometry (all cells)? Or use mesh tally instead? Because we're concerned with the spatial accuracy, a mesh tally would be good to have. A few cell-based tallies would be interesting as well to see how the faceting affects these values too.
For the geometry complexity: We need an indicator for geometry complexity. For CSG model, number of cells/surfaces maybe a good one, but for DAG model, number of triangles maybe better than number of cells/surfaces. Which one should we use? This has long been an area of debate. I tend to view the number of triangles as a problem of scale rather than complexity. The same could be said for number of cells. I think really the average number of surfaces per volume, number of surfaces in total, and (in the case of DagMC) the number higher order surfaces (higher than order 2) are good ways of measuring the complexity of a model. It's tricky because CSG query performance will scale with the number of surfaces per cell, and DagMC's will scale with the number of triangles - making it difficult to have one metric to measure both by.
For the performance: Items to compare: CPU time, Maximum memory usage, particles/s, maybe parallel efficiency, anything else? We'll probably want to focus mostly on the performance. CPU time and parallel efficiency. It would be good to put a lot of emphasis on how DagMC scales with the number of threads. Memory is less interesting because moving from equation-based surfaces to our triangles is going to incur more memory usage, and the simple story there is that if you want to represent real-world engineering geometries, you'll have to take that hit in memory usage no matter what. What's significant about our implementation in OpenMC is that it's threaded! So our memory usage will lower than when using other implementations in HPC environments. We can mention this when talking about how DAG-OpenMC scales with the number of threads.