I have written some custom gradients and want to use `./model diagnose`

to check the behavior but the 350 parameters (spread across multiple arguments to the function) are listed just as 1 to 350. I guess they are in the same order as the header of the CSV file, but is there an easy way to match parameter names to param idx of `diagnose`

?

The problem is that the function `diagnose`

reports the gradient output which is defined on the transformed unconstrained space, not the nominal constrained space defined in the `parameters`

block. Because of this the number of gradient components may even be equal to the dimension of the constrained space.

That said the ordering is preserved, so that your intuition is correct. If you donâ€™t have any constrained parameters then the parameter indices of the `diagnose`

function will correspond to the nominal parameters in the order theyâ€™re defined in the model, which is the same as the order of the CmdStan CSV header.

If you have any constrained variables that require lower-dimensional spaces (covariance matrices, simplices, etc) then you have to account for the change in dimension. The header of the â€śdiagnostic_fileâ€ť output accounts for this using a very naive naming convention, but it could be a useful double check.

It makes sense that the gradients need to behave well in the same space the sampler is moving in. Thanks for the helpful remarks; I think the tip about the `diagnostic_file`

is what Iâ€™m looking for.

Just be careful that the names in the `diagnostic_file`

arenâ€™t the most informative. For example given a parameter `real<lower=0> x;`

the diagnostic file will show values for `log(x)`

but still use the name `x`

in the header. Similarly for a simplex variable `simplex[3] x`

the diagnostic file will include columns labeled `x.1`

and `x.2`

which correspond not to the first two elements of `x`

but rather the two unconstrained variables that are used to generate `x`

.