Customisable Region for arithmetic

[johnomotani]

Proposal:

• Add a new region like RGN_DEFAULT that by default is a reference to or copy of RGN_ALL
  • Idea is that RGN_DEFAULT can be replaced by the user for optimisation
  • I don't like RGN_DEFAULT as a name much, seems like it could be misleading. RGN_ARITHMETIC might be better, although it's a bit long?
• Replace RGN_ALL in pretty much all places we currently use it (in particular in the arithmetic operations) with RGN_DEFAULT.

I guess we'd need to change this: "In the current implementation overwriting a region, by attempting to add a region which already exists, is not allowed, and will result in a BoutException being thrown. This restriction may be removed in future." Maybe just remove the restriction for RGN_DEFAULT as a special case?

My use case is that I have a physics model which can use only 1 x-guard cell (MXG=1) almost everywhere but in a couple of places (for a certain implementation of ExB advection for a non-Boussinesq vorticity equation) I need 2 guard cells. Making communication routines give me a choice of how many guard cells to include seems likely too complicated to be worth doing, but skipping unneeded arithmetic in the second guard cell should give a useful speed-up.

Alternative proposal: remove the restriction on overwriting regions so I can modify RGN_ALL. This seems more potentially dangerous to me, so I'd favour the above to have a single customisable region.

[ZedThree]

RGN_ARITHMETIC is nice and descriptive and not too long.

Maybe a function to explicitly set this particular region? I guess it would be a method on Mesh.

[bendudson]

I second (third?) the RGN_ARITHMETIC choice: It's clear from the name what it does, and we won't need to be typing it very often.

We probably have to allow regions to be modified, just with a health warning in the manual.