<div dir="ltr"><div><div>Hey Oliver,<br></div>unfortunately, having the user create his
 own coordinate object is only a good idea for sequential grids. For 
parallel grids, the coordinate object implicitly contains information 
about the partitioning. Especially with TensorProduct grids this should 
not be touched by the user. It would also violates the "Simple things 
should be simple" paradigm.<br></div>Best,<br>Dominic</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 10:38 AM, Oliver Sander <span dir="ltr"><<a href="mailto:sander@igpm.rwth-aachen.de" target="_blank">sander@igpm.rwth-aachen.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dominic,<br>
thanks for measuring.  It's always good to make informed choices.  Frankly, I wouldn't<br>
have expected it to make that much of a difference.<br>
Concerning the additional information: I guess the most general way would be to require<br>
the user to create the Coordinate object herself, and pass it to the YaspGrid constructor.<br>
That way a single YaspGrid constructor works for all possible Coordinate types.<br>
On the other hand I think that one additional YaspGrid constructor for the case considered<br>
here wouldn't be a bad thing.<br>
Best,<br>
Oliver<br>
<br>
<br>
Am <a href="tel:13.10.2014" value="+13102014">13.10.2014</a> um 10:31 schrieb Dominic Kempf:<br>
<div class="HOEnZb"><div class="h5">> Hey Oliver,<br>
> this is indeed something to think about.<br>
> I have bad news though. I have done a quick measurement of option b).<br>
> I added a parameter origin to EquidistantCoordinates and defaulted it to 0.<br>
> This slowed down the finitevolume example by roughly 10%.<br>
> You're option a) is of course VERY simple to implement. The only question<br>
> that bugs me about it, is how to pass the additional information. I would<br>
> be very happy<br>
> if there was a good way, that does not involve introducing an additional<br>
> constructor.<br>
> Any opinions?<br>
> Best,<br>
> Dominic<br>
><br>
> On Fri, Oct 10, 2014 at 7:13 PM, Oliver Sander <<a href="mailto:sander@igpm.rwth-aachen.de">sander@igpm.rwth-aachen.de</a>><br>
> wrote:<br>
><br>
>> Hi all,<br>
>> while thinking about how to replace SGrid by YaspGrid I came about the<br>
>> following<br>
>> small inconvenience: SGrid are uniformly spaced, and both the lower left<br>
>> and the<br>
>> upper right corners are free.  YaspGrid, OTOH, when they are not<br>
>> tensor-product grids,<br>
>> constrain the lower-left corner to be (0,...,0).  So currently, in order<br>
>> to replace<br>
>> SGrids I sometimes have to use tensor-product YaspGrids even though they<br>
>> are uniformly<br>
>> spaced.<br>
>> Should we<br>
>> a) introduce a third Coordinates class in YaspGrid for uniformly spaced<br>
>> grids with<br>
>>    a nonzero left corner?<br>
>> b) generalize the current EquidistantCoordinate class to allow for a<br>
>> nonzero left<br>
>>    corner?<br>
>><br>
>> a) would be preferable if b) would lead to a measurable slowdown.  Does<br>
>> anybody<br>
>> have experience with this?<br>
>> Thanks,<br>
>> Oliver<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Dune-devel mailing list<br>
>> <a href="mailto:Dune-devel@dune-project.org">Dune-devel@dune-project.org</a><br>
>> <a href="http://lists.dune-project.org/mailman/listinfo/dune-devel" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-devel</a><br>
>><br>
>><br>
><br>
<br>
<br>
</div></div><br>_______________________________________________<br>
Dune-devel mailing list<br>
<a href="mailto:Dune-devel@dune-project.org">Dune-devel@dune-project.org</a><br>
<a href="http://lists.dune-project.org/mailman/listinfo/dune-devel" target="_blank">http://lists.dune-project.org/mailman/listinfo/dune-devel</a><br>
<br></blockquote></div><br></div>