AS/NZS 1680.1:2006 Appendix B, whilst not Normative, still has the clearest instructions to computer-based lighting designers in Australia & New Zealand about important parameters for interior calculations, such as calc grid spacing and the like. It states what should be done, and the logical & practical reasons why it is necessary.
In that Appendix, Clause B2 CALCULATION GRIDS has this to say about effects of calc grid size:
"...Reducing the grid size will reduce the errors in uniformity and average illuminance but if a small grid is applied over a whole room the effects of the walls produce unduly pessimistic predictions of these parameters"
It then goes on in a sub-paragraph to state:
...(b) No calculation point should be closer than 1000 to a wall, partition or vertical obstruction that is included in the calculation."
(from surrounding information, it is clear that they meant 1000mm)
ElumTools allows us to set an 'exclusion zone' around rooms so that calcs are not performed within a user-nominated distance from the walls. AGi32 only provides this capability as a frustratingly tedious process of 'Remove Calc Point' functions in Polygon or Window sized bites, and it's especially painful where there are rooms and/or partitions that are not 'North-South' or 'East-West' in nature.
On the surface, it would seem that a function to nominate a distance of calc-point exclusion for walls and other objects would be a great idea. Certainly it would be a far better situation that the current one we're in. However, in reality, it's not always practical to follow what the Standard says. For example, many corridors are less than 2000mm wide, so blindly following the Standard would result in no calc points at all. Similarly, a toilet block (set of bathrooms) with partitions for stalls and the generally enclosed spaces would end up with very few areas that exist more than 1000mm from a large vertical obstruction.
So, the final solution is probably up to the team at Lighting Analysts as to what they're prepared to do to make the software really user friendly, intuitive and flexible in this respect, but as it currently stands the time taken up dealing with this issue manually on a large project is considerable.
I note that as an AGi32 user, it feels frustrating that ElumTools gets lots of these nice functions. Many of us have been using the software since the old DOS days of the late 80s & early 90s, and have financed a lot of the ability for Lighting Analysts to create new software such as ElumTools. I'd submit that if the functions are in ElumTools, then they're included because they're seen as useful to the user experience. That should therefore mean that they need to be available to AGi32 users as well.