unexpected behavior when iterating over regular grids?

[rmodrak]

CASE 1 - Double-couple grid search with 2 points per axis. There should be 8 different moment tensors, but it seems capuaf just evaluates the same moment tensor 8 times!

cap.pl -H0.02 -P1/15/60 -p1 -S2/10/0 -T15/150 -D1/1/0.5 -C0.1/0.333/0.025/0.0625 -Y1 -Zweight_test.dat -Mscak_34 -m4.5 -I1/1/2/2/2 -R0/0/0/0/0/360/0/90/-180/180 20090407201255351

CASE 2 - Double-couple grid search with only 1 point. The point should line in the interior of the kappa/theta/sigma intervals (?), but it seems it lies on the boundary instead.

cap.pl -H0.02 -P1/15/60 -p1 -S2/10/0 -T15/150 -D1/1/0.5 -C0.1/0.333/0.025/0.0625 -Y1 -Zweight_test.dat -Mscak_34 -m4.5 -I1/1/1/1/1 -R0/0/0/0/0/360/0/90/-180/180 20090407201255351

[carltape]

For the case of a user asking to "search" a single point, while also providing a range for the search, it would be great if CAP would exit with an error explaining the incompatibility. If a user asks for a single point in the grid search (-I1/1/1/1/1), then they should also have to specify the gridpoint with the -R flag
For point solution use -Rv0/w0/strike0/dip0/rake0
If a user want to evaluate waveforms for a fixed moment tensor, then hopefully no -I flag is needed (or wanted).

I don't think we've completely tested all the range of search options for CAP. Perhaps if we outline all imaginable choices, this would help determine what exit messages should be implemented. The regular grid search has been used mostly for visualization purposes only -- for the DC "brick" plots in Silwal and Tape (2016) and for the FMT lune plots in Alvizuri and Tape (2016) and Alvizuri et al. (2018).

[rmodrak]

I was trying to use "regular grids" in the context of benchmark comparisons between CAP and MTUQ.

In writing such tests, the grid needs to be small, say -I1/1/1/10/10/10, otherwise it becomes impractical to include in travis.

So far the CAP and MTUQ regular grid results are similar, but not identical. I'm trying to understand why, and it seems the CAP regular grid discretization might be a bit strange.

In fact, I'm not so interested in fixing how CAP handles end member cases of 1 or 2 points per axis. I was just interested in understanding if there is anything unexpected about the discretization that might be affecting the CAP / MTUQ comparisons.