I thought it was. If not, it can be easily done so, I think. I think the
issue was with the overlap projection, but that the quadtree was flexible
enough to handle it.
On Apr 22, 2013 8:44 PM, "Britton Smith" brittonsmith@gmail.com wrote:

Ok, giving a source region to a projection seemed to work in parallel. In
that case, I guess it's fine to phase out the field_cuts keyword. We
should still make sure the source keyword for projections gets into the
documentation in that section.

I thought it was. If not, it can be easily done so, I
think. I think the
issue was with the overlap projection, but that the quadtree was flexible
enough to handle it.
On Apr 22, 2013 8:44 PM, "Britton Smith" brittonsmith@gmail.com wrote:

Is doing a projection with a source region
parallelizable? The
field_cuts keyword will allow projections to still work in parallel. This
could be the value of keeping it around.

Ok, giving a source region to a projection seemed to
work in parallel. In that case, I guess it's fine to phase out the field_cuts keyword.
We should still make sure the source keyword for projections gets into the documentation
in that section.

On Mon, Apr 22, 2013 at 9:09 PM, Matthew Turk matthewturk@gmail.com wrote:
I thought it was. If not, it can be easily done so, I think. I think the issue was with
the overlap projection, but that the quadtree was flexible enough to handle it.

On Apr 22, 2013 8:44 PM, "Britton Smith" brittonsmith@gmail.com wrote:
Is doing a projection with a source region parallelizable? The field_cuts keyword will
allow projections to still work in parallel. This could be the value of keeping it
around.

On Mon, Apr 22, 2013 at 8:32 PM, Matthew Turk matthewturk@gmail.com wrote:
Hmm, should we still do this or instead rely on cut regions?

This discussion may be related to #552. Do we want
to rethink how we handle
the way field cuts work going forward?

Hm, this error actually is exactly correct. "NotImplementedError".
:) It's just something that I haven't gotten around to porting, it's
not deprecated or anything. Limited resources have led to
prioritizing getting the more straightforward data objects implemented
first ... this one has just been harder, and not prioritized.

Ok, giving a source region to a projection seemed to work in parallel. In
that case, I guess it's fine to phase out the field_cuts keyword. We should
still make sure the source keyword for projections gets into the
documentation in that section.

Ok, giving a source region to a projection seemed to
work in parallel. In
that case, I guess it's fine to phase out the field_cuts keyword. We should
still make sure the source keyword for projections gets into the
documentation in that section.

I completely agree about the docs. I'll do some performance tests
when I am able to compare the relative performance in seial and in
parallel before we do any deprecating.