Re: itaps-parallel [Fwd: **** iMesh.h and iBase.h changes ****]
Lori A. Diachin wrote:
Hi All,
Karen just pointed out that I read her email backwards and she is not available on the 21st, so I'd like to go with the second best option which is Tuesday the 20th at 1 pm so everyone can participate for at least part of the time. It's also a bit better from the perspective of the paper.
Sorry for the confusion.
Date: Tuesday, Jan 20 Time: 1 pm PST Number: 866-914-3976 Passcode: 662912#
Lori
At 01:09 PM 1/8/2009, Lori A. Diachin wrote:
Hi All,
It looks like there is mutual exclusivity until Jan 21. Everyone who responded is available from 1-2 pm pacific on that day. Please be prepared to talk about your status in updating your implementations wrt to the iMesh.h and iBase.h changes Jason proposed and to discuss item 6.
Carl, if there are any significant areas we should look at in the paper, please send it out in advance with pointers to the relevant areas of text.
The LLNL number: 866-914-3976 The passcode is 662912#
Lori
Hi All,
I'd like to check in on the status of everyone's changes wrt to the iMesh.h and iBase.h files that Jason sent out back in October. We decided to defer these until after SC08 and gave ourselves an internal deadline of Dec 15... so, are we done yet? :-)
Seriously - it was my understanding that folks had agreed in principle to all of these changes; the one exception was what to do about item #6 below. It may very well be that we need a quick telecon to discuss this as well as get an update on status. Carl is planning to send out the iMesh paper by Jan 23, so we may want to touch base before then..
Speaking of which, here's the latest version. Things I'd like people to look at: o The canonical ordering picture / table. I think I managed to make it clear, but please have a look and confirm/deny. o In the section on the swapping service, I've left in the comparisons of memory and CPU time for all three implementations, despite the fact that FMDB and MOAB don't have the critical calls tweaked. Tim, Mark (et al), I'm happy to take those comparisons out for now, although I think we'd be well-advised to have the fully optimized versions in the final paper either way. o Lori has promised I'll have new FE results before this goes to press. :-) And thanks to Jason for cleaning up the Mesquite section. Carl -- ------------------------------------------------------------------------ Dr. Carl Ollivier-Gooch, P.Eng. Voice: +1-604-822-1854 Associate Professor Fax: +1-604-822-2403 Department of Mechanical Engineering email: [email protected] University of British Columbia http://www.mech.ubc.ca/~cfog Vancouver, BC V6T 1Z4 http://tetra.mech.ubc.ca/ANSLab/ ------------------------------------------------------------------------
Carl, Although I would like to put some focus on improving mesh adapt (from multiple levels) and FMDB (low level performance and memory), I do not think it is going to happen in the near future since the SCOREC group needs to keep focused on parallel and meeting the needs of applications groups we are working with. (By the way your figure 6 showing where the time is spent is quite interesting and gives great information on where things need improvement - Ting and others, please note that figure and table XVI.) Therefore I am not comfortable including the memory and cpu comparisons. In addition to known inefficiencies, we may be comparing apples and oranges in some aspects. The mesh adapt procedures tend to include substantial logic checks and decision processes not used in lots of codes. My guess is that the only fair comparison is the the Native and GRUMMP comparison. Mark Carl Ollivier-Gooch wrote:
Lori A. Diachin wrote:
Hi All,
Karen just pointed out that I read her email backwards and she is not available on the 21st, so I'd like to go with the second best option which is Tuesday the 20th at 1 pm so everyone can participate for at least part of the time. It's also a bit better from the perspective of the paper.
Sorry for the confusion.
Date: Tuesday, Jan 20 Time: 1 pm PST Number: 866-914-3976 Passcode: 662912#
Lori
At 01:09 PM 1/8/2009, Lori A. Diachin wrote:
Hi All,
It looks like there is mutual exclusivity until Jan 21. Everyone who responded is available from 1-2 pm pacific on that day. Please be prepared to talk about your status in updating your implementations wrt to the iMesh.h and iBase.h changes Jason proposed and to discuss item 6.
Carl, if there are any significant areas we should look at in the paper, please send it out in advance with pointers to the relevant areas of text.
The LLNL number: 866-914-3976 The passcode is 662912#
Lori
Hi All,
I'd like to check in on the status of everyone's changes wrt to the iMesh.h and iBase.h files that Jason sent out back in October. We decided to defer these until after SC08 and gave ourselves an internal deadline of Dec 15... so, are we done yet? :-)
Seriously - it was my understanding that folks had agreed in principle to all of these changes; the one exception was what to do about item #6 below. It may very well be that we need a quick telecon to discuss this as well as get an update on status. Carl is planning to send out the iMesh paper by Jan 23, so we may want to touch base before then..
Speaking of which, here's the latest version. Things I'd like people to look at:
o The canonical ordering picture / table. I think I managed to make it clear, but please have a look and confirm/deny.
o In the section on the swapping service, I've left in the comparisons of memory and CPU time for all three implementations, despite the fact that FMDB and MOAB don't have the critical calls tweaked. Tim, Mark (et al), I'm happy to take those comparisons out for now, although I think we'd be well-advised to have the fully optimized versions in the final paper either way.
o Lori has promised I'll have new FE results before this goes to press. :-)
And thanks to Jason for cleaning up the Mesquite section.
Carl
participants (2)
-
Carl Ollivier-Gooch -
Mark Shephard