Binary output : writing out ghost cells? about amrclaw HOT 11 OPEN

from amrclaw.

@mjberger Okay. I was hoping that using the F90 slicing feature would not be as slow as manually looping over i.j. It isn't that big a deal to strip out the ghost cells in Matlab.

from amrclaw.

I would imagine the compiler could inline something like that. Have you tested the slow-down by chance?

from amrclaw.

I am testing it now - and it seems that there is no slow-down, and in fact, writing out fewer values is faster (e.g. 0.044s vs. 0.059s). So it does seem that the compiler is able to handle the slicing efficiently.

from amrclaw.

from amrclaw.

I've just issued a PR to AMRClaw and with my proposed changes for the binary output. I've also issued one for Visclaw PR with the binary reader for Matlab.

Especially in 3d, not writing out the ghost cells seems to save a lot in both time writing output and saves in storage.

from amrclaw.

Reading binary output in Matlab is faster than reading the ascii, but this may not speed up the 3d plotting as much as one might hope. Rather, the code slows down as the number of 3d slices increases. At two different places in the code, I do basically an all-to-all comparison with slices at different orientations (x,y,z) to mask patches and to plot lines at slice intersections. The lines can be suppressed, but the masking is needed so the plotting looks okay. These bottlenecks can probably be sped up with more efficient algorithms. Anyone want to look into this?

In the meantime, set as few slices as necessary, i.e. in setplot3.m,

% setplot3.m : To speed up code, set only one slice in each direction, rather than 11. 
xSliceCoords = [0.5];    %linspace(0,1,11);
ySliceCoords = [0.5];    %linspace(0,1,11);
zSliceCoords = [0.5];    %linspace(0,1,11);

Note : users can loop over multiple slices using the sliceloop command. See

>> help clawgraphics

for more information on Clawpack Matlab graphics commands.

from amrclaw.

On a related note, at one point I was experimenting with creating arrays in visclaw that included the ghost cells too when reading in the binary output, after making sure these were properly set at the time they are written out in valout (which they aren't by default). For some purposes it may be useful to actually have the ghost cell values when plotting. In particular, if you want to make plots of vorticity, which requires finite differencing the velocities and doesn't look nice near patch boundaries if you switch to 1-sided differences there and use centered differences elsewhere. Also contour plots typically have a gap near patch boundaries that could perhaps be avoided if you contoured grids with one row of ghost cells included. But making all this general with an option where the user could set the number of ghost cells to include both on output and input and when plotting would take some work...

from amrclaw.

I actually think it would be fairly easy to specify how many ghost cells to output. Of course, it would require an extra parameter - something like mbc_out, but it seems that writing binary output with slicing doesn't suffer from any performance hits.

On the other hand, allowing the graphics to make use of the ghost cells is another story ...

from amrclaw.

from amrclaw.

I haven't done anything with GeoClaw output. And I don't really support GeoClaw plotting in Matlab - mostly because I am guessing nobody uses Matlab with GeoClaw. But I could do something if it were useful.

from amrclaw.