2011/2/11 Jonathan Guyer <[email protected]> > > > On Feb 11, 2011, at 9:43 AM, Benny Malengier wrote: > > > I did some tests, and I came to the conclusion I have no idea how the add > mesh code works. I see in this code 'numerix.resize' and 'numerix.newaxis', > but these just append with 0's and I see those popping up without being set > so I fail to understand how these values are actually set. > > > > Perhaps this code is buggy for 3D? > > There's at least one 3D test that passes, but that doesn't mean there > aren't problems. > > > Hence I conclude I don't understand the code. > > It's possible that nobody does 8^) > > > I rewrote the code to what I can understand myself and to what I think it > is supposed to do, using the repeat function of fipy, which I think is more > correct that the resize and newaxis combination. > > Thank you! > > > I can now add the two 3D meshes without a mem error, and it is actually > quite fast which I was not expecting as I am using chunks of only 10. > > Interesting. Is that when you compare all vertices or only the exterior > ones? Both the chunking and the comparison of exterior points are clearly > good efficiencies, but I'd be interested to know where the primary benefit > is coming from. >
I think the benefit now comes from the chunks, just as in the polygon problem in the other thread which gave mem error, but with chunks went without problems. Using an operation manifold decreases the time too of course, in relation to the number of external indexes that are needed. My problem was that I added the chunks to the original closeness alg. and it did not work, I obtained indexes of connecting vertices that where completely wrong (always between 0 and chunksize). So I tried to understand the existing algorithm and failed. I'll do some extra tests when I have time again, I'm on a symposium at the moment. The extra nice thing about chunks is that that can be parallelized if advantageous. Greetings, Benny > > > If you indicate how the change can be made official, let me know and I > will do the work. I need direction for that though as I don't want to submit > patches that have no chance of being integrated. > > That's fair. This change will definitely make it into the code in some > form, whether we do it or you do it. I'm aware that you've contributed a > number of other things that haven't made it in, yet. Chalk that up to lack > of time, not lack of interest. > > > As to the underlying closeness algorithm, we'll need to take a look at both > the old way and your proposal to see which we prefer. We probably won't get > to it until next week. > > > >
