Incompatibility Mechanism

[s9105947]

If an implementation does not support a PICMI feature, there is no standardized way to communicate that. I suggest we implement some methods provided by the picmistandard python package which can be called to indicate such incompatibilities. E.g.:

import picmistandard
picmi.codename = "dummypic"

picmistandard.util.unsupported_feature("mirrors")
# prints: "mirrors are not supported by dummypic"

if input.icecream not in ["vanilla", "strawberry"]:
    picmistandard.util.unsupported_value("icecream flavor: {}".format(input.icecream))
# prints: "value not supported by dummypic: icecream flavor: cherry"

I'd separate the two cases:

1. A parameter is not supported at all (unsupported_feature()).
2. A parameter is supported, but not all values can be used (unsupported_value()).

Potentially (down the road) the behavior of these functions could be complemented by user-defined callbacks. For now (purely by gut feeling) I'd propose warning (but continuing) in the first case, and throwing (aborting) in the second.

[dpgrote]

I've submitted PR #61 as a possible way of handling unsupported arguments and values. Does this work for you?

Note that there is a third case, where the code does not support one of picmi classes. For instance, a code that does not support RZ will not have an the class CylindricalGrid. But in this case, Python will already raise the error that the class name is not known.

[s9105947]

Thanks for preparing #61, this is pretty much what I had in mind. I've added some comments there.

But in this case, Python will already raise the error that the class name is not known.

...and the implementation could even leave this class explicitly empty:

class CylindricalGrid:
    def __init__(**kw):
        warnings.warn("cylindrical grid not supported")

(Note to future implementors: Probably a bad idea, haven't thought this through thoroughly.)