Matt Larsen
Matt Larsen
This is what we have now: https://github.com/Alpine-DAV/ascent/blob/e0afe9750ba047f5916805dec5aec95f4e16c1e1/src/ascent/utils/ascent_actions_utils.hpp#L64
Lulesh deposits energy in one corner of the data set and the shockwave propagates radially. Unfortunately, that region is on then other side of the data set. We have example...
Potential output for a filter: ``` filter_name: "pl1_0_vtkh_marchingcubes" filter_type: "vtkh_marchingcubes" params: field: "braid" iso_values: [-0.4, 0.2, 0.4] ``` So in this case, there were three levels and the resulting iso...
First: Welcome Justin! We can do a better job of reporting the error, and this should be caught inside the ascent filter rather than in a dependent lib. The reason...
- expressions as filter parameters - scalar rendering - binning and python processing examples
nice. Thanks for getting this over the finish line.
I played around with this when I was doing the original ray tracing performance study. For me, the default static scheduling was bad, but changing it to dynamic did not...
Do you know why there is a huge dip at 2 processors and then back up? On 2016-02-05 00:20, Vincent Chen wrote: > Here is some scaling I tried today...
Well, I think that this particular problem maybe memory bound. As more threads do work, the memory systems get saturated and scaling suffers. -Matt On 2016-02-05 10:17, Vincent Chen wrote:...
You could take the enxo data set, use visit to re-sample it into a different sizes. Then just tetrahedralize it. -Matt On 2016-02-05 10:30, Vincent Chen wrote: > Yeah all...