I agree with IAbstract's answer, but I want to expand upon it with my own 2 cents.
The abstract base should make no assumptions as to whether or not the derived children will "need" the method. Indeed, if it does make the assumption, assume the children absolutely need it.
In addition, providing an empty implementation in the abstract base would possibly lead to children believing there is, in fact, some default implementation that might actually do something. You might have children overriding the method with an empty implementation simply because they do not want anything done!
(I realize you may likely be the one writing both the base and the child, but I think it is best to mentally seperate your own roles. When you're writing the base, you're the provider. When you're writing the child, you're the consumer. As a provider, develop the base in a way that will make most sense to your consumers.)
Make the method abstract. Let the children decide what (if any) implementation there needs to be for each step of the algoritm, following in the spirit of the template method patterm.
InvalidOperationException
in the implementation of that inheritor. Which means you may want your abstract class to have anpublic abstract bool ExtraCriteriaAllowed { get; };
so consumers can know whether or not to use the method. \$\endgroup\$