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.
2 Likes
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.
1 Like
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.