Need better error handling in vn(), vb(), etc

[langfob]

Random alpha value in derive_Xu_control_parameters() is sometimes too small & leads to illegal num_nodes_per_group and when vn() checks whether the value is in range, it crashes everything when it's not in range. Here's an example of the resulting error:

In stop_bdpg:  Validating '1' used for input variable integerize(n__num_groups^alpha__) - 
(num_independent_nodes_per_group - , must be >= range_lo = '2' 
Validating '1' used for input variable     1), must be >= range_lo = '2' 

The alpha value was a legal draw since it might have led to a legal number of nodes if the number of groups had been large, vn() correctly failed it for the given number of groups.

What really needs to happen here is that each of the derived values should be getting checked and then if they fail the check, they should return a flag that can be passed up the food chain to allow bdpg to make a new random draw instead of completely crashing.

This suggests that I might want to change the vb, vn, etc routines to have an input flag that lets you determine whether they fail completely when the tests are not passed or instead, return a flag indicating that somehow.

The difficulty is that right now, they return the validated number or boolean directly. Not sure how to get around that unless I set up exception handling, which would be a major overhaul in many places throughout the bdpg code.

For the moment, I'm going to just set the number of nodes to the smallest legal value whenever this happens, instead of having it crash. I don't have a problem with having the run fail rather than making this artificial fix, but tzar also has a bug and is not correctly marking all failed runs as failed at the moment. That means that when this crash would happen, tzar wouldn't necessarily flag that the run has crashed and that might cause other problems down the line. So, I'll just make this hacky fix for now.

NOTE: The other thing to note is that the fix doesn't really hurt anything in the experiments since we're not trying to exactly generate a specific distribution of Xu parameters that wouldn't be met by this fix. Instead, we're trying to roughly generate that distribution but more importantly, generate some distribution that allows random draws for test and train to be drawn from the same distribution. In this case, alpha values that are small enough to cause this error will always generate consistent behavior with this fix and so the randomly drawn training and testing values will be drawn from the same distribution.