Current COMPADRE release and development versions fail to meet CompadreData/CompadreM definition about rcompadre HOT 4 CLOSED

That is... frustrating. I didn't realise there would be such matrices in the data. I can sort of see why in exceptional cases like these it might be necessary to relax the rules of the class, though. What I would suggest doing instead is that we migrate this check to functions in Rage which assume a nonnegative matrix so that whilst the data may be included in com(p)adre and pass the checks of the ´class, that they can't be in calculations whose assumptions they violate (this is the approach I've taken in popdemo)

from rcompadre.

I can take care of coding this in the CompadreM class file. I've assigned myself the task

from rcompadre.

I've removed the need for matrices to be nonnegative... hopefully now the current databases will work as CompadreM objects @levisc8

We'll need to be careful about making sure to check for nonnegativity in other functions in Rcompadre, Rage and popdemo. For popdemo I've been thinking about writing a checking function that runs through common culprits which can then be run at the start of each functions with arguments to select or deselect the components to check against. Maybe this would be a good idea for Rcompadre and Rage also...

from rcompadre.

@iainmstott I've tested the new version and it seems to work. I definitely agree that we need to be mindful of implementing those checks in Rage and popdemo though.

from rcompadre.